Subject: Re: [Megaco] Protocol version negotiation

From: Terry L Anderson <[email-masked]>
Date: Thu, 01 Aug 2002 14:53:47 -0400

got two votes for being explicit and no objections, so I suggest the 
following wording:

Current text:
A ServiceChange command from an MG that registers with an MGC shall 
contain the version number of the protocol supported by the MG in the 
ServiceChangeVersion parameter. Regardless of the version placed in the 
ServiceChangeVersion parameter the message containing the command shall 
be encoded as a version 1 message. Upon receiving such a message, if the 
MGC supports only a lower version, then the MGC shall send a 
ServiceChangeReply with the lower version and thereafter all the 
messages between MG and MGC shall conform to the lower version of the 
protocol.  If the MG is unable to comply and it has established a 
transport connection to the MGC, it should close that connection.  In 
any event, it should reject all subsequent requests from the MGC with 
Error 406 Version Not supported.

If the MGC supports a higher version than the MG but is able to support 
the lower version proposed by the MG, it shall send a ServiceChangeReply 
with the lower version and thereafter all the messages between MG and 
MGC shall conform to the lower version of the protocol. If the MGC is 
unable to comply, it shall reject the association, with Error 406 
Version Not Supported.

Add:
Otherwise, it is optional for the MGC to return a version in the 
ServiceChangeReply.

Aleksandr Ryabin wrote:

> Hi,
>
> I agree that returning version is optional.
> Although I also agree with Terry that it is odd to describe all, but 
> one case.
> Perhaps it would be good to include the case explicitly (even if it might
> look intuitive what it means) to avoid any confusion.
>
> Thanks,
>         Aleks
>
> At 10:10 AM 7/24/2002, Terry L Anderson wrote:
>
>
>> Christian Groves wrote:
>>
>>> G'Day Terry,
>>>
>>> I don't know why the MGC MUST return the version. The text currently 
>>> does not
>>> state this. The MGC can either not return the version (acceptance of 
>>> the MG
>>> signalled version) or reply with the same version of the MG 
>>> signalled version.
>>
>> I agree that there is no statement that it MUST return the version. 
>> It's just that all the other cases are mentioned explicitly (and all 
>> these DO require version) and so it is somewhat odd to omit the one 
>> that is perhaps the most common (at least now).  We certainly have 
>> the choice to leave things as they are so that returning version is 
>> optional.  I just think that describing all but one case leads to 
>> confusion, but if no one else is concerned (and agrees that returning 
>> version is optional for this case) I will drop it.
>>
>>> Regards, Christian
>>>
>>> Terry L Anderson wrote:
>>>
>>>
>>>> Section 11.3 on protocol negotiation, describes the behavior of MGC
>>>> specifying explicitly that it return version in the response for 
>>>> two cases:
>>>> 1) MGC supports only a lower version than that proposed by MG
>>>> 2) MGC supports a higher version but can support the version 
>>>> proposed by MG.
>>>> I believe by extension that MGC should also return version in the case
>>>> where
>>>> 3) MGC supports ONLY the same version proposed by MG
>>>> but this is not actually stated.  MG of course could not know the
>>>> difference between #2 and #3.  I suppose that an MG receiving a 
>>>> response
>>>> with no version should assume that the version proposed is being
>>>> accepted but of course this would have worked for #2 as well. The
>>>> question is, is omission equivalent to returning the equal value.
>>>>
>>>> Do we believe that MGC MUST always return a version in its response 
>>>> and
>>>> if so should we reword the first two paragraphs of 11.3 to make this
>>>> clear, OR are we satisfied this leaving it optional in case #3.
>>>>
>>>> -- 
>>>>
>>>> ------------------------------------------------------------
>>>> Terry L Anderson              mailto:[email-masked]
>>>> Tel:732.949.5628   Fax:732.949.7016
>>>> Lucent Technologies/INS/Voice Over IP Access Networks
>>>> Rm 2G-219A, 101 Crawfords Corner Rd, Holmdel, NJ 07733-3030
>>>> http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
>>>>
>>>> _______________________________________________
>>>> Megaco mailing list
>>>> [email-masked]
>>>> https://www1.ietf.org/mailman/listinfo/megaco
>>>>
>>>
>>>
>>>
>>
>> -- 
>>
>> ------------------------------------------------------------
>> Terry L Anderson              mailto:[email-masked]
>> Tel:732.949.5628   Fax:732.949.7016
>> Lucent Technologies/INS/Voice Over IP Access Networks
>> Rm 2G-219A, 101 Crawfords Corner Rd, Holmdel, NJ 07733-3030
>> http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
>>
>>
>>
>>
>>
>> _______________________________________________
>> Megaco mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/megaco
>
>

