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@PACKETIZER.COM] Sent: Wednesday, June 07, 2000 1:44 AM To: ITU-SG16@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@mailbag.intel.com