Re: Version of "Disconnected" ServiceChange messages

Hi Christian,

Thanks for picking this up. The new error code sounds good to me.

Will you be adding it to the next version of the implementors' guide?

Thanks,
Elad

-----Original Message-----
From: Christian Groves [mailto:[email protected]] 
Sent: Wednesday, June 25, 2008 8:45 AM
To: Kevin Boyle
Cc: Elad Chomsky; Carsten Waitzmann; [email protected]
Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages

G'Day,

As a follow up I would propose to add a new error code to the IG (whilst

we wait for other H.248.8 additions) along the line of:

*
4.2.4x Error code #: 507*

*Name*: Unknown Control Association

*Definition*: Returned by a MGC in response to a ServiceChangeRequest 
with method "Disconnect" when the MGC has no knowledge of the indicated 
control association. MGC should only return responses to MGs that it has

knowledge of in order to minimise security issues.

*Error Text in the Error Descriptor*: -

*Comment*: -

Sound OK?

Regards, Christian

Kevin Boyle wrote:
> 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:[email protected]] 
> Sent: Tuesday, April 15, 2008 5:17 PM
> To: Boyle, Kevin (NCRTP:0Q10); Carsten Waitzmann
> Cc: [email protected]
> 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:[email protected]]
> Sent: Tuesday, April 15, 2008 6:42 PM
> To: Elad Chomsky; Carsten Waitzmann
> Cc: [email protected]
> 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: [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
> _______________________________________________
> Megaco mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/megaco
>
>