Folks,
As you know, we added some text to the H.323 Implementers Guide (section 6.1.7) removing the text from 8.2.1/H.323 that used to state:
``The sending of encapsulated H.245 messages or the initiation of the separate H.245 connection by either endpoint prior to the sending of a Q.931 message containing fastStart by the called endpoint terminates the Fast Connect procedures.''
There was also some further supporting text added to the IG, but removed before the final agreed document that read (this is somewhat out of date now that H.323v4 devices that use Fast Connect *shall* tunnel, but text is necessary for V2 and V3 entities): ``It is possible to switch to H.245 procedures before the Fast Connect procedure completes. If h245Tunneling is enabled, the terminating party may start using tunneling as described in 8.2.1. If H.245 transport address is included in the Setup message, then the terminating party may start the switch to H.245 as described in 8.2.3. In either case the Fast Connect procedure is terminated.''
Unfortunately, removing this text (particular the text that was already existing the H.323) has caused all kinds of grief, as there are implementations that do, in fact, behave according to this text found in H.323v2 and H.323v3. I know a few people have discussed reversing this decision, but no formal proposal has been submitted.
We need to have a discussion on this topic. I want to propose that the H.323v4 white paper *not* have this text removed. If people agree with that, I will bring a contribution that will propose reinstating this text.
Part of the reason for its removal is that there is a race condition that can occur. For example, if the caller sends a Setup with fastStart and then later initiates H.245 while at the same time, the called endpoint returns a message with fastStart, what state is H.245 in?
I believe that we can resolve the issues by documenting the fact that a race condition exists and introducing a few new rules. For example, we could say
that if, as in this example above, the calling endpoint initiates H.245 and then gets a fastStart element in a message, the caller shall recognize the fact that Fast Connect was accepted. Hopefully, no logical channel signaling will have taken place. If it has, the called party should reject any conflicting channels, so the calling endpoint can recognize that a rejected channel is the result of Fast Connect being accepted and the channel is actually open (as per the FC received).
I would like to see if we can come to any kind of agreement on this issue and a recommendation for a direction forward.
Best Regards, Paul
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com