Subject: [Megaco] Version of "Disconnected" ServiceChange messages

From: "Elad Chomsky" <[email-masked]>
Date: Mon, 14 Apr 2008 15:57:48 +0100

Hello H.248 heavyweights,

I have a question regarding the H.248 version that should be used when
encoding a "Disconnected" ServiceChange request.

The way an MG utilizes "Disconnected" ServiceChange requests is
described under Annex F.3.6 of H.248.1:

1/ When an MG detects that it became disconnected from its MGC, it tries
to re-establish its control-association by sending a "Disconnected"
ServiceChange request to that MGC. If the MGC replies to request, the
control-association continues without interruption.

2/ If the MGC fails to reply to the ServiceChange request above, the MG
starts traversing its list of possible MGCs and tries registering with
each of them. The MG will use a "Disconnected" ServiceChange when trying
to register with the original MGC and a "Failover" ServiceChange when
trying to register with any other MGC.

3/ The control-association is terminated as soon as the MG sends a
"Failover" ServiceChange request to an MGC.

Now according to (2) above, the "Disconnected" ServiceChange can be
considered as a registration. Therefore, according to clause 11.3 of
H.248.1, it must be encoded according as a version 1 message. However it
also appears that in (1) above, the "Disconnected" ServiceChange is sent
over an existing control-association; and therefore should be encoded
according to the association's negotiated version. 

Is this the correct interpretation? I.e. Must a "Disconnected"
ServiceChange be encoded using version 1 if no control association
exists and using the negotiated version if a control-association exists?
Or should one of these versions always be used?

Many thanks in advance,
Elad Chomsky

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

---

From: Carsten Waitzmann <[email-masked]>
Date: Tue, 15 Apr 2008 11:53:36 +0200

Hello Elad,

I think that's a valid point.

