RE: H.245 Terminates Fast Connect
Paul,
If the agreement was clearly to remove the text, how can you not remove it? This is true even if you have difficulties agreeing with the decision.
Yes there is a race condition, but only regarding the pending OLCs. A simple statement is that OLC activity cannot be done until the FastStart terminates or is explicity rejected. Other H.245 activity should be fine.
Bob
------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan@ICN.Siemens.com ------------------------------------------------------------------
-----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Tuesday, June 13, 2000 6:17 AM To: ITU-SG16@mailbag.cps.intel.com 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
Bob,
We can re-instate it by removing the text from the Implementers Guide :-) We have done that before. People do not like such changes in direction, but we have created quite a serious problem, because there are millions of H.323 devices out there now that assume that initiation of H.245 terminates Fast Connect.
We could leave the text as-is in the IG/H.323v4 and insert a note that mentions that an H.323v2 device assumed that Fast Connect was terminated when H.245 was initiated early and that a race condition existed in some cases. We could then provide some general guidelines under which we should operate when talking to an H.323v2 device. Would that be a better solution?
I'm open to suggestions. How we resolve these issues is not so important, but I believe it is important that we address how we will achieve interoperability between V2 and V3/V4 devices.
Paul
----- Original Message ----- From: "Callaghan, Robert" Robert.Callaghan@icn.siemens.com To: "'Paul E. Jones'" paulej@PACKETIZER.COM Cc: "'Mailing list for parties associated with ITU-T Study Group 16'" ITU-SG16@mailbag.cps.intel.com Sent: Tuesday, June 13, 2000 9:22 AM Subject: RE: H.245 Terminates Fast Connect
Paul,
If the agreement was clearly to remove the text, how can you not remove
it?
This is true even if you have difficulties agreeing with the decision.
Yes there is a race condition, but only regarding the pending OLCs. A simple statement is that OLC activity cannot be done until the FastStart terminates or is explicity rejected. Other H.245 activity should be fine.
Bob
Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan@ICN.Siemens.com
-----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Tuesday, June 13, 2000 6:17 AM To: ITU-SG16@mailbag.cps.intel.com 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
participants (2)
-
Callaghan, Robert -
Paul E. Jones