On TD26 - Fast TCS and M/S negotiation in H.323v4
Plong at SMITHMICRO.COM
Wed Jun 7 03:51:01 EDT 2000
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
Smith Micro Software, Inc.
"Primum non nocere"
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
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
was rejected, so it sends a Facility with H.245 messages. Then (perhaps
the same time), the called endpoint returns CONNECT with fastStart...
what state are things in? The caller thought that it terminated FC and
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
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
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
However, I am not opposed to a work-around. Apparently, the removal of
text has caused some confusion, so it may be worth reinstating that text
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
I believe fixes the issues) or we could reinstate the text and provide
guiding text (which may reduce incompatibilities with V2 equipment).
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