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

Paul Long Plong at SMITHMICRO.COM
Wed Jun 7 03:51:01 EDT 2000


Paul,

An EP that thinks that Alerting-without-fastStart indicates FC has been
rejected is clearly making a false assumption.

You know, if EPs would just start using an empty fastStart component in all
responses up to Connect to indicate rejection of FC, we'd solve this problem
once and for all. No more waiting until Connect to determine if FC is
supported. No more worrying about terminating FC by using H.245. It is
already inherent in H.323 that an empty fastStart essentially indicates
rejection of FC, so we just need to add words to v4 and the v3IG admonishing
an EP to encode an empty fastStart if it doesn't support FC (or knows that
it will eventually reject FC) instead of waiting until Connect to not encode
fastStart.

Paul Long
Smith Micro Software, Inc.
"Primum non nocere"


-----Original Message-----
From: Paul E. Jones [mailto:paulej at PACKETIZER.COM]
Sent: Wednesday, June 07, 2000 1:44 AM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4


Bob,

That text in section 8.2.1 has been removed via the Implementers Guide.
There were a few issues with the text as it was, with a "race condition"
being the most notable.

If an aggressive endpoint sends a SETUP w/ fastStart and the other end
returns Alerting without fastStart, the calling endpoint may assume that
FC
was rejected, so it sends a Facility with H.245 messages.  Then (perhaps
at
the same time), the called endpoint returns CONNECT with fastStart...
now,
what state are things in?  The caller thought that it terminated FC and
the
called party thinks that FC was accepted.

One could say "the caller should then recognize that FC was indeed
accepted", but it defeats the purpose of "terminating FC".  The reason
for
that text was so that the calling EP could do its best to try to get the
H.245 tunnel up and channels open before CONNECT-- we could get into a
terrible mess.

Now, there could be work-arounds to this issue, but I believe that the
procedural explanation to work-around the race condition may be far
worse.
However, I am not opposed to a work-around.  Apparently, the removal of
that
text has caused some confusion, so it may be worth reinstating that text
and
defining some general guidelines.

However, we need to think through this carefully.  Contributions are
definitely solicited :-)  We could leave the text as it is in the IG
(which
I believe fixes the issues) or we could reinstate the text and provide
some
guiding text (which may reduce incompatibilities with V2 equipment).

Paul

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



More information about the sg16-avd mailing list