From: Paul E. Jones
Pete,
We do have one more Rapporteur's meeting, so we can try to introduce some
corrective text to address this issue and then put that forward as a delayed
contribution or a Rapporteur's TD (latter preferred if we can come to an
agreement).
I may be missing your point in (2), but perhaps this will address the
question: H.323v2 says that if an endpoint initiates H.245 (tunneled or a
separate connection) before getting a response to Fast Connect, Fast Connect
is terminated. However, there is no such rule with H.323v3/4. An H.323v2
device could initiate a Fast Connect call and then send an H.245 message to
a V3 device to terminate Fast Connect, but the V3 device would not recognize
that as a termination of Fast Connect. Thus, we have two devices that are
out of sync.
Between two V2 devices, we have a race condition, because one side could
send an H.245 message to terminate FC, while the other side returns a
message with fastStart to accept Fast Connect. Again, the two are out of
sync. This is what we tried to address by removing the text, but we did not
address the V2/V3 interoperability issue. So, we still have a potential
problem.
We could resolve this by simply stating noting the V2 behavior and
discouraging a V3+ device from sending an H.245 message to a V2 device prior
to learning whether FC was accepted. As a worst case, if it did send an
H.245 message, it should assume that it is terminating Fast Connect in the
V2 device and that a race condition may exist.
For V3 and V4, FC is not terminated in this way as the text now stands--
endpoints are free to start H.245 in parallel. In addition, fast connect
can be explicitly rejected, which gives an endpoint the "go ahead" to do
logical channel signaling to get audio and video channels open prior to
CONNECT.
There may be additional, more complex issues-- I may be over-simplifying the
interoperability issues here in this reply. It seems simple on the surface,
but I know that I have heard from more than one vendor that they were not
happy with these changes. However, I think that if we could add some
explanatory text to H.323v3/4 to describe the V2 behavior and document the
issues, I think we can move forward with the text as it is now, but I do not
want to make that conclusion without others also taking a serious look at
this issue.
Paul
----- Original Message -----
From: "Pete Cordell" <pete(a)TECH-KNOW-WARE.COM>
To: <ITU-SG16(a)mailbag.cps.intel.com>
Sent: Tuesday, June 13, 2000 9:39 AM
Subject: Re: H.245 Terminates Fast Connect
> 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(a)tech-know-ware.com
> +44 1473 635863
> =============================================
>
> ----- Original Message -----
> From: Paul E. Jones <paulej(a)PACKETIZER.COM>
> To: <ITU-SG16(a)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(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
