Subject: Re: Washington Issue 21 - Version Incompatibilities

From: Tom-PT Taylor <[email-masked]>
Date: Fri, 19 Nov 1999 14:14:27 -0600

Don't forget that we have major and minor version numbers.  If one end
supports a higher minor version number than the other, the two ends should
still be able to interwork, using the selective processing procedures
defined in B. below.  If the major version numbers differ, we effectively
have two different protocols and if one end can't drop down to the level of
the other there can be no association.

> -----Original Message-----
> From: Rayhan, Abdallah [CAR:5N00:EXCH]
> Sent: Friday, November 19, 1999 10:46 AM
> To:   [email-masked]
> Subject:      Re: Washington Issue 21 - Version Incompatibilities
>
> Should this be in the main document or in a separate I-D ?
> If it is ought to happen, a separate I-D might be the way to go
> since this seems to be an important issue that will be addressed for
> all old and future releases of MEGACO.
>
> Abdallah Rayhan
>
> Christian Groves wrote:
>
> > G'Day all,
> >
> > I like Harpeet version handling method (as included below).
> >
> > I also think some text like we have for the packages versioning should
> > be added as well describing principles for extending the protocol. ie.
> > backwards compatible changes.
> >
> > Cheers, Christian
> >
> > Harpeet's text---------------------------------------------------------
> >
> > - The MG-MGC association is initiated by MG.
> > - The first ServiceChange command from MG would contain the version
> > number as supported by MG. On receiving such a message two scenarios can
> > be there:
> >    A. MGC supports a higher version of protocol as compared to MG
> >       - If MGC has a support for the lower version, then
> >       - it sends the ServiceChangeReply with the lower version
> >       - thereafter, all the messages between MG and MGC would
> >         contain the lower version and would only use the IE as
> >         specified in the lower version of the protocol.
> >     - else
> >       - it rejects the association request giving reason as version not
> > supported.
> >
> >    B. MG supports higher version of protocol.
> >
> >      - MGC on receiving a ServiceChange having a higher version would
> > send back a ServiceChange indicating its own version.
> >      (here it is being assumed that MGC is able to parse the
> > ServiceChange method as defined in the newer version, If while parsing
> >      ServiceChange command, MGC encounters some descriptors that it does
> > not recognize, then it will ignore those descriptors).
> >
> >      MGC after sending the reply can proceed assuming that MG would
> > switch to a lower version. if MG can not then MG anyway
> >      initiates the clearingof the association (see below)
> >
> >      - MG on receiving ServiceChange reply with the lower version can do
> > the following:
> >
> >      a) If it supports the lower version, then from that point it will
> > work on the lower version, that is it will send messages with version
> >      id as the lower version and use only those IE that are defined in
> > that lower version.
> >
> >      b) If MG does not support the lower version, then it will clear the
> > association by sending another ServiceChange to the MGC with
> >      ServiceChangeMethod as Forced and reason as "version not supported"
> > ------------------------------------------------------------------------
> >
> > Brian Rosen wrote:
> > >
> > > A number of issues were raised in the Washington meeting that
> > > were "send to the list".  This is one of these issues, with the
> > > problem and my suggested fix.
> > >
> > > Most of this text comes from a message from Nancy Greene
> > >
> > > Problem:
> > >
> > > What do you do when the MG and MGC differ in their versions?
> > >
> > > We reference RFC2145 as the place that defines the meaning of
> > > the major and minor version numbers. But we do not state
> > > anywhere in the protocol what happens when an MG/MGC receives
> > > a message with a higher version number than it supports.
> > >
> > > Our options:
> > > 1) the entity receiving the msg returns an error "version not
> > > supported". The other side must then resend the message with a
> > > lower version number (how does it know how low to go?). Probably
> > > need a way for the version to be negotiated or preprovisioned.
> > >
> > > 2) the entity notes the higher version number, but still tries to
> > > parse the transactions in the message - when it encounters a
> > > descriptor it does not support, it either a) ignores it or b)
> > > sends an error msg with the actual descriptor it could not
> > > understand in it.
> > >
> > > Proposed Solution
> > > 2)b)
> > >
> > > Brian

---

From: Christian Groves <[email-masked]>
Date: Mon, 22 Nov 1999 16:51:45 +0100

G'Day all,

I believe this should be in the base H.248 protocol specification.

I agree with Tom that the major and minor numbering needs to be
considered? Tom what would cause a minor re-numbering compared to a
major renumbering considered that we need to keep each version (minor or
major) backwards compatible.

Cheers, Christian

Tom-PT Taylor wrote:
> supports a higher minor version number than the other, the two ends
> should still be able to interwork, using the selective processing
> procedures defined in B. below.  If the major version numbers differ,
> we effectively have two different protocols and if one end can't drop
> down to the level of the other there can be no association.
>
>      > Harpeet's
>      text---------------------------------------------------------
>      >