Subject: Profile and version in ServiceChange Descriptor

From: Sachin Mittal <[email-masked]>
Date: Wed, 2 Feb 2000 10:43:02 +0530

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 ?

This might have been asked before but i am not able to find any.

---

From: Harpreet Singh Anand <[email-masked]>
Date: Wed, 2 Feb 2000 11:27:48 +0530

Hello,

> 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

---

From: Abdallah Rayhan <[email-masked]>
Date: Wed, 2 Feb 2000 09:17:11 -0500

Profile version is different than protocol version. Protocol version is
for the protocol syntax, semantics, functionality while profile is for the
application of the protocol, MG IP phone is an application that would
have a profile version,
<ftp://standards.nortelnetworks.com/megaco/docs/Wash99/draft-ietf-megaco-ipphone-01.txt>

Profile in service change need not be used if no profile is not specified.
Version in service change is used when changing the running version
of the protocol, e.g., upgrading, downgrading.

Abdallah Rayhan

---

From: Abdallah Rayhan <[email-masked]>
Date: Wed, 2 Feb 2000 09:36:41 -0500

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

---

From: Chuong Nguyen <[email-masked]>
Date: Wed, 2 Feb 2000 11:33:18 -0600

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

--
  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: Abdallah Rayhan <[email-masked]>
Date: Thu, 3 Feb 2000 09:42:00 -0500

This is something that be decided in future releases of MEGACO IMO. For
example
V2, V3, .... could state that V1 is a common negotiation version. In
this case,
version negotiation would always happen in V1. In V1, we have the
insight to provide the
mechanism to accomplish this. However, different versions may resort to
different
mechanisms. Therefore, rather than binding this requirement in this
draft and
forcing it on all future releases of the protocol, let future versions
worry about how
compatibility issues are resolved.

Abdallah Rayhan

Chuong Nguyen wrote:

> 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.
>
> 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