Re: Version of "Disconnected" ServiceChange messages

G'Day Elad,

Yes, that's the intention.

Regards, Christian

Elad Chomsky wrote:
> 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
>>
>>   
>>     
>
>