Re: Version of "Disconnected" ServiceChange messages
Kevin Boyle <kboyle <at> nortel.com>
2008-05-07 05:58:04 GMT
Sorry about the delay... H.248 isn't my primary job anymore and I
sometimes have trouble responding as quickly as I once did. Comments
inline. [KJBII]
Kevin
-----Original Message-----
From: Elad Chomsky [mailto:elad <at> juniper.net]
Sent: Tuesday, April 15, 2008 5:17 PM
To: Boyle, Kevin (NCRTP:0Q10); Carsten Waitzmann
Cc: megaco <at> ietf.org
Subject: RE: [Megaco] Version of "Disconnected" ServiceChange messages
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.
[KJBII] Right. Because this is kind of a "bozo state", the MGC might
have also detected the outage and is waiting for the SC Disconnected to
ensure that things have returned to normal on the comms link. It then
could take action to ensure that the MG and MGC are in sync about the
status of the existing contexts.
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.
[KJBII] This is a pretty good summary, other than the very last part.
The MG *could* re-register, but then all bets are off for any existing
contexts, and the MGC may wipe out whatever was established on the MG
earlier. A SC Disconnected indicates that there was a temporary outage
and comms have now been restored. MGCs may very well treat that a whole
lot differently than a re-registration which could be an indicator of a
much bigger problem. The whole idea is to be unambiguous about what is
going on from the MG's point of view.
----------
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.
[KJBII] You are right -- it does need to return an error. I don't see
one that is particularly indicative of the situation... 504 is
marginally OK other than the fact that it is deprecated. While I think
401 is a bit vague and isn't really as descriptive as it ought to be,
that seems the best choice until a new error code can be added to
H.248.8 for this situation.
Thanks,
Elad
-----Original Message-----
From: Kevin Boyle [mailto:kboyle <at> nortel.com]
Sent: Tuesday, April 15, 2008 6:42 PM
To: Elad Chomsky; Carsten Waitzmann
Cc: megaco <at> ietf.org
Subject: RE: [Megaco] 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: megaco-bounces <at> ietf.org [mailto:megaco-bounces <at> ietf.org] On Behalf
Of Elad Chomsky
Sent: Tuesday, April 15, 2008 6:27 AM
To: Carsten Waitzmann
Cc: megaco <at> ietf.org
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:cwaitzmann <at> alcatel-lucent.de]
Sent: Tuesday, April 15, 2008 12:54 PM
To: Elad Chomsky
Cc: megaco <at> ietf.org
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
> Megaco <at> ietf.org
> 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
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
RSS Feed