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