According to H.248 Sup.7 "renewal" is considered as follows:
The term “refreshment” (also known as “renewal”) of an H.248 CA is
related to the application of ServiceChange method and reason
combination of {Disconnected, #900}. CA refreshment is characterized by
situations of a previous existing CA, a subsequent short-term
interruption, and then a continuation of the previous CA without any MG
(re-)registration step(s).

Furthermore, F.3.6 says that the original H.248 CA is terminated
whenever the MG attempts to re-register with another MGC ("failover").
As at that point the original H.248 CA is terminated, it cannot be
renewed anymore and therefore a new CA has to be established. In other
words, the scenario escalates from "lost communication" to "lost control
association". Thus I think it would be appropriate to say that in a
second (third, ..) round when the MG tries to re-register with the MGC
of the original CA, the MG will use SC method "restart".
I don't think that "disconnected/900" should be admitted as mean for
re-registration.

best regards
Carsten

-- 
Alcatel-Lucent Deutschland AG
Sitz der Gesellschaft: Stuttgart - Amtsgericht Stuttgart HRB 4026
Vorsitzender des Aufsichtsrats: Michael Oppenhoff
Vorstand: Wolfgang Weik (Vors.), Dr. Rainer Fechner, Juergen Poesinger, Alf
Henryk Wulf
_______________________________________________
Megaco mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/megaco

---

From: "Elad Chomsky" <[email-masked]>
Date: Tue, 15 Apr 2008 11:26:33 +0100

Hello Carsten,

Like you, I dislike the fact that the same method/reason combination,
"Disconnected/900" is used both to renew a control association and to
re-register once that control association was terminated. However
changing this behavior will require making a change to Annex F.3.6.
Currently this annex clearly states that:

"If the MG exhausts its list of MGCs without successfully establishing a
control association, the MG waits a random amount of time and then
attempts registration with the MGCs in its list again, starting with the
MGC from the original control association. The MG will send a
ServiceChange with a ServiceChangeMethod of "Disconnected" to the MGC
from the original control association each time the MG attempts to
contact it."

So, "Disconnected/900" is clearly used for re-registration as well.

If this behavior is changed, I would suggest that re-registration will
use "Failover/909". I see little reason to differentiate between the
original MGC and all others once the control association is terminated.

I would still be really grateful for any views regarding the H.248
version that should be used when encoding the two types of
"Disconnected/900" (i.e. the "renew" one and the "re-register" one).
This point is actually causing us some interoperability problems.

Many thanks,
Elad

-----Original Message-----
From: Carsten Waitzmann [mailto:[email-masked]] 
Sent: Tuesday, April 15, 2008 12:54 PM
To: Elad Chomsky
Cc: [email-masked]
Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages

Hello Elad,

The term "refreshment" (also known as "renewal") of an H.248 CA is

best regards
Carsten

Vorstand: Wolfgang Weik (Vors.), Dr. Rainer Fechner, Juergen Poesinger,
Alf

---

From: "Kevin Boyle" <[email-masked]>
Date: Tue, 15 Apr 2008 11:42:00 -0400

I believe that this is being made far more complicated than it was
intended to be.

The wording about "terminating" the control association was put in place
because there has to be some point when the MG stops listening to the
original association in order to establish a new one.  But if no one
else accepts the registration, why can't the original be "picked back
up"?  The MGC from the previous control association would still think it
was the same control association.

The intent of Disconnected has always been that the comms were lost on
the control association and they are being reestablished.  Given this,
it is not actually a re-registration.

Registration to establish a new control association must always use
version 1.  This is to allow version negotiation to take place at the
lowest common denominator, as support of later versions implies support
of earlier versions.  Disconnected is not establishing a new control
association, but is repairing one that was the subject of comms loss.
This means that the Disconnected should be encoded per the version
negotiated on the previous control association between the two entities.
If the MG wishes to renegotiate the version, then it can do so once
comms are re-established.

Kevin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elad Chomsky
Sent: Tuesday, April 15, 2008 6:27 AM
To: Carsten Waitzmann
Cc: [email-masked]
Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages

Hello Carsten,

Many thanks,
Elad

-----Original Message-----
From: Carsten Waitzmann [mailto:[email-masked]]
Sent: Tuesday, April 15, 2008 12:54 PM
To: Elad Chomsky
Cc: [email-masked]
Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages

Hello Elad,

best regards
Carsten

Alf Henryk Wulf _______________________________________________

---

From: "Elad Chomsky" <[email-masked]>
Date: Tue, 15 Apr 2008 22:16:42 +0100

Hello Kevin,

If I understand you correctly, it would seem that my original
understanding of Annex F.3.6 was very different from its original
intent. I would be very grateful if I could run by you what I infer from
your response (below); just to make sure I got it right this time:

----------

An MG can detect a disconnection of the control-association; for
example, through the timing-out of an MG initiated transaction. When the
MG detects such a disconnection, it still considers the
control-association as active. It handles any requests received on that
control-association normally; and issues Notify requests over it when
events are detected. However it will also send a "Disconnected/900"
ServiceChange on the control-association; to inform the MGC that there
was a temporary interruption of the connection.

If the MGC fails to respond to the "Disconnected/900" ServiceChange
request (i.e. this request also times-out), the MG considers the control
association as down. It will no longer accept requests received on this
control-association. Instead it will try registering with other MGCs
using a "Failover/909" ServiceChange. Whenever its configuration
indicates that it should try registering with the original MGC, it would
instead try to renew the original control-association using a
"Disconnecetd/900" request. Note that this "renewing" is not a
registration; i.e. the MG never tries to re-register with the original
MGC.

----------

If this is correct, what error should the MGC return when it receives a
"Disconnected/900" ServiceChange but knows nothing about an existing
control-association? Some error must be returned, as otherwise the MG
will never be able to connect with that MGC.

Thanks,
Elad

-----Original Message-----
From: Kevin Boyle [mailto:[email-masked]] 
Sent: Tuesday, April 15, 2008 6:42 PM
To: Elad Chomsky; Carsten Waitzmann
Cc: [email-masked]
Subject: RE: [Megaco] Version of "Disconnected" ServiceChange messages

Kevin

-----Original Message-----

Hello Carsten,

Many thanks,
Elad

-----Original Message-----
From: Carsten Waitzmann [mailto:[email-masked]]
Sent: Tuesday, April 15, 2008 12:54 PM
To: Elad Chomsky
Cc: [email-masked]
Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages

Hello Elad,

best regards
Carsten