Subject: [Megaco] Isup Megaco Corellation

From: Odelia Jacobowitz <[email-masked]>
Date: Wed, 16 Jul 2008 14:06:54 +0300

Hi ,

I need to correlate between Isup to Megaco signaling messages ,
Can I expect to find in the ADD request (Megaco message) reference to the cic from the Iam  (Isup message) ?

* In the MGCP protocol for instance the cic was encapsulated in the endpoint EI .
Please advice ...
Regards,
Odelia Jacobowitz
Embedded Software Engineer

Septier Communications Ltd.
Tel :  +972-(0) 3-924-7026 (123)
Fax:  +972-(0) 9-924-7023
Cell:  +972-(0)54-4790-668
Email: [email-masked]<mailto:[email-masked]>
Web:  www.septier.com<BLOCKED::http://www.septier.com>

_______________________________________________
Megaco mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/megaco

---

From: Christian Groves <[email-masked]>
Date: Fri, 18 Jul 2008 10:10:12 +1000

Hello Odelia,

There is no direct reference to a cic in Megaco. The MGC is expected to 
maintain a mapping between a cic and a TerminationID. So if the MGC 
receives an IAM it will request a particular terminationID based on the 
cic via a ADD.request.

Regards, Christian

Odelia Jacobowitz wrote:
> *Please advice …*
> *Regards,*
> *Odelia Jacobowitz*
> * *
> *Tel :* +972-(0) 3-924-7026 (123)
>
> *Fax:* +972-(0) 9-924-7023
>
> *Cell:* +972-(0)54-4790-668
>
> Email: [email-masked] <mailto:[email-masked]>_
>
> Web: www.septier.com <BLOCKED::http://www.septier.com>
>
> ------------------------------------------------------------------------
>

---

From: "Raphael Tryster" <[email-masked]>
Date: Sun, 27 Jul 2008 15:21:15 +0300

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

---

From: Christian Groves <[email-masked]>
Date: Tue, 29 Jul 2008 15:05:43 +1000

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

---

From: "Raphael Tryster" <[email-masked]>
Date: Tue, 29 Jul 2008 08:24:31 +0300

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-masked]] 
Sent: Tuesday, July 29, 2008 8:06 AM
To: Raphael Tryster
Cc: [email-masked]
Subject: Re: [Megaco] Which MGC should be contacted first on
retransmission timeout?

Hello Raphael,

connection, or 2) the primary MGC going "OutOfService". The MG will not 

....

Regards, Christian

> some other method of detecting re-establishment of communication being
************************************************************************
**********************
> *** eSafe scanned this email for viruses, vandals, and malicious
content. ***
************************************************************************
**********************

---

From: "Schwarz Albrecht" <[email-masked]>
Date: Tue, 29 Jul 2008 09:58:37 +0200

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Raphael Tryster
> Sent: Dienstag, 29. Juli 2008 07:25
> To: Christian Groves
> Cc: [email-masked]
> 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
> 
> 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:
> 
> 
> 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.
> 
> ....
> 
> > communication with the MGC, the MG sends a ServiceChange 
> Command with
> a
> If you have received this email in error, please notify the 
> system manager or the sender immediately and do