Re: FastStart and payload size
Yep, you are right: it has always been the maximum size. The difference is that if you have capability negotiation before (non fast-start), it is understood that you would attempt to indicate a larger maximum size in the OpenLogicalChannel than what was indicated in the terminal capability negotiation.
Also, I would guess that "fixed sized" payload (let say in increments of 10 ms) may be less demanding on the hardware or DSP.
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.
Francois, Paul,
For the cost of no more than half a round-trip time you could forget about fastStart and do everything using tunnelled H.245 (which was always the better "fast starting" idea, and was originally put up as an alternative to what you're describing as "half-baked" - don't ask ME why both ended up getting standardized!). I believe you can tunnel TCS & MSDet in Setup, and TCS, MSDetAck and OLC into CallProceeding - stick an OLC or two into a (caller to callee) Facility message and you're quite likely to have everything ready to go by the time Connect happens! If we can make this standard practice we might even (with luck) eventually be able to deprecate fastStart rather than forever patching it... Except that then certain people will get upSET... (Sorry: couldn't resist that one!)
Regards, Chris
Francois Audet wrote:
Yep, you are right: it has always been the maximum size. The difference is that if you have capability negotiation before (non fast-start), it is understood that you would attempt to indicate a larger maximum size in the OpenLogicalChannel than what was indicated in the terminal capability negotiation.
Also, I would guess that "fixed sized" payload (let say in increments of 10 ms) may be less demanding on the hardware or DSP.
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.
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
Always liked that Chris Purvis fellow! Of course we all recall that certain people tried to SET things up so that fast start wouldn't be required in any standard context. Certain other people objected to that on moral grounds: one of whom is no longer with us, and one other of whom is now apparently seeing the light. Too bad the power's been turned off.
Dave.
-----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@MAILBAG.INTEL.COM]On Behalf Of Chris Wayman Purvis Sent: Monday, March 13, 2000 4:39 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: FastStart and payload size
Francois, Paul,
For the cost of no more than half a round-trip time you could forget about fastStart and do everything using tunnelled H.245 (which was always the better "fast starting" idea, and was originally put up as an alternative to what you're describing as "half-baked" - don't ask ME why both ended up getting standardized!). I believe you can tunnel TCS & MSDet in Setup, and TCS, MSDetAck and OLC into CallProceeding - stick an OLC or two into a (caller to callee) Facility message and you're quite likely to have everything ready to go by the time Connect happens! If we can make this standard practice we might even (with luck) eventually be able to deprecate fastStart rather than forever patching it... Except that then certain people will get upSET... (Sorry: couldn't resist that one!)
Regards, Chris
Francois Audet wrote:
Yep, you are right: it has always been the maximum size. The difference is that if you have capability negotiation before (non fast-start), it is understood that you would attempt to indicate a larger maximum size in the OpenLogicalChannel than what was indicated in the terminal capability negotiation.
Also, I would guess that "fixed sized" payload (let say in increments of 10 ms) may be less demanding on the hardware or DSP.
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.
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
participants (3)
-
Chris Wayman Purvis -
David Walker -
Francois Audet