Pete,
We do have one more Rapporteur's meeting, so we can try to introduce some corrective text to address this issue and then put that forward as a delayed contribution or a Rapporteur's TD (latter preferred if we can come to an agreement).
I may be missing your point in (2), but perhaps this will address the question: H.323v2 says that if an endpoint initiates H.245 (tunneled or a separate connection) before getting a response to Fast Connect, Fast Connect is terminated. However, there is no such rule with H.323v3/4. An H.323v2 device could initiate a Fast Connect call and then send an H.245 message to a V3 device to terminate Fast Connect, but the V3 device would not recognize that as a termination of Fast Connect. Thus, we have two devices that are out of sync.
Between two V2 devices, we have a race condition, because one side could send an H.245 message to terminate FC, while the other side returns a message with fastStart to accept Fast Connect. Again, the two are out of sync. This is what we tried to address by removing the text, but we did not address the V2/V3 interoperability issue. So, we still have a potential problem.
We could resolve this by simply stating noting the V2 behavior and discouraging a V3+ device from sending an H.245 message to a V2 device prior to learning whether FC was accepted. As a worst case, if it did send an H.245 message, it should assume that it is terminating Fast Connect in the V2 device and that a race condition may exist.
For V3 and V4, FC is not terminated in this way as the text now stands-- endpoints are free to start H.245 in parallel. In addition, fast connect can be explicitly rejected, which gives an endpoint the "go ahead" to do logical channel signaling to get audio and video channels open prior to CONNECT.
There may be additional, more complex issues-- I may be over-simplifying the interoperability issues here in this reply. It seems simple on the surface, but I know that I have heard from more than one vendor that they were not happy with these changes. However, I think that if we could add some explanatory text to H.323v3/4 to describe the V2 behavior and document the issues, I think we can move forward with the text as it is now, but I do not want to make that conclusion without others also taking a serious look at this issue.
Paul
----- Original Message ----- From: "Pete Cordell" pete@TECH-KNOW-WARE.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Tuesday, June 13, 2000 9:39 AM Subject: Re: H.245 Terminates Fast Connect
Paul,
Two things...
- 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.
- 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.comFor 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