Re: [codec] #16: Multicast?

["Raymond (Juin-Hwey) Chen" <[e-mail]>]

On Saturday, April 24, 2010 at 4:37 PM, Stephen Botzko wrote:

>>>
   Sure - for certain frame sizes.  But 1 ms frames won't give you 5 ms one-way delay.
>>>
> Agreed, this delay model is too simplisti to be useful.
> There's algorithmic delay (including framing) + flight time + dejittering.  Flight time depends on the > network path, not on the frame size.  And the amount of jitter is due principally to cross-congestion.
I also agree.  See my last email.   My main point was not the absolute one-way delay value for the 5 ms frame size but the relative delay between 5 ms and 20 ms frame sizes.  I agree that the 5X delay might be too simplistic.  I tried to use a simple formula to make it is easier for people to follow, but I did realize its limitation especially at a small frame size, so I added that "Even if you use a longer jitter buffer, ..." sentence.
Regardless of whether 5X frame size is overly simplistic, the fact remains that cellular codecs have a 20 ms frame size and have a typical one-way delay around 80 to 110 ms or so, and the cellular networks probably don't have the kind of jitter that the Internet has.  What would make us believe that an IETF codec with a 20 ms frame size will get a one-way delay much below 80 ms?  Chances are an Internet call using an IETF codec with a 20 ms frame size will likely have a one-way delay at least as long as the one-way delay of a cell phone call, and more likely to be longer, because PC audio driver software tends to add quite a bit of delay, and an Internet call incurs additional jitter buffer delay when compared with cell phone calls.
Therefore, regardless of the accuracy of the 5X frame size formula, the conclusion remains the same: for the conference bridge application, a 20 ms codec frame size will result in the total one-way delay far exceeding the ITU-T's 150 ms guideline, thus substantially degrading the perceived quality of the communication links, and with one or even two cell phone callers joining the conference, the long latency and the associated problems will just get much worse.  Therefore, it is necessary for the IETF codec to have a low-delay mode using a small codec frame size such as 5 ms to address delay-sensitive applications such as bridge-based conference calls.
Raymond