Subject: RE: Version negotiation and message headers

From: "Alf Heidermark (UAB)" <[email-masked]>
Date: Thu, 8 Mar 2001 14:44:58 +0100

Nancy
Version 1 shall be a subset of  version 2 so they can always speak on version 1 level according to the rules in the last part of paragraph. 

The last part of paragraph says

"When extending the protocol with new versions, the following rules should be followed.
1. Existing protocol elements, i.e., procedures, parameters, descriptor, property,  values, should not be changed unless a protocol error needs to be corrected or it becomes necessary to change the operation of the service that is being supported by the protocol.
2. The semantics of a command, a parameter, descriptor, property, value should not be changed.
3. Established rules for formatting and encoding messages and parameters should not be modified.
4. When information elements are found to be obsolete they can be marked as not used. However, the identifier for that information element will be marked as reserved. In that way it can not be used in future versions".

If this rules are followed I assume that an earlier version always becomes a subset of the later version.

-----Original Message-----
From: Nancy Devin [mailto:[email-masked]]
Sent: den 8 mars 2001 14:16
To: Mark Mitchell
Cc: [email-masked]'
Subject: Re: Version negotiation and message headers

Hi all,

Regarding the discussed scenario, MG supports only version 2 and MGC supports
only version 1.

When the MG sends its first serviceChange command, the message version is
version 2.  Within the serviceChange command, the version parameter is 2.  How
can the MGC parse the serviceChange command if it only support version 1?

Suppose it can parse the serviceChange command.  It replies with the
serviceChangeReply and indicates that it wants to use version 1 through the
version parameter.  The message version is then 1.  How can the MG parse the
message if it does not support version 1.

That would mean that the MG can not register with the MGC.  Is it a requirement
to know which common version is supported by both the MG and the MGC before
registration?

Nancy

Mark Mitchell wrote:

> Hi there,
>
> I've got some questions on version negotiation.  The spec is pretty clear
> about how to negotiate versions on the original ServiceChange commands
> (section 11.3).  However, we're not sure about how this fits in with the
> version number that appears in the Megaco message header (i.e. "MEGACO/1"
> for version 1).  Presumably this version will change when version 2 of the
> protocol appears?
>
> Our understanding is that at this point, a Gateway sending a service change
> and supporting version 2 will send a message with a header of "MEGACO/2" and
> version 2 in the ServiceChange command.  If the MGC only supports version 1,
> it will respond with version 1 in the ServiceChange response and in the
> message header.  After this, future messages from the MG should adhere to
> version 1.   This raises a few questions.
>
> - Presumably this means that subsequent Gateway messages should have 1 in
> the message header?
>
> - When parsing a message, should we parse based on the negotiated version
> (from the ServiceChanges) rather than the version in the message header?
> This is particularly interesting with regards to the first response - we
> have sent Version 2 but as the MGC has responded with version 1 we will need
> to parse this response according to the version 1 spec.  I presume we would
> parse as far as the version number, realise this is V1 and use V1 rules to
> parse?
>
> - Should we reject a message that has a version number in the message ID
> that disagrees with the negotiated version?
>
> Sorry for thinking so far in advance!
>
> Regards,
>
> Mark
>
> -------
> Mark Mitchell
> Development Manager - DC-MGCP/DC-Megaco
> Voice Networking Group
> Data Connection Ltd
> Tel: +44 20 8366 1177
> Fax: +44 20 8363 1468
> Email: [email-masked]
> Web: http://www.dataconnection.com

--
Nancy Devin
Software Designer

Alcatel
600 March Road, P.O. Box 13600
Kanata, Ontario, Canada
K2K 2E6

Telephone: (613) 591-3600 x6897
Fax:       (613) 599-3609
Internet:  [email-masked]

---

From: Nancy Devin <[email-masked]>
Date: Thu, 08 Mar 2001 09:06:11 -0500

Hi Alf,

If that is the case, it would imply that the connection between an MG that supports only version 1 and an MGC that supports only version 2 is valid?  But that none of the version two capabilities would be available on the MG.  Would that mean that the following
scenario is valid?

Scenario
MC supports only protocol version 1
MGC supports only protocol version 2

1)    MG sends a registering serviceChange command to the MGC.  The version in the msg header is 1 and the version parameter is set to 1.

2)    MGC receives the command.  It parses the command using a version 2 parser and recognizes that the MG wants to negotiate version 1.

3)    MGC replies to the MG with a serviceChange reply.  The msg header is 2 and the version parameter is set to 2.

4)    MG receives the serviceChange reply.  It detects that the message has been encoded using version 2, but it uses its version 1 parser to decode the message.  The MG ignores any version 2 parameters that it does not understand.

At that point the MG is registered with the MGC.

The MG will always send messages encoded using version 1.
The MGC will always send messages encoded using version 2.
The MG will parse the MGC messages using a version 1 parser

Nancy

--
Nancy Devin
Software Designer

Alcatel