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

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
>