FastStart and payload size

Paul Long plong at SMITHMICRO.COM
Fri Mar 10 14:41:20 EST 2000


Francois,

You are correct that your first solution would cause backward-compatibility
problems, because the called EP merely _selects_ which OLCs it wants to use.
>From the caller's proposed OLCs, it returns the ones that it accepts. It
cannot provide its own OLCs or otherwise modify the proposed OLCs. The
Recommendation is quite clear about this. I can quote from it, if necessary.
:-)

I'm afraid that the only solution is the second one you describe, but IMO it
is not necessary to provide every possible value within a range, e.g., 100,
99, 98, 97... From my experience at interops, it seems like G.711 framing is
limited to either 60, 30, 20, or 10ms frames, so that's what I would propose
in addition to your own 100ms maximum. (Note that for some EPs, this is not
their maximum framing but the _exact_ framing that you must use!)

Our EP currently just proposes one type of media per session ID (due to
another problem with FC). We propose G.723.1 and H.263. This is what our
fastStart looks like in order to overcome the problem you describe:

in G.723.1, maxframes 4, SS
out G.723.1, maxframes 4, SS
out G.723.1, maxframes 4, no SS
out G.723.1, maxframes 1, no SS
in H.263, SQCIF 1, QCIF 1, CIF 1, vTSTO
out H.263, SQCIF 1, QCIF 1, CIF 1, vTSTO
out H.263, QCIF 1, vTSTO
out H.263, QCIF 2, no vTSTO

Note that it's only necessary to provide maximum caps for incoming media,
because the called EP can always ignore features it does not support, e.g.,
SS and CIF, and undershoot your maximum framing. Once/if we support multiple
media per session ID, this is probably what it would look like:

in G.723.1, maxframes 4, SS
out G.723.1, maxframes 4, SS
out G.723.1, maxframes 4, no SS
out G.723.1, maxframes 1, no SS
in G.711, ALaw, maxFrames 200
out G.711, ALaw, maxFrames 60
out G.711, ALaw, maxFrames 30
out G.711, ALaw, maxFrames 20
out G.711, ALaw, maxFrames 10
in G.711, muLaw, maxFrames 200
out G.711, muLaw, maxFrames 60
out G.711, muLaw, maxFrames 30
out G.711, muLaw, maxFrames 20
out G.711, muLaw, maxFrames 10
in H.263, SQCIF 1, QCIF 1, CIF 1, vTSTO
out H.263, SQCIF 1, QCIF 1, CIF 1, vTSTO
out H.263, QCIF 1, vTSTO
out H.263, QCIF 2, no vTSTO
in H.261, QCIF 1, CIF 1, vTSTO
out H.261, QCIF 1, CIF 1, vTSTO
out H.261, QCIF 1, vTSTO
out H.261, QCIF 2, no vTSTO

(whew!)

Paul Long
Smith Micro Software, Inc.

-----Original Message-----
From: Francois Audet [mailto:audet at NORTELNETWORKS.COM]
Sent: Friday, March 10, 2000 12:35 PM
To: ITU-SG16 at MAILBAG.INTEL.COM
Subject: FastStart and payload size


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/>



More information about the sg16-avd mailing list