Re: [codec] #16: Multicast?

"Raymond (Juin-Hwey) Chen" <> Sun, 25 April 2010 01:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A91CD3A6855 for <>; Sat, 24 Apr 2010 18:30:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.29
X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_50=0.001, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bgdumt0jFpcY for <>; Sat, 24 Apr 2010 18:30:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 10FE93A67A2 for <>; Sat, 24 Apr 2010 18:30:05 -0700 (PDT)
Received: from [] by with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Sat, 24 Apr 2010 18:29:44 -0700
X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201
Received: from ([]) by ([]) with mapi; Sat, 24 Apr 2010 18:31:08 -0700
From: "Raymond (Juin-Hwey) Chen" <>
To: stephen botzko <>, Koen Vos <>
Importance: low
X-Priority: 5
Date: Sat, 24 Apr 2010 18:29:42 -0700
Thread-Topic: [codec] #16: Multicast?
Thread-Index: AcrkBw4pMpf+gEl3QYWZ3Yo0uUVTXAACCHlw
Message-ID: <>
References: <> <000001cae173$dba012f0$92e038d0$@de> <> <001101cae177$e8aa6780$b9ff3680$@de> <> <002d01cae188$a330b2c0$e9921840$@de> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
MIME-Version: 1.0
X-WSS-ID: 67CD448231G102660943-01-01
Content-Type: multipart/alternative; boundary="_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A28BIRVEXCHCCR01c_"
Cc: "" <>
Subject: Re: [codec] #16: Multicast?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 25 Apr 2010 01:30:07 -0000

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.