-- 

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:732.949.5628   Fax:732.949.7016
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2G-219A, 101 Crawfords Corner Rd, Holmdel, NJ 07733-3030
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 01 Aug 2002 14:53:47 -0400

Current text:

Add:

--

---

From: "Chuong N. Nguyen" <[email-masked]>
Date: Thu, 01 Aug 2002 14:41:42 -0500

How long is the MG supposed to remember that MGCxxx does not support that
version?
Is it really necessary to reply back w/406?

IF MG can't establish control association w/MGCxxx, it would move on and
eventually find
another MGC that would accept its registration.

IF I was the MG, I would not reply back w/anything if the MGC is not my
controller.
So is the MG considered not compliant to the Megaco Standard?

--
  Alcatel USA, Inc             Internet: [email-masked]
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****

---

From: "Chuong N. Nguyen" <[email-masked]>
Date: Thu, 01 Aug 2002 14:41:42 -0500

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 01 Aug 2002 17:54:32 -0400

First of all, let's be clear that I was not proposing any change in the 
part to which you refer, so your comments have nothing to do with the 
correction I am advocating, but I'll respond to them anyway below.

Chuong N. Nguyen wrote:

> How long is the MG supposed to remember that MGCxxx does not support 
> that version?

I think that the intension was that MG reply with 406 for later requests 
sent by the MGC during the association.  But of course we have yet to 
refine our definition of association.  Unfortunately our registration 
process is a two message handshake rather than a three message handshake 
and so there is no way for the MG to unambiguously cancel the 
association due to properties of the MGC's reply (including the 
version).  And we do not have any "unregister" command.  So it is 
possible for the MG to believe that the association has ended while the 
MGC does not.  Dropping any tranport connection should accomplish it for 
connection-oriented transport but this is more difficult for 
connection-less transports.  It might seem reasonable for MG to consider 
the association ended and simply ignore requests from the MGC (as with 
any other MGC with which it has no association).  But the MGC may well 
believe that the association exists and so retry the request the maximum 
number of times.  MGC responding with an error will break the 
association more rapidly.  As to how long, I would think that this might 
be allowed to be implementation dependent (since we are only trying to 
save the retranmissions).  After some provisioned period, MG could well 
treat requests as from any non-associated MGC.

> IF MG can't establish control association w/MGCxxx, it would move on 
> and eventually find
> IF I was the MG, I would not reply back w/anything if the MGC is not 
> my controller.
I guess if you accept my view the only question is, can the provisioned 
period be as short as 0 sec.

>> >>>> http://its.lucent.com/~tla <http://its.lucent.com/%7Etla> 
>> (Lucent internal) http://www.gti.net/tla
>> >>>>
>> >> http://its.lucent.com/~tla <http://its.lucent.com/%7Etla> (Lucent 
>> internal) http://www.gti.net/tla
>> >>
>> >>
>> >>
>> >>
>> >>
>> http://its.lucent.com/~tla <http://its.lucent.com/%7Etla> (Lucent 
>> internal) http://www.gti.net/tla
>>

--

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 01 Aug 2002 17:54:32 -0400

--

---

From: "Chuong N. Nguyen" <[email-masked]>
Date: Thu, 01 Aug 2002 17:36:54 -0500

You are right that the discussion has nothing to do w/the change but the
implementation of
current text regarding error, 406.

You bring up a good point that I didn't even thought of - how to tell MGC to
"unregister".
But I do accept your view.
Something more to add to the implementation.

Reading the current text more closely, it is kind of strange that the MG will
return an error when
MGC replies w/a lower version.

I was always under the impression that higher version of the Standard has to
be backward compatible
w/lower version.
Is there such a requirement?

---

From: "Chuong N. Nguyen" <[email-masked]>
Date: Thu, 01 Aug 2002 17:36:54 -0500

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 01 Aug 2002 19:24:03 -0400

Chuong N. Nguyen wrote:

