Subject: Re: Profile and version in ServiceChange Descriptor

From: Tom-PT Taylor <[email-masked]>
Date: Wed, 2 Feb 2000 19:51:51 -0600

I like your approach of requiring initial registration to always use v1
format.  Let's see what others say.

> -----Original Message-----
> From: Chuong Nguyen [SMTP:[email-masked]]
> Sent: Wednesday, February 02, 2000 12:33 PM
> To:   [email-masked]
> Subject:      Re: Profile and version in ServiceChange Descriptor
>
> Can we just negotiate version at the message header level instead of going
> into transaction
> and serviceChange?
>
> IF MGC does not support the version specified in the message header, it
> will return an
> error to MG.  MG can start backing off the version # until it finds one
> that the MGC would
> accept.
>
> The example seems to be implying that the first message is always encoded
> in v1 and
> version negotiation is done with serviceChange messages.  If so, the
> Standard should clearly
> state this in section 11.3.
>
> Otherwise, in the example if MG started w/ v3, it would get an error at
> the message level.
> Then MG has to start backing off the version # until MGC accept it.  So we
> are back to doing
> some kind of message level version negotiation.
>
> Chuong
>
> Abdallah Rayhan wrote:
>
>       The objective of message versioning is different from protocol
> versioning
>       in service change. Messaging versioning is for efficient parsing and
>
>       processing of the message as well as debugging. While protocol
> versioning
>       in servicechane is for changing the protocol version without
> resorting to
>       error messages.
>
>       For example,
>       1-
>       ; msg encoded in V1, servicechange version is 2
>       ; both MG and MGC understand V1
>       MG -------> MGC
>
>       2-
>       ; msg is still encoded in V1,
>       ; MGC rejects service change version, MGC does not support V2
>       ; MG realizes that it can not upgrade its communication with MGC
>       MG <------- MGC
>
>       3- MG decides whether it wants to continue communication with
>       MGC in V1 or halt.
>
>       Another scenario would be that MGC supports V2 as well V1, so it
>       accepts service change to V2. MG encodes its msgs using V2 syntax
>       as well as MGC. The last two steps of the above scenario would be,
>       2-
>       ; msg is still encoded in V1,
>       ; MGC accepts service change version, MGC supports V2
>       ; MG realizes that it can upgrade its communication with MGC
>       MG <------- MGC
>
>       3-
>       ; msg is encoded in V2,
>       MG -------> MGC
>
>       Abdallah Rayhan
>
>       Harpreet Singh Anand wrote:
>
>       > Hello,
>       >
>       > > The Profile field conatins a version and a version field is also
> included
>       > > seperately in ServiceChange
>       > > Descriptor. Are they different, or this is redundant information
> ?
>       >
>       > The version in the profile field specifies the version of the
> profile being
>       > supported by the gateway. It is different from the version field
> which specifies
>       > the version of the MEGACO protocol.
>       >
>       > Quote from section 7.2.8:
>       >
>       > " The optional Profile parameter specifies the Profile (if any) of
> the
>       > protocol supported.  The Profile includes the version of the
> profile
>       > supported.
>       >
>       > The optional Version parameter contains the protocol version and
> is used
>       > if protocol version negotiation occurs (see section 11.3). "
>       >
>       > A related question: What is the need of adding version field in
>       > ServiceChangeDescriptor when the same information is there in the
> first line of
>       > the message ?
>       >
>       > Regards,
>       > Harpreet
>       >
>       > _________________________________
>       > Harpreet Singh Anand
>       > Ficon Technology
>       > E-mail :  <mailto:[email-masked]>
>       > Web    :  <http://www.ficon-tech.com>
>
> --
>   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: Christian Groves <[email-masked]>
Date: Thu, 3 Feb 2000 15:19:39 +0100

I don't think this is practical always using the v1 format. We may want
to in the future add new features to the initial startup serviceChange
action. With this limitation it means that we can't add these new
features.

Cheers, Christian

Tom-PT Taylor wrote:
>
> I like your approach of requiring initial registration to always use
> v1 format.  Let's see what others say.
>
>      Can we just negotiate version at the message header level instead
>      of going into transaction
>      and serviceChange?
>
>      IF MGC does not support the version specified in the message
>      header, it will return an
>      error to MG.  MG can start backing off the version # until it
>      finds one that the MGC would
>      accept.
>
>      The example seems to be implying that the first message is always
>      encoded in v1 and
>      version negotiation is done with serviceChange messages.  If so,
>      the Standard should clearly
>      Otherwise, in the example if MG started w/ v3, it would get an
>      error at the message level.
>      Then MG has to start backing off the version # until MGC accept
>      it.  So we are back to doing
>           The objective of message versioning is different from
>           protocol versioning
>           processing of the message as well as debugging. While
>           protocol versioning
>           > > The Profile field conatins a version and a version field
>           is also included
>           > > Descriptor. Are they different, or this is redundant
>           information ?
>           >
>           > The version in the profile field specifies the version of
>           the profile being
>           > supported by the gateway. It is different from the version
>           field which specifies
>           > " The optional Profile parameter specifies the Profile (if
>           any) of the
>           > protocol supported.  The Profile includes the version of
>           the profile
>           > supported.
>           >
>           > The optional Version parameter contains the protocol
>           version and is used
>           > ServiceChangeDescriptor when the same information is there
>           in the first line of
>           > the message ?
>           >
>           > Regards,
>           > Harpreet
>           >

---

From: Chuong Nguyen <[email-masked]>
Date: Thu, 3 Feb 2000 09:15:51 -0600

Tom
I was only trying to get some pro and con on message level version
negotiation versus
serviceChange version level negotiation.

My point is with message level version negotiation, one does not have to
dig into the command
level to figure out what version is needed/requested.  In order to dig into
the command level, one
would have to use the correct version parser which could be a nightmare.
I think it avoids the scenario that Christian mentions below.

Hopefully the message header is always the same regardless of how many
Megaco versions there
are.

From Christina's point:
If you have new features thus new version and somehow does not recognize v1
anymore,
then there is no backward compatibility.

By the way I do not see backward compatibility as a requirement.  If there
is no requirement
why even bother with version negotiation especially serviceChange version
level negotiation.
 Section 11.3 only describes how to implement version negotiation.
It did not said that MGC shall support a lower version.
"..., if the MGC supports only a lower version ..."
"If the MGC supports a higher version than the MG but is able to support
the lower version ..."

Chuong