Re: Which MGC should be contacted first on retransmission timeout?

Hi Albrecht,

After going through this thread will it be correct to assume:

1. There is no reason to retry the same MGC with which a transaction 
failure has happened for Notify requests sent from MG.
2. For the reliable transport protocols it is possible to find out if 
the link/connection to MGC has gone down. I think the reason F.3.6 
mentions to retry the same MGC is because we do not want to go into 
cycle of retrying all other MGCs during transient failures. But don't 
you think that the reliable transport layer itself should handle such 
transient failures. The transient failures should be  transparent to 
H.248 layer.

Isn't it better to have MG always try  different MGC starting from 
primary (first in the list) irrespective of the transport protocol. For 
reliable transport protocols , the transport layer will have capability 
to recover from transient failures transparently, so that MG does not 
enter the disconnect procedure.

Thanks,
Vikram




Schwarz Albrecht wrote:
> Hi Raphael,
>
> you may be right for a particular network instantiation, whereas H.248.1
> is considering the more general case.
>
> Here: guess "Notify" relateds to the H.248.14-based "MGC polling
> mechanism by MG", which again is a technology, required only for
> non-assured transport protocols.
> Any assured transport technology does not require H.248.14.
>
> Annex F (F.3.6) is transport-independent, thus not providing all
> potential logic when coupling non-SC based call-independent procedures
> with SC procedures.
>
> Saying that, your point is valid, and I would try to address it in a
> profile spec (because a profile is transport dependent).
>
> BR, Albrecht
>
>
>   
>> -----Original Message-----
>> From: [email protected] 
>> [mailto:[email protected]] On Behalf Of Raphael Tryster
>> Sent: Dienstag, 29. Juli 2008 07:25
>> To: Christian Groves
>> Cc: [email protected]
>> Subject: Re: [Megaco] Which MGC should be contacted first on 
>> retransmissiontimeout?
>>
>>
>>  Thanks, Christian.  So to give a concrete example, if MG  
>> receives no reply to retransmissions of a Notify for half a 
>> minute, it will transmit SC Disconnected for another half a 
>> minute before trying failover to another MGC.  I don't see 
>> any reason why retransmission timeout of SC is a more 
>> reliable indication of MGC failure than retransmission 
>> timeout of a Notify (except a bug in the MGC), but this 
>> mechanism provides some extra time to verify the MGC or the 
>> connection is dead before trying a different MGC.  Is this 
>> extra time actually a Good Thing?
>>
>> Regards,
>>
>> Raphael
>>
>> -----Original Message-----
>> From: Christian Groves [mailto:[email protected]]
>> Sent: Tuesday, July 29, 2008 8:06 AM
>> To: Raphael Tryster
>> Cc: [email protected]
>> Subject: Re: [Megaco] Which MGC should be contacted first on 
>> retransmission timeout?
>>
>> Hello Raphael,
>>
>> In Amendment 1 to H.248.1v3 two notes were added to the F.3.6 
>> text that may provide further explanation. The text reads:
>>
>>
>>       F.3.6 MG Lost Communication
>>
>> When the MG has detected a loss and subsequent 
>> re-establishment of communication with the MGC (NOTE 1), the 
>> MG sends a ServiceChange Command (NOTE 2) with a 
>> ServiceChangeMethod of "Disconnected" to the MGC
>>
>> in the current control association. If the MGC fails to 
>> respond, the MG then sends a ServiceChange Command with a 
>> ServiceChangeMethod of "Failover" and ServiceChangeReason 909 
>> ("MGC Impending Failure") to each
>>
>> MGC in its list in turn until it has successfully established 
>> a new control association, or it has exhausted its list of 
>> MGCs. If the MGC does respond, the control association 
>> continues as if it were not interrupted.
>>
>> NOTE 1: The two main causes for lost communications between 
>> the MGC and MG are 1) failures or short-term interruptions of 
>> the H.248 transport connection, or 2) the primary MGC going 
>> "OutOfService". The MG will not necessarily be able to 
>> discriminate between the two, therefore the ServiceChange 
>> procedures are the same in both cases.
>>
>> NOTE 2: The MG may send one or more ServiceChange Commands. 
>> The transmission of subsequent ServiceChange Commands may be 
>> timer-controlled. Multiple re-establishment attempts may help 
>> in situations with short-term failures, either of the 
>> transport connection or of the MGC, thereby avoiding the 
>> invocation of failover procedures when they are not warranted.
>>
>> ....
>>
>> With regards to "Disconnected" despite its name its actually 
>> to indicate
>>
>> that the Control association was lost and is now re-established, thus 
>> the first sentence of F.3.6. I don't think there's a problem between 
>> 11.5 and F.3.6 because 11.5 indicates firstly that its already 
>> determined that the MGC has failed thus the procedure goes into 
>> failover. In F.3.6 the first part of the procedure is that 
>> communication
>>
>> is restored and if this isn't successful then go into a failover.
>> With regards to the "hint" of another method I guess its relying on a 
>> transport level indication of connectivity between a MGC and MG.
>>
>> Regards, Christian
>>
>> Raphael Tryster wrote:
>>     
>>>  Is there a contradiction between 11.5 and F.3.6?
>>>
>>> 11.5 says:
>>>
>>> "If the MG detects a failure of its controlling MGC, it attempts to
>>> contact the next MGC on its pre provisioned list. It starts its
>>>       
>> attempts
>>     
>>> at the beginning (primary MGC), unless that was the MGC that failed,
>>>       
>> in
>>     
>>> which case it starts at its first secondary MGC".
>>>
>>> F.3.6 says:
>>>
>>> "When the MG has detected a loss and subsequent re-establishment of
>>> communication with the MGC, the MG sends a ServiceChange 
>>>       
>> Command with
>> a
>>     
>>> ServiceChangeMethod of 'Disconnected' to the MGC in the current
>>>       
>> control
>>     
>>> association. If the MGC fails to respond, the MG then sends a
>>> ServiceChange Command with a ServiceChangeMethod of 'Failover' and
>>> ServiceChangeReason 909 ('MGC Impending Failure') to each MGC in its
>>> list in turn until it has successfully established a new control
>>> association, or it has exhausted its list of MGCs".
>>>
>>> So, suppose MG sent a Notify and failed to receive a reply before
>>> retransmissions timed out.  According to 11.5, it would send SC to a
>>> DIFFERENT MGC.  According to F.3.6, it would send SC to the 
>>>       
>> SAME MGC,
>>     
>>> and only try a different one if the SC also timed out.  Which is it?
>>>
>>> I am also puzzled by the language of F.3.6.  ""When the MG has
>>>       
>> detected
>>     
>>> a loss and subsequent re-establishment of communication 
>>>       
>> with the MGC".
>>     
>>> Usually, SC Disconnected is sent as a trial to see whether the MGC
>>>       
>> will
>>     
>>> now reply, and not as a result of re-establishment of communication.
>>>       
>> Is
>>     
>>> some other method of detecting re-establishment of 
>>>       
>> communication being
>>     
>>> hinted at here?
>>>
>>> Raphael Tryster
>>>
>>>       
>> **************************************************************
>> **********
>> **********************
>>     
>>> IMPORTANT: The contents of this email and any attachments are
>>>       
>> confidential. They are intended for the 
>>     
>>> named recipient(s) only.
>>> If you have received this email in error, please notify the system
>>>       
>> manager or the sender immediately and do 
>>     
>>> not disclose the contents to anyone or make copies thereof.
>>> *** eSafe scanned this email for viruses, vandals, and malicious
>>>       
>> content. ***
>>     
>> **************************************************************
>> **********
>> **********************
>>     
>>> _______________________________________________
>>> Megaco mailing list
>>> [email protected]
>>> https://www.ietf.org/mailman/listinfo/megaco
>>>
>>>   
>>>       
>> **************************************************************
>> ********************************
>> IMPORTANT: The contents of this email and any attachments are 
>> confidential. They are intended for the 
>> named recipient(s) only.
>> If you have received this email in error, please notify the 
>> system manager or the sender immediately and do 
>> not disclose the contents to anyone or make copies thereof.
>> *** eSafe scanned this email for viruses, vandals, and 
>> malicious content. ***
>> **************************************************************
>> ********************************
>>
>> _______________________________________________
>> Megaco mailing list
>> [email protected]
>> https://www.ietf.org/mailman/listinfo/megaco
>>
>>     
> _______________________________________________
> Megaco mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/megaco
>
>