FastStart and payload size

Francois Audet audet at NORTELNETWORKS.COM
Fri Mar 10 13:35:11 EST 2000


Another glitch with fast connect...
 
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.
 
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.
 
Suppose that A calls B using fast start. A has a big buffer and can support
G.711 at up to 100 ms (send and receive). B can only support 20 ms. A calls
B using fastStart and advertizes 100 ms for both direction. B 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.
 
Any views on this?
 
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).
 
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.
 
In any case, I think we should clarify the procedures.

-----
François Audet  Tel:+1 408 565 5675 mailto:audet at NortelNetworks.com
<mailto:audet at NortelNetworks.com> 
Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com
<http://www.nortelnetworks.com/>  

 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000310/e0076a71/attachment-0003.html>


More information about the sg16-avd mailing list