<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: On TD26 - Fast TCS and M/S negotiation in H.323v4</TITLE>
<META content="text/html; charset=windows-1252" http-equiv=Content-Type>
<META content="MSHTML 5.00.3013.2600" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial>Francois,</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial>But the possibility exists that a V2 device may accept
both, reject one or the other, or reject both since a SETUP containing fastStart
and tunneled H.245 is "illegal". Heck, a "strict" endpoint may even drop
the call, but I suspect that nobody would go that far.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial>If fastStart was accepted and the remote end returns the
tunneling flag set to TRUE, how do you know if it did or did not process the
H.245 message in the SETUP? I'm not convinced that this procedure is going
to make everybody happy. (Same could be said if fastStart is not accepted,
I suppose.)</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial>My concern is that this issue is potentially damaging to
some implementations. If all of the vendors have no problem with this
change, then I can live with it. Cisco has no objection, but I would like
to solicit the input of others-- changes like this, even as good as they are,
could cause serious problems.</FONT></DIV>
<DIV><FONT face=Arial></FONT> </DIV>
<DIV><FONT face=Arial>It appears that we've already made a similar "mistake" by
allowing H.245 procedures to be done in parallel to fastConnect by removing the
clause that says that if we start H.245, fast connect is terminated. That
text was removed, because there was a race condition that could occur, which
could result in interoperability problems. The right solution probably
should have been to document the race condition and tell people "don't do
that". However, we made the change and now some manufacturers have serious
backward compatibility problems. I don't want to make the same mistake
again.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial>Comments?</FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=Arial>Paul</FONT></DIV>
<DIV> </DIV>
<BLOCKQUOTE
style="BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
<DIV style="FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV
style="BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: black"><B>From:</B>
<A href="mailto:audet@nortelnetworks.com"
title=audet@nortelnetworks.com>Francois Audet</A> </DIV>
<DIV style="FONT: 10pt arial"><B>To:</B> <A
href="mailto:paulej@packetizer.com" title=paulej@packetizer.com>'Paul E.
Jones'</A> ; <A href="mailto:ITU-SG16@mailbag.cps.intel.com"
title=ITU-SG16@mailbag.cps.intel.com>Mailing list for parties associated with
ITU-T Study Group 16</A> ; <A href="mailto:pete@TECH-KNOW-WARE.COM"
title=pete@TECH-KNOW-WARE.COM>pete</A> </DIV>
<DIV style="FONT: 10pt arial"><B>Cc:</B> <A
href="mailto:sasha@radvision.rad.co.il"
title=sasha@radvision.rad.co.il>Alexander (Sasha) Ruditsky</A> ; <A
href="mailto:dskran@sonusnet.com" title=dskran@sonusnet.com>Dale Skran</A>
</DIV>
<DIV style="FONT: 10pt arial"><B>Sent:</B> Monday, May 29, 2000 11:00 PM</DIV>
<DIV style="FONT: 10pt arial"><B>Subject:</B> RE: On TD26 - Fast TCS and M/S
negotiation in H.323v4</DIV>
<DIV><BR></DIV>
<P><FONT size=2>Yes, a few comments:</FONT> <BR><FONT size=2>1 It seems that
all current implementations that we could think of </FONT><BR><FONT
size=2> would simply ignore the tunnelling information if the fastStart
</FONT><BR><FONT size=2> element is present. This means, that there
would be no </FONT><BR><FONT size=2> interoperability problems. Fast
start would be sucessfull, but not</FONT> <BR><FONT size=2> tunnelling,
which would mean that tunnelling would have to happen</FONT> <BR><FONT
size=2> after the SETUP message, as per H.323v2 and v3.</FONT> <BR><FONT
size=2>2 There is a small possibility that an implementation would acutally
</FONT><BR><FONT size=2> give priority to the tunnelling information
instead of the fastStart</FONT> <BR><FONT size=2> element (v2 and v3
don't say what would happen if they are present, they</FONT> <BR><FONT
size=2> just say not to do it). In that particular case, the fastStart
would fail</FONT> <BR><FONT size=2> but the tunnelling would be
successful. So the worst case scenario is that</FONT> <BR><FONT size=2>
fastStart fails, but "fast tunnelling" is successful. This doesn't seem to
</FONT><BR><FONT size=2> me to be a real interoperability problem. In
any case, it seems that case</FONT> <BR><FONT size=2> 1 is much more
likely.</FONT> </P><BR>
<P><FONT size=2>> -----Original Message-----</FONT> <BR><FONT size=2>>
From: Paul E. Jones [<A
href="mailto:paulej@packetizer.com">mailto:paulej@packetizer.com</A>]</FONT>
<BR><FONT size=2>> Sent: Monday, May 29, 2000 7:46 PM</FONT> <BR><FONT
size=2>> To: Mailing list for parties associated with ITU-T Study
</FONT><BR><FONT size=2>> Group 16; pete</FONT> <BR><FONT size=2>> Cc:
Audet, Francois [SC9:4K02:EXCH]; Alexander (Sasha) Ruditsky; Dale</FONT>
<BR><FONT size=2>> Skran</FONT> <BR><FONT size=2>> Subject: Re: On TD26
- Fast TCS and M/S negotiation in H.323v4</FONT> <BR><FONT size=2>>
</FONT><BR><FONT size=2>> </FONT><BR><FONT size=2>> Pete, Sasha,
Francois, Dale, et al,</FONT> <BR><FONT size=2>> </FONT><BR><FONT
size=2>> I have concerns about this document that differ from Pete's.
</FONT><BR><FONT size=2>> However, since</FONT> <BR><FONT size=2>>
discussion on this document has started, I thought I might as </FONT><BR><FONT
size=2>> well express</FONT> <BR><FONT size=2>> my concerns now while
the material is fresh on people's minds.</FONT> <BR><FONT size=2>>
</FONT><BR><FONT size=2>> The issue has to do with the very first sentence
of the </FONT><BR><FONT size=2>> proposal, which says</FONT> <BR><FONT
size=2>> to strike "shall not" and replace it with "may". So, V2
</FONT><BR><FONT size=2>> devices shall not</FONT> <BR><FONT size=2>>
send a fastStart element and an H.245 message in SETUP, but </FONT><BR><FONT
size=2>> V4 may. This</FONT> <BR><FONT size=2>> seems to be a
serious backward compatibility issue. If a V2 </FONT><BR><FONT
size=2>> device were to</FONT> <BR><FONT size=2>> receive a SETUP
containing fastStart and an encapsulated </FONT><BR><FONT size=2>> H.245
message, what</FONT> <BR><FONT size=2>> would it do? I believe the
behavior is not defined.</FONT> <BR><FONT size=2>> </FONT><BR><FONT
size=2>> Would somebody like to comment?</FONT> <BR><FONT size=2>>
</FONT><BR><FONT size=2>> Paul</FONT> <BR><FONT size=2>>
</FONT><BR><FONT size=2>> ----- Original Message -----</FONT> <BR><FONT
size=2>> From: "Pete Cordell" <pete@TECH-KNOW-WARE.COM></FONT>
<BR><FONT size=2>> To: <ITU-SG16@mailbag.cps.intel.com></FONT>
<BR><FONT size=2>> Sent: Saturday, May 20, 2000 1:57 PM</FONT> <BR><FONT
size=2>> Subject: On TD26 - Fast TCS and M/S negotiation in H.323v4</FONT>
<BR><FONT size=2>> </FONT><BR><FONT size=2>> </FONT><BR><FONT
size=2>> > I note that TD-26 has been accepted to show how TCS can be
</FONT><BR><FONT size=2>> conveyed in</FONT> <BR><FONT size=2>> >
parallel with fast start.</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT
size=2>> > However, the example shows the use of call proceeding for
</FONT><BR><FONT size=2>> receiving TCS</FONT> <BR><FONT size=2>>
back</FONT> <BR><FONT size=2>> > from the remote endpoint. This is
not typically an </FONT><BR><FONT size=2>> end-to-end message,</FONT>
<BR><FONT size=2>> and</FONT> <BR><FONT size=2>> > therefore how the
procedure works with the gatekeeper </FONT><BR><FONT size=2>> routed model
needs</FONT> <BR><FONT size=2>> to</FONT> <BR><FONT size=2>> > be
addressed.</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> >
Possible solutions are:</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT
size=2>> > 1. Refer to the new text that says it is the responsibility
of the</FONT> <BR><FONT size=2>> > gatekeeper to forward any tunnelled
message for which none </FONT><BR><FONT size=2>> is available</FONT>
<BR><FONT size=2>> > using FACILITY. (There might be some
objection from some to using a</FONT> <BR><FONT size=2>> > facility
message this early in the call setup process though.)</FONT> <BR><FONT
size=2>> ></FONT> <BR><FONT size=2>> > 2. Restrict the tunnelling
(and probably the fast start </FONT><BR><FONT size=2>> info) to
Alerting,</FONT> <BR><FONT size=2>> > Connect and Facility, which
generally are end-to-end. I </FONT><BR><FONT size=2>> believe this
is</FONT> <BR><FONT size=2>> > compatible with the latest procedures for
deciding when </FONT><BR><FONT size=2>> fast start has</FONT> <BR><FONT
size=2>> been</FONT> <BR><FONT size=2>> > ignored.</FONT> <BR><FONT
size=2>> ></FONT> <BR><FONT size=2>> > Which ever option is
chosen, it would also be nice to have </FONT><BR><FONT size=2>> a picture
for</FONT> <BR><FONT size=2>> it</FONT> <BR><FONT size=2>> >
also!</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> >
Pete</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT size=2>> >
=============================================</FONT> <BR><FONT size=2>>
> Pete Cordell</FONT> <BR><FONT size=2>> >
pete@tech-know-ware.com</FONT> <BR><FONT size=2>> >
=============================================</FONT> <BR><FONT size=2>>
></FONT> <BR><FONT size=2>> > </FONT><BR><FONT size=2>>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</FONT>
<BR><FONT size=2>> > For help on this mail list, send "HELP ITU-SG16" in
a message to</FONT> <BR><FONT size=2>> >
listserv@mailbag.intel.com</FONT> <BR><FONT size=2>> ></FONT> <BR><FONT
size=2>> </FONT><BR><FONT size=2>> </FONT></P></BLOCKQUOTE></BODY></HTML>