<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META content="MSHTML 5.00.3013.2600" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT size=2><SPAN class=840411500-07032000>Another glitch with fast
connect...</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=840411500-07032000></SPAN></FONT> </DIV>
<DIV><FONT size=2><SPAN class=840411500-07032000>The OpenLogicalChannel
indicates in dataType.audioData the MAXIMUM payload size for the forward channel
to be opened. In non-fast start, the endpoint opening the channel would
obviously use the information it gathered in the terminal capability exchange in
order not to try to open a channel that would exceed's the receiver's
capabilities.</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=840411500-07032000></SPAN></FONT> </DIV>
<DIV><FONT size=2><SPAN class=840411500-07032000>In fastStart, there is no
terminal capability negotiation. The endpoint sending the SETUP message includes
the MAXIMUM payload size it can support in both direction since it can not guess
what are the capabilites of the receiver. The receiver has to "select" from the
list provided in the SETUP.</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=840411500-07032000></SPAN></FONT> </DIV>
<DIV><FONT size=2><SPAN class=840411500-07032000>Suppose that <EM>A </EM>calls
<EM>B </EM>using fast start. <EM>A </EM>has a big buffer and can support G.711
at up to 100 ms (send and receive). <EM>B</EM> can only support 20 ms. <EM>A
</EM>calls <EM>B</EM> using fastStart and advertizes 100 ms for both direction.
<EM>B </EM>has no choice but to reject the call, or to initiate H.245
tunnelling or a separate H.245 channel. This means to me that it can actually be
a disadvantage to advertize a bigger maximum payload size than the default
in fasStart. It also mean that fast start only has a reasonable chance of
working well if by chance the called party can handle an equal or larger payload
size than the originator.</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=840411500-07032000></SPAN></FONT> </DIV>
<DIV><FONT size=2><SPAN class=840411500-07032000>Any views on
this?</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=840411500-07032000></SPAN></FONT> </DIV>
<DIV><FONT size=2><SPAN class=840411500-07032000>One possibility is that the
receiving endpoint would be allowed to signal a SMALLER payload size in the OLC
it sends back to the originator. This would however mean a change to the
specification, and would potentially mean backward interoperability problems
since current implementations may not accept OLC contents that do not match what
was originally sent in the OLC in the SETUP message (they might reject the call,
or might ignore the changed values).</SPAN></FONT></DIV>
<DIV><FONT size=2><SPAN class=840411500-07032000></SPAN></FONT> </DIV>
<DIV><FONT size=2><SPAN class=840411500-07032000>The other possibility is for
the sender of the SETUP message to advertize multiple payload size as
alternative OLCs. While it would be possible in some cases to completely
describe one's capabilities without creating huge fastStart messages (eg.,
G.723-30 ms, G.723-60 ms), it may not be practical for others (e.g., G.711-100
ms, G.711-99 ms, G.711-98 ms, ... down to 1 ms). This would mean that in some
cases, you might be restricted to only a few (maybe advertize the maximum and
the default). Maybe a trick would be to advertize always at least the default
(20 ms) if supported, and the maximum if different.</SPAN></FONT></DIV>
<DIV> </DIV>
<DIV><FONT size=2><SPAN class=840411500-07032000>In any case, I think we should
clarify the procedures.</SPAN></FONT></DIV>
<P><FONT face=Courier><FONT size=1>-----<BR>François Audet Tel:+1 408 565
5675 <A href="mailto:audet@NortelNetworks.com"
target=_blank>mailto:audet@NortelNetworks.com</A><BR>Nortel Networks Fax:+1 408
565 2375 <A href="http://www.nortelnetworks.com/"
target=_blank>http://www.NortelNetworks.com</A></FONT></FONT><FONT size=1><FONT
face=Courier> </FONT></FONT></P>
<DIV> </DIV></BODY></HTML>