Re: Version of "Disconnected" ServiceChange messages

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 protected] [mailto:[email protected]] On Behalf
Of Elad Chomsky
Sent: Tuesday, April 15, 2008 6:27 AM
To: Carsten Waitzmann
Cc: [email protected]
Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages

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 protected]]
Sent: Tuesday, April 15, 2008 12:54 PM
To: Elad Chomsky
Cc: [email protected]
Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages

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




Elad Chomsky wrote:
> 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 protected]
> https://www.ietf.org/mailman/listinfo/megaco
> 

--
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 protected]
https://www.ietf.org/mailman/listinfo/megaco