On TD26 - Fast TCS and M/S negotiation in H.323v4

[Paul Long]

Francois,

At worst, it will indeed "'break'" things" ("...a RELEASE COMPLETE
message...shall be returned"); at best, the behavior will be
implementation-dependent because H.323 disallows it ("...shall not include
both a fastStart element and encapsulated H.245 messages...").

(sigh) H.323 was intended to be extensible and backwards compatible. All
versions of H.323 are inherently compatible with all other versions of
H.323. Every single change that is considered for a new version of the
Recommendation must be considered in this light. So far, we've done a pretty
good job. Let's not create v4 as an isolated Recommendation that is not
backward compatible.

Setup is unique in that the transmitting EP cannot know the version of the
receiving EP before it sends it. Therefore, we cannot define purely
version-specific behavior for Setup. For other messages, e.g., Alerting and
OpenLogicalChannel, we can because, by the time these messages can be
transmitted, the transmitting EP knows the version of the receiving EP.
That's how we are generally able to make version-specific changes to H.225.0
and H.245.

BTW, relying on version-specific behavior creates insurmountable problems
with GKs that use the routed model, i.e., all GKs. Over time, as there are
more and more entities of different versions out in the field, and the
versioning-GW aspect of a GK becomes more critical, we will find that we
have painted ourselves into a corner unless we address the problem now. The
only solution I can see is to _never_ define purely version-specific
behavior--always signal/negotiate it. (Paul?)

Paul Long
Smith Micro Software, Inc.

-----Original Message-----
From: Francois Audet [mailto:audet at NORTELNETWORKS.COM]
Sent: Thursday, June 01, 2000 7:49 AM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4


> Paul,
>
> We agreed at the Osaka meeting to allow a SETUP to contain both the
> fastStart and h245Control, but it has not been officially
> approved by the
> ITU.
>
> As it stands right now, I don't think I can agree to include
> it in H.323v4
> on the grounds that it breaks backward compatibility with
> V2-- I just don't
> see a clean solution here.

It doesn't "break" anything. The call will still proceed.

> I'm opening to hearing more suggestions, but as you pointed
> out, there are
> two issues:
>   1) H.323v2 states explicitly that it is illegal

There are a lot of things that changed from v2 to v4. That's the role of

versions.

>   2) There is no way to know what version to destination EP is before
>      sending this illegal message

That would apply to any single change that we do on H.225.0 and H.245.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com