Paul,
Two things...
1) What will be the procedure used in Geneva to decide v4. Will we have the opportunity to put a delta document in? If we are, the correct (not necessarily sensible!) procedure is to have the white paper as agreed in Osaka, and un-do it (as a result of further information) in Geneva.
2) Fast start is limited to working on session IDs 1 and 2. As long as H.245 specifies other session IDs with its OLC I believe this can get around the alleged race condition. Does this make any sense?
Pete.
============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 =============================================
----- Original Message ----- From: Paul E. Jones paulej@PACKETIZER.COM To: ITU-SG16@mailbag.cps.intel.com Sent: 13 June 2000 11:17 Subject: H.245 Terminates Fast Connect
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com