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