Re: [codec] #16: Multicast?

Cullen Jennings <> Tue, 18 May 2010 17:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA1CB3A6A91 for <>; Tue, 18 May 2010 10:37:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -107.555
X-Spam-Status: No, score=-107.555 tagged_above=-999 required=5 tests=[AWL=-1.856, BAYES_50=0.001, MANGLED_WRLDWD=2.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8SWBBTTTPqgA for <>; Tue, 18 May 2010 10:37:56 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E69003A6C4F for <>; Tue, 18 May 2010 10:34:28 -0700 (PDT)
Authentication-Results:; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAO5r8kurR7Hu/2dsb2JhbACeAXGlIJoAhRAEg0A
X-IronPort-AV: E=Sophos;i="4.53,256,1272844800"; d="scan'208";a="223027669"
Received: from ([]) by with ESMTP; 18 May 2010 17:34:21 +0000
Received: from [] ( []) by (8.13.8/8.14.3) with ESMTP id o4IHYKQ3009574; Tue, 18 May 2010 17:34:20 GMT
Mime-Version: 1.0 (Apple Message framework v1078)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <>
In-Reply-To: <>
Date: Tue, 18 May 2010 11:34:19 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <000001cae173$dba012f0$92e038d0$@de> <> <001101cae177$e8aa6780$b9ff3680$@de> <> <002d01cae188$a330b2c0$e9921840$@de> <> <> <> <> <> <> <> <07C815A7-> <>
To: Raymond Chen <>
X-Mailer: Apple Mail (2.1078)
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: Tue, 18 May 2010 17:37:57 -0000

On May 12, 2010, at 12:28 PM, Raymond (Juin-Hwey) Chen wrote:

> Hi Cullen,
> Hmm... That's interesting.  Would you please share more details of 
> your measurement equipment setup, the codec used, the codec frame 
> size, the number of codec frames in each packet, the way you 
> measured the delay, and the measured delay value, etc.?  

Sure - it's really simple to set up. I use a signal generator that makes a tone burst. Typically I do something like 550 Hz tone that is a 200 ms long burst that occurs once a second. I play this into a speaker near the microphone on one phone and also put it into 1 channel of a scope.  I think put a microphone near the speaker of the other phone and put that on another channel of the scope and measure the mouth to ear delay. It's really easy to see the starts of the two bursts from the speaker and microphone and measure the delay within a few ms. I've done lots of clever things over the years using stats from software in the phones but this technique is easy and pretty fool proof on getting good results. The phones were plugged into Netgear 100Mbps hub as I sometimes look at the timing of the ethernet packets too. I set up phones for G.711, one frame per packet - I choose this as  it is easy to change the length of each frame but results are similar with other codecs. 

I was using two Cisco 7960 phones - no idea what version of the software and may have been a development build but it's pretty unlikely that current production software would have different results from what I tested. I set the phones for G.711 with 20 ms packets, measured delay, then set the phones for 30 ms packets and measured delay. For a given packet length, when I make multiple phone calls or reboot one of the phones, the measurements stay consistent. 

The resulting change in delay between the two experiments was much less than 30ms that a (3x 30 ms - 3 x 20 ms) would have predicted. I feel like a total tool not providing the details of the exact measurements but lots of measurements like this Cisco considers confidential and I'm just not up to arguing with folks about what can and can not be said publicly. I probably should have done a test with 10 ms packets too but I did not. Yes I realize how nuts it is to consider something that anyone can easily measure as confidential. If anyone really cares, I will go do the work to be able to provide the numbers. 

> I didn't come up with this 3*(codec frame size) delay number for IP 
> phones myself.  A very senior technical lead in Broadcom's IP phone 
> chips group told me that, and Broadcom is currently the #1 world-
> wide market share leader in IP phone chips, accounting for more than 
> half of the world's IP phone chip shipments.
> Most of the world's 
> tier-1 IP phone manufacturers use our IP phone chips at least in 
> some of their product lines.

Yah, again, Cisco considers chipsets confidential but if you poke around with google,  such as

Folks claim the 7960 uses a Broadcom chip - of course that looks like it is for the ethernet switch on the phone not much to do with software that impacts audio latency. 

> I would be very interested to learn more about your measurements to 
> try to reconcile these seemingly contradictory statements from two 
> different sources.  Thanks.

Be glad to talk to whoever it is. I really don't know relevant this all is too figuring out what packets sizes we need to support.

> Best Regards,
> Raymond
> -----Original Message-----
> From: Cullen Jennings [] 
> Sent: Wednesday, May 12, 2010 8:00 AM
> To: Raymond (Juin-Hwey) Chen
> Cc: Koen Vos;
> Subject: Re: [codec] #16: Multicast?
> On May 4, 2010, at 7:15 PM, Raymond (Juin-Hwey) Chen wrote:
>> the 3*(codec frame size) delay is very real for IP phone
> This does not match the measurements I have. And I certainly don't have 100+ year voip experience but I do have two of the #1 selling enterprise phones connected to an oscilloscope. Test with other phones suggest most the major vendors of IP hard phones have fairly comparable performance when it comes to delay. 
> Cullen

Cullen Jennings
For corporate legal information go to: