H.245 Terminates Fast Connect

Paul E. Jones paulej at PACKETIZER.COM
Tue Jun 13 21:40:28 EDT 2000


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 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


> 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 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
>
>
> 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 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 mailing list