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@NortelNetworks.com
Nortel Networks Fax:+1 408
565 2375 http://www.NortelNetworks.com