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

 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. ***
**********************************************************************************************