Subject: RE: Version negotiation and message headers

From: "Tom-PT Taylor" <[email-masked]>
Date: Tue, 13 Mar 2001 12:04:51 -0500

I couldn't find Alf's remarks in his second reply.  However, my view of the
situation differs from what Nancy proposes, as follows:
(1) The MG and MGC MUST negotiate and use a common version.  If this can't
be done, the registration fails.  (Implication: the MGC probably has to
support at least two versions and has to be upgraded before the MGs in the
same network.)
(2) The rules Alf quotes ensure that the negotiation works.  They also
minimize the pain of moving from one version to another.

> -----Original Message-----
> From: Nancy Devin [mailto:[email-masked]]
> Sent: Friday, March 09, 2001 9:54 AM
> To: Alf Heidermark (UAB)
> Cc: Mark Mitchell; [email-masked]'
> Subject: Re: Version negotiation and message headers
> 
> 
> 
> If I understand properly, in step 3) the MGC will send the 
> serviceChange reply encoded using version 2,e.g. version in 
> msg header is 2, and the serviceChangeVersion parameter will 
> be set to 1.  Since the serviceChangeDescriptor has been 
> defined in protocol version 1,
> none of its parameters and values have been modified when 
> version 2 of the protocol has been defined.  Therefore a 
> version 1 parser (the MG parser) should be able to execute 
> the command without failure.
> 
> If this is the case, then what is the use of the version in 
> the message header?
> 
> Nancy
> 
> "Alf Heidermark (UAB)" wrote:
> 
> > See comments below
> >
> > -----Original Message-----
> > From: Nancy Devin [mailto:[email-masked]]
> > Sent: den 8 mars 2001 15:06
> > To: Alf Heidermark (UAB)
> > Cc: Mark Mitchell; [email-masked]'
> > Subject: Re: Version negotiation and message headers
> >
> > 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.  
> (Alf) According to chapter 11.3 it answer with version 1.
> 
> > 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
> >
> > "Alf Heidermark (UAB)" wrote:
> >
> > > 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]
> >
> > --
> > 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]
> 
> --
> 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]
> 
> 
>