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

Anatoli Levine alevine at RADVISION.COM
Thu Jun 1 14:29:00 EDT 2000

Paul, list,

I have some relevant questions:

Is there today an implementation of the H.323 v2 which will break if it receive
both tunneled H.245 message and fast start element in the SETUP? Does anyone
plan to produce purposefully such an implementation? Does anyone checks
specifically for this combination in order to ignore such SETUP message? I would
assume most of the implementations will pick one or another (I think fast start
has an advantage here), and some of them will be happy with both. I think this
"full SETUP" has the big advantage and we should go ahead with this.


Paul Long wrote:

> 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
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: alevine.vcf
Type: text/x-vcard
Size: 306 bytes
Desc: Card for Anatoli Levine
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000601/f674011c/attachment-0006.vcf>

More information about the sg16-avd mailing list