H.245 Terminates Fast Connect

[Pete Cordell]

Paul,

Two things...

1) 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.

2) 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 at tech-know-ware.com
+44 1473 635863
=============================================

----- Original Message -----
From: Paul E. Jones <paulej at PACKETIZER.COM>
To: <ITU-SG16 at 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 at mailbag.intel.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com