Re: FastStart and payload size
Hum... That kind of worries me.
It means that the burden is on the originating side to "guess" what the terminator is likely to support.
I also agree that practically speaking, implementations normally support multiples of 10 ms as the payload size (with the notable exeption of Netmeeting).
However, technically speaking, if you advertize 30 ms as the maximum payload size you can support, it implies that in order to comply with the H.323 specification, you would support any value between 0 ms (whatever it means) and 30 ms. I don't think many implementations could do this. But that is a separate issue.
In any case, if we all understand that the originator is responsible for accurately describing a decent subset of the capabilities it can support, we probably should describe this in the spec because I am convinced that most people will simply put the maximum payload size they can support...
-----Original Message----- From: Paul Long [mailto:plong@SMITHMICRO.COM] Sent: Friday, March 10, 2000 11:41 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: FastStart and payload size
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@NORTELNETWORKS.COM] Sent: Friday, March 10, 2000 12:35 PM To: ITU-SG16@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@NortelNetworks.com mailto:audet@NortelNetworks.com Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com http://www.nortelnetworks.com/
Francois,
(Worries me, too. I don't like Fast Connect. "Half-baked" comes to mind. Apologies to whoever the authors are...)
Exactly, the caller has to make a series of educated guesses regarding outgoing caps, based on the implementor's experience and common sense.
(Wait a minute. Let me get on my high horse... okay, I'm on... :-) These fields have always indicated _maximum_ framing. For example, if I indicate that I can receive packets containing as many as 20 frames per packet (for G.711, a frame happens to be 1ms in duration), that means you can send me packets containing 1, 20, 10, 2, 15, 8, etc., frames. Mix and match. Put a different number of frames in each successive packet if you want to. It doesn't matter. The _only_ constraint is that no packet may contain more than 20 frames. It has never meant that you can only send me 20 frames per packet for each and every packet, which for G.711 would be 20ms packets all the time. However, several vendors apparently have "extra-normative" technical constraints that they must deal with regarding packet size, i.e., DSPs that require being fed chunks of fixed-size audio, e.g., 20ms packets. But there is no way in H.245 and therefore H.323 to indicate a fixed-size packet. These vendors should either "fix" their DSPs or perform re-framing between transport and decoder. In our software-only implementation, we have a FIFO into which we shove all incoming audio frames. Once frames are installed in the FIFO, it doesn't matter where the packet boundary was. The decoder just processes frames in the order they were received. I'm sure that there are really good technical reasons why some implementations require fixed-size audio packets. Based on our perhaps too simplistic implementation, however, this has always puzzled me.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Francois Audet [mailto:audet@NORTELNETWORKS.COM] Sent: Friday, March 10, 2000 1:55 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: FastStart and payload size
Hum... That kind of worries me.
It means that the burden is on the originating side to "guess" what the terminator is likely to support.
I also agree that practically speaking, implementations normally support multiples of 10 ms as the payload size (with the notable exeption of Netmeeting).
However, technically speaking, if you advertize 30 ms as the maximum payload size you can support, it implies that in order to comply with the H.323 specification, you would support any value between 0 ms (whatever it means) and 30 ms. I don't think many implementations could do this. But that is a separate issue.
In any case, if we all understand that the originator is responsible for accurately describing a decent subset of the capabilities it can support, we probably should describe this in the spec because I am convinced that most people will simply put the maximum payload size they can support...
participants (2)
-
Francois Audet -
Paul Long