Re: [codec] #16: Multicast?

"Raymond (Juin-Hwey) Chen" <> Mon, 10 May 2010 19:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2C4B28C3B7 for <>; Mon, 10 May 2010 12:27:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.113
X-Spam-Status: No, score=-0.113 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uteFLUajWgrW for <>; Mon, 10 May 2010 12:27:26 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 15ABF28C1F3 for <>; Mon, 10 May 2010 12:11:55 -0700 (PDT)
Received: from [] by with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 10 May 2010 12:11:33 -0700
X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031
Received: from ([]) by ([]) with mapi; Mon, 10 May 2010 12:12:56 -0700
From: "Raymond (Juin-Hwey) Chen" <>
To: Koen Vos <>
Date: Mon, 10 May 2010 12:11:32 -0700
Thread-Topic: [codec] #16: Multicast?
Thread-Index: Acrvv780XCFpA/L3T9e9ynvyOmGX6gAsFXmw
Message-ID: <>
References: <> <> <> <> <> <000001cae173$dba012f0$92e038d0$@de> <> <001101cae177$e8aa6780$b9ff3680$@de> <> <002d01cae188$a330b2c0$e9921840$@de> <> <> <> <002c01cae939$5c01f400$1405dc00$@de> <>, <009901caede1$43f366d0$cbda3470$@de> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
MIME-Version: 1.0
X-WSS-ID: 67F685EF38O203136089-01-01
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: Mon, 10 May 2010 19:27:27 -0000

Hi Koen,

> All in all I'm happy with the current requirements document, and it's  
> unclear what specific changes (besides a Bluetooth mode) you have in  
> mind...?

Correction: I never argued that we should add a "Bluetooth mode".  My main point in this area is just that there are complexity-sensitive applications such as low-end devices and VoIP gateways where a low codec complexity is important or even necessary.  In other words, if the IETF codec complexity is too high, then either it will become much more expensive for some applications (e.g. gateways), or it may not even be feasible to put the codec in some low-end devices.  Bluetooth headset was merely given as an example.  

Considering that there are a very large number of Bluetooth headset users and that the current Bluetooth headsets can already be used for making VoIP phone calls, it would be great if the IETF codec can be implemented in future Bluetooth headsets to avoid the additional coding distortion and delay associated with transcoding. However, with that said, I didn't mean to push a "Bluetooth mode" for the IETF codec. I merely wanted to use Bluetooth headset as an example to make a point that a low codec complexity is desirable and a high codec complexity can have negative consequences.