H.245 Terminates Fast Connect
Paul E. Jones
paulej at PACKETIZER.COM
Tue Jun 13 21:40:28 EDT 2000
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
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.
----- Original Message -----
From: "Callaghan, Robert" <Robert.Callaghan at icn.siemens.com>
To: "'Paul E. Jones'" <paulej at PACKETIZER.COM>
Cc: "'Mailing list for parties associated with ITU-T Study Group 16'"
<ITU-SG16 at mailbag.cps.intel.com>
Sent: Tuesday, June 13, 2000 9:22 AM
Subject: RE: H.245 Terminates Fast Connect
> If the agreement was clearly to remove the text, how can you not remove
> 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.
> Robert Callaghan
> Siemens Enterprise Networks
> Tel: +1.561.923.1756 Fax: +1.561.923.1403
> Email: Robert.Callaghan at ICN.Siemens.com
> -----Original Message-----
> From: Paul E. Jones [mailto:paulej at PACKETIZER.COM]
> Sent: Tuesday, June 13, 2000 6:17 AM
> To: ITU-SG16 at mailbag.cps.intel.com
> Subject: H.245 Terminates Fast Connect
> 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
> 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
> 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
> start using tunneling as described in 8.2.1. If H.245 transport address
> 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
> later initiates H.245 while at the same time, the called endpoint returns
> message with fastStart, what state is H.245 in?
> I believe that we can resolve the issues by documenting the fact that a
> condition exists and introducing a few new rules. For example, we could
> that if, as in this example above, the calling endpoint initiates H.245
> 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
> 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,
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com
More information about the sg16-avd