> You are right that the discussion has nothing to do w/the change but 
> the implementation of
> You bring up a good point that I didn't even thought of - how to tell 
> MGC to "unregister".
> Reading the current text more closely, it is kind of strange that the 
> MG will return an error when
> I was always under the impression that higher version of the Standard 
> has to be backward compatible
> w/lower version.
I suppose it depends on what one means by "compatible".  There are 
stated requirements (actually stated for package versions), that 
properties, signals and events can be added but existing ones can not be 
removed or modified.  We follow similar principles for a new version of 
the protocol (eg. deprecating a property rather than removing it, etc.)  
 This means that a parser can be designed to ignore the extensions and 
still be able to parse the parts that are in common.  And one can also 
be designed to tolerate the omission of the extensions to read a lower 
version message.  But this does not mean that an entity is REQUIRED to 
be designed to function without the extensions (accept a lower version). 
 It just helps insure that such a design is possible.

>> <http://its.lucent.com/%7Etla>
>> <http://its.lucent.com/%7Etla> (Lucent
>> <http://its.lucent.com/%7Etla> (Lucent

--

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 01 Aug 2002 19:24:03 -0400

--

---

From: Christian Groves <[email-masked]>
Date: Fri, 02 Aug 2002 10:31:15 +1000

G'Day Terry,

I thought it would be better to be a little bit more specific:
"If the MGC supports the version indicated by the MG, it is optional for the MGC
to return a version in the ServiceChangeReply.

Christian

---

From: Christian Groves <[email-masked]>
Date: Fri, 02 Aug 2002 10:31:15 +1000

G'Day Terry,

Christian

---

From: Terry L Anderson <[email-masked]>
Date: Fri, 02 Aug 2002 10:17:29 -0400

Your description actually overlaps a bit with one of the others ( :-) 
part of why I chose my language was to insure I avoided overlap or any 
other overlooked cases).  An MGC that supports the indicated version AS 
WELL AS A HIGHER ONE, is required by the second paragraph to return a 
version (the indicated one).  But I would be happy replacing the second 
paragraph (or most of it) with your statement.  That is, an MGC that 
supports a higher version as well as the indicated version can accept 
the indicated version by returning no version.  In fact the whole thing 
might be explained more clearly, by rewording it to indicate that a 
version must be returned ONLY when the indicated one cannot be supported 
and to require a lower one.  Returning the a version equal to the 
indicated one would always be optional.  

How about replacing BOTH paragraphs with:

be encoded as a version 1 message. 

If the MGC cannot support the indicated version, but is able to support 
a lower one, it shall return the lower version in the ServiceChangeReply 
and thereafter all the messages between MG and MGC shall conform to the 
lower version of the protocol.  If the MGC is unable to support the 
indicated version or any lower one, it shall reject the association, 
with Error 406 Version Not Supported. If the MG is unable to comply and 
it has established a transport connection to the MGC, it should close 
that connection.  In any event, the MG should reject all subsequent 
requests (for a provisioned time) from the MGC with Error 406 Version 
Not supported. The MGC may optionally return the indicated version to 
confirm its acceptance.

Christian Groves wrote:

>to return a version in the ServiceChangeReply 
>
>Christian
>
>Terry L Anderson wrote:
>  
>

--

---

From: Terry L Anderson <[email-masked]>
Date: Fri, 02 Aug 2002 10:17:29 -0400

--

---

From: "Chuong N. Nguyen" <[email-masked]>
Date: Fri, 02 Aug 2002 10:34:47 -0500

Wouldn't it clearer and straight forward if MGC is required to return the version
period.

Having to deal w/optional parameter seems to always be causing some kind of
implementation hardship/confusion.

---

From: "Chuong N. Nguyen" <[email-masked]>
Date: Fri, 02 Aug 2002 10:34:47 -0500

---

From: "Joseph Bell" <[email-masked]>
Date: Sun, 4 Aug 2002 12:18:53 -0500

Hi all.

I have a question regarding the ABNF grammar in S1.5.3 of H.248.6.  In
particular, ToneName is defined as

ToneName = (Package id, Tone id) / "#"FreqValue / "&"AnnouncementParameterList

My question is how to interpret '(Package id, Tone id)'.  Is this an ABNF
sequence group, and if so, what is the comma for?

Or should this have been written

ToneName = "(" PackageId "," ToneId ")" / "#"FreqValue /
"&"AnnoucementParamterList

Regards,
Joe

---

From: "Joseph Bell" <[email-masked]>
Date: Sun, 4 Aug 2002 12:18:53 -0500

Hi all.

Regards,
Joe

---

