Subject: Re: Profile and version in ServiceChange Descriptor

From: Tom-PT Taylor <[email-masked]>
Date: Thu, 3 Feb 2000 09:39:47 -0500

v1 ServiceChange already has room for expansion -- the extension capability
is explicit.

> -----Original Message-----
> From: Christian Groves [SMTP:[email-masked]]
> Sent: Thursday, February 03, 2000 9:20 AM
> To:   [email-masked]
> Subject:      Re: Profile and version in ServiceChange Descriptor
>
> 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.
> >
> >      -----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:56:47 +0100

G'Day Tom,

Yes I agree v1 ServiceChange can be expanded but is there any point if
in the future you'll always send a v1 ServiceChange. You should optimise
a protocol for the most common case, that is where the MGC and MG will
have the same versions. Therefore send the highest version you support.

Cheers, Christian

Tom-PT Taylor wrote:
>
> v1 ServiceChange already has room for expansion -- the extension capability is explicit.
>