Re: 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
>
>