From: "Joseph Bell" <[email-masked]>
Date: Sun, 4 Aug 2002 12:44:42 -0500

Additional question:

The example RingingTone given in H.248.6 doesn't seem to be able to match the
existing grammar.  The end of the string is simply

*0

which seems to indicate an infinite repeat, but the DefToneString is clearly

"(" DefToneElement ["*" RepeatCount] ")" ["," / "+" / "X" DefToneString]

which indicates to me that the string must always be enclosed in parenthesis and
RingingTone should have *0) on the end.

Regards
Joe
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of Joseph
Bell
  Sent: Sunday, August 04, 2002 12:19 PM
  To: Megaco Mailing List
  Subject: [Megaco] Annex J (248.6) Tone Grammar Clarification

  Hi all.

  Regards,
  Joe

---

From: "Joseph Bell" <[email-masked]>
Date: Sun, 4 Aug 2002 12:44:42 -0500

Additional question:

*0

Regards
Joe
  -----Original Message-----

  Hi all.

  Regards,
  Joe

---

From: Christian Groves <[email-masked]>
Date: Mon, 05 Aug 2002 13:22:02 +1000

G'Day Terry,

I don't understand why my sentence overlaps quite a bit. The previous paragraphs
talk about the case where the version received from the MG is higher or lower
than the one the MGC wishes to support. Rather than rewording the 2 paragraphs
how about:
""If MGC wants to use the version indicated by the MG, it is optional for the
MGC to return a version in the ServiceChangeReply"

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Mon, 05 Aug 2002 13:22:02 +1000

G'Day Terry,

Regards, Christian

---

From: Terry L Anderson <[email-masked]>
Date: Mon, 05 Aug 2002 10:17:48 -0400

The problem is that the second paragraph refers to one case where the 
MGC is accepting the offered value but the wording requires the return 
of the version:

If the MGC supports a higher version than the MG but is able to support
the lower version proposed by the MG, it shall send a ServiceChangeReply...

I want to remove that wording that conflicts.

--

---

From: Terry L Anderson <[email-masked]>
Date: Mon, 05 Aug 2002 10:17:48 -0400

--

---

From: Christian Groves <[email-masked]>
Date: Tue, 06 Aug 2002 11:05:28 +1000

G'Day Terry,

There are 3 situations:
1. The MG sends a version, the MGC supports a lower one, so it sends back the
lower one (this is the first paragraph)
2. The MG sends a version, the MGC supports a higher one, but as the MG only
supports the lower one the MGC has to send back the MG version (this is the case
in the second paragraph)
3. The MG sends a version, the MGC supports the same one, so the MGC either can
send back the same one or not send back anything. (this is the addition)

Can we at least agree that its case 3 that we need to add?

I still can't see the conflict but coing from the southern hemisphere it may be
that being upside down is getting to me!?!?

Regards, Christian

---

From: Christian Groves <[email-masked]>
Date: Tue, 06 Aug 2002 11:05:28 +1000

G'Day Terry,

There are 3 situations:

Regards, Christian

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 06 Aug 2002 10:05:38 -0400

>Can we at least agree that its case 3 that we need to add?
Yes.

>that being upside down is getting to me!?!?
I believe that your suggested statement also covers #2 making return of 
version for
#2 optional while the current language makes returning version for #2 
mandatory.  I would prefer allowing it to be optional but then the 
current language for #2 requires change.

--

---

From: Terry L Anderson <[email-masked]>
Date: Tue, 06 Aug 2002 10:05:38 -0400

Yes.

--

---

From: Aleksandr Ryabin <[email-masked]>
Date: Tue, 06 Aug 2002 10:23:23 -0400

Hi Christian,

         I know its been "chewed" for a while now, but here is my two
cents anyway :)

         From MG point of view case 2 and 3 can not be differentiated
since at the end they will talk the same version MG originally requested.
It does not matter what MGC supports, or not. What important is to establish
ether they can talk the same version and which version will that be.
This is why I believe Terry is trying to change the wording to basically
merge 2 and 3 and say that in these cases version is optional.
Thus if MGC agrees with MG proposed protocol version it is optional to
send version in reply.

I think what case 1 and failure situations have to clearly stated
and then wording about optional version return, for example, that you
have suggested, should be placed.

That is leave orig par 1 as is, replace par 2 with the following wording:

"If the MGC only supports higher version(s) than the MG, it shall
reject the association with Error 406 Version Not Supported.

