Subject: Re: Message Header w/Version

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 16 Aug 1999 08:26:42 -0500

This thread has gone on nearly a month now, so I thought I would summarize
it.  Doing so brought out a couple of new issues in my mind that people
might want to comment on.

The thread began with Brian's posting of 7/20/99 proposing that version be
put into the ServiceChange message only rather than every message, and
questioning whether we still support profile.

Along the way, the discussion got into a couple of side issues which seem to
have been resolved:

 - To permit MGC handoff, the MGC can also issue the ServiceChange message.
Issues of state synchronization appear to have been resolved satisfactorily
by noting that the protocol provides the necessary mechanisms, but the
actual method used is an implementation issue.

 - We will use the RFC 1006 TPKT mechanism to delineate messages in TCP
operation.

Getting back to the version issue:
 - The arguments for putting the version in every message are that it makes
for a cleaner separation of parsing from other parts of the implementation,
that other protocols do it, and that some application other than Megaco may
process Megaco messages independently of Megaco context.
 - The argument against putting the version in every message is the
perceived hit on performance.  This is supplemented by the proposition that
you need other association state information (besides version) to work with
incoming messages in any event.
 - There is NO argument with the proposition that we need a version
identifier at some point to allow protocol evolution.

I had one thought as I worked through this summary:

 - If the version is announced only in the ServiceChange message, does this
mean that the MG always controls the version to be used and that there is no
way for the MGC to negotiate it?  This has an implication for network
upgrade procedures which people may want to consider.

One final point: there has been no discussion of the profile ID issue.  The
word "profile" brings to my mind the idea of restrictions on the available
possibilities, rather than new forms which would be unknown to parsers.  As
such, it would be informatioin the receiver of a message would want the
sender to know, not vice versa.  Thus if we should have it at all, it should
be in the ServiceChange message and possibly its response.

---

From: David Oran <[email-masked]>
Date: Mon, 16 Aug 1999 10:46:21 -0400

A perhaps silly question:

If the version number is only in the service change message, then if the MG
and MGC ever get mis-synchronized (perhaps due to an earlier parsing or
protocol error), how does a parser reasonably figure out when it gets
confused by a message whether its confusion is due to a version mismatch or
something else. It strikes me that there's at least the potential for better
debugging and error reporting if every message is entirely self-describing.

Some (possibly debatable) philosophy:

Some things about a protocol need to be "held fixed" across evolutionary
changes or you lose backward compatibility. Putting the version number in
every message effectively "fixes" the format of the protocol up to the
version-number field for all time. Conversely, depending on the version
number in the service-change message fixes some aspects of the protocol
state machine for all time (i.e. must see a service change message before
you can interpret any other message). Which of these two things do we feel
more comfortable keeping constant for the life of the protocol? I have my
personal preference; maybe you can guess?

Dave.

> -----Original Message-----
> From: Media Gateway Control (megaco)
> [mailto:[email-masked]]On Behalf Of Tom-PT Taylor
> Sent: Monday, August 16, 1999 9:27 AM
> To: [email-masked]
> Subject: Re: Message Header w/Version
>
>

---

From: Abdallah Rayhan <[email-masked]>
Date: Tue, 17 Aug 1999 13:04:04 -0400

Question: What are the pros and cons of Version ?

pros:
1- Ability to change syntax and semantics of new versions of MEGACO
with the possibility of maintaining backward compatibility.
2- Less semantic/syntax constraints on how to process  messages.
3- Ability to differentiate between unsupported versions and syntax/semantic
errors

cons:
1- Few extra bytes( MEGACO/xx.xx)

It is obvious that pros of having Version in every message outweighs
the cons.

regards
Abdallah Rayhan

---

From: Christian Groves <[email-masked]>
Date: Wed, 18 Aug 1999 18:48:56 +1000

I agree with the pros and cons below as they relate to the question you
proposed however I don't see how you arrived at your conclusion of a
version in each message. No one argues against having a version
somewhere in the protocol and the pros can be acheived by both the
Service change and message version method. With the serviceChange method
Megaco/H248 doesn't take the extra byte/processing hit.

Perhaps also 'fixing' the protocol upto the version information field is
not good for future releases of the protocol which may want to add
information to the proceeding fields.

As ServiceChange is the first message and fixes the relationship between
an MC and MG the version supported is determined. If the relationship
changes another ServiceChange is issued with new information.

In the service change method the MG & MC retain what version they are
operating with. Surely in a Mis-alignment (what ever that is), parsing
error state, nuclear holocaust (wasn't IP designed for this?) etc the MG
is going to have trouble recognising anything coming across the line
(including where the version information is in a message), the locally
stored version is a good reference point.

Cheers, Christian