H.245 Terminates Fast Connect

Paul E. Jones paulej at PACKETIZER.COM
Tue Jun 13 06:17:24 EDT 2000


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



More information about the sg16-avd mailing list