If the MGC supports the version indicated by the MG, it is optional for
the MGC to return a version in the ServiceChangeReply"

Thanks
         Aleks

---

From: Aleksandr Ryabin <[email-masked]>
Date: Tue, 06 Aug 2002 10:23:23 -0400

Hi Christian,

Thanks
         Aleks

---

From: Troy Cauble <[email-masked]>
Date: Tue, 06 Aug 2002 12:18:29 -0400

Joseph Bell wrote:
> My question is how to interpret '(Package id, Tone id)'.  Is this an 
> ABNF sequence group, and if so, what is the comma for?
>  

I can't answer for the author, but I'd GUESS that only the
comma was meant to be quoted.

But there are other problems with the ABNF in H.248.6.

1.  If the document is using ABNF, it should reference RFC 2234.

2.  The VCHAR specification includes printables like comma, dash,
     double quote, parens, asterisk, ampersand, hash-mark, etc.

     A) Some of these items are used as delimiters in the higher
     level productions.  These delimiters are indistinguishable from
     VCHAR productions.

     B) The double quote character is not allowed within String parameter
     elements of H.248.1. (See the ABNF appendix in H.248.1.)

3.  I believe that the following also specfies the double quote
     character, which is not allowed in String parameter elements
     of H.248.1.

     SubstitutionString = """1*VCHAR""";

4.  This type of recursion was avoided in H.248.1.  But I can't find anything
     in RFC 2234 that says it's illegal...

     DefToneString = "(" DefToneElement ["*" RepeatCount ] ")" [","/"+"/"X" 
DefToneString]

I suggest that #2 be fixed by changing VCHAR to something with few or no
punctuation characters.

-troy

---

From: Troy Cauble <[email-masked]>
Date: Tue, 06 Aug 2002 12:18:29 -0400

-troy

---

From: Aleksandr Ryabin <[email-masked]>
Date: Tue, 06 Aug 2002 13:37:42 -0400

I have another comment about it.
(Package id, Tone id) construction meaning seems to be same as pkgdName
as defined in the base spec, which is (PackageName SLASH ItemID).
If my understanding correct then I'm curious why invent new coding for it?
Should not it be "/" instead?

         Aleks

At 12:18 PM 8/6/2002, Troy Cauble wrote:
>     DefToneString = "(" DefToneElement ["*" RepeatCount ] ")" 
> [","/"+"/"X" DefToneString]
>
>

---

From: Aleksandr Ryabin <[email-masked]>
Date: Tue, 06 Aug 2002 13:37:42 -0400

Aleks

---

From: "Joseph Bell" <[email-masked]>
Date: Tue, 6 Aug 2002 19:21:29 -0500

Comments inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Aleksandr Ryabin
Sent: Tuesday, August 06, 2002 12:38 PM
To: Troy Cauble; [email-masked]; Megaco Mailing List
Subject: Re: [Megaco] Annex J (248.6) Tone Grammar Clarification

[JAB]
H.248.1 appears to take the approach of "don't leave it up to chance."  If I
read
  PackageName SLASH ItemID

and later see
  SLASH = %x2F; "/"

then I know without a doubt that it is not an ABNF alternative.
[/JAB]
         Aleks

>1.  If the document is using ABNF, it should reference RFC 2234.

[JAB] No argument here.

>I suggest that #2 be fixed by changing VCHAR to something with few or no

[JAB]
Good point on VCHAR.  It appears from reading various tone strings that
PackageId and ToneId
can either be a hexadecimal tag or a string name.  Could the ABNF be changed
to
PackageId = ("0" "x" 1*HEXDIG) / (1*ALPHA)
ToneId = ("0" "x" 1*HEXDIG) / (1*ALPHA)

I think my confusion on the recursion is that the way it reads seems to
preclude the ability to
do something like

(((#480)+(#620)),250,-24)

because in this example the recursion is not at the DefToneString level, but
at the DefToneElement level.

DefToneElement = ToneName ["," ToneDuration ["," ToneAmplitude]]

In above, ((#480)+(#620)) is being treated as a ToneName, which I don't see
anything in the grammar
(recursive or not) supporting that.

Regards
Joe

---

From: "Joseph Bell" <[email-masked]>
Date: Tue, 6 Aug 2002 19:21:29 -0500

Comments inline.

-----Original Message-----

[JAB]

and later see
  SLASH = %x2F; "/"

[JAB] No argument here.

[JAB]

Regards
Joe