Re: [codec] #16: Multicast?

stephen botzko <> Fri, 30 April 2010 13:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 29B623A6C0B for <>; Fri, 30 Apr 2010 06:41:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.01
X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3DYoBOTH-VZo for <>; Fri, 30 Apr 2010 06:41:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 825F83A6BF7 for <>; Fri, 30 Apr 2010 06:41:20 -0700 (PDT)
Received: by wwb24 with SMTP id 24so163233wwb.31 for <>; Fri, 30 Apr 2010 06:41:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=LB/pRf52XSrQuHo1LcwEA2ZX/dWZRnExYPOBMbmXTQQ=; b=Vb+nm+B186hGWGO4zT8H/Z/2ZyplpuX3WqyjQy6N3iTqC6hqncWJbwUioyi6R2d6pT wtXuBEzp3KuBo0LvVU+FUyEu17b12dRzqDb+8CFqmLxIZB7Foo0/DhH2/qsTJPMOkOo3 kUui8BSFeN+FWEaNHNbUEB1kx7QhD5zieU4tI=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QKJea0r8XIPbSnz7CIBYVSrujOFsX/pLBxHGs9nTHBJm7wV9jkdph/o3JSS2FxNAMw 0mHL7A2Eykdz74hgBf0B89LmL6CiCrXv/4hvk+h1wv/qVF4KOqrI6338nCPNqDzv5L72 DqZLqapUL2PxxPnNP8dfuJTNTRzLY2UBPbdBY=
MIME-Version: 1.0
Received: by with SMTP id w54mr693345wel.213.1272634861792; Fri, 30 Apr 2010 06:41:01 -0700 (PDT)
Received: by with HTTP; Fri, 30 Apr 2010 06:41:01 -0700 (PDT)
In-Reply-To: <006c01cae85f$e45df360$ad19da20$@de>
References: <> <001101cae177$e8aa6780$b9ff3680$@de> <> <002d01cae188$a330b2c0$e9921840$@de> <> <> <> <> <> <006c01cae85f$e45df360$ad19da20$@de>
Date: Fri, 30 Apr 2010 09:41:01 -0400
Message-ID: <>
From: stephen botzko <>
To: Christian Hoene <>
Content-Type: multipart/alternative; boundary="001485f1d92addee380485746480"
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: Fri, 30 Apr 2010 13:41:24 -0000

Hi Christian

I agree that Wireless IP is in scope, one could also argue that LTE might be
in scope, since it will be using IPv6.

As we all know, the internet runs over multiple physical layers, and usually
an end-to-end connection uses more than one physical layer.  So I am not
sure how we can translate layer 2 constraints into requirements for CODEC

I can see how it might impact the RTP packetization - allowing frames to be
split across packets would allow media-aware devices to adjust the
packetization to optimize delivery.

BTW, I am a bit puzzled by the G.722 statement, since it can run at a 7.5 ms
packet delivery schedule (using 60 payload bytes per packet).

Stephen Botzko

On Fri, Apr 30, 2010 at 8:23 AM, Christian Hoene <>wrote:

> Hi,
> I just want to share some insights from the recent development of
> Bluetooth's Hands-Free Profile (HFP) version 1.5, which supports
> wideband speech.  One main requirement were on the frame size of 7.5 ms
> because the Bluetooth MAC protocol support scheduling at
> this interval. Actually, to achieve this they modified SBC to work on 15
> blocks instead of 4,8,12 or 16 blocks and they decided
> against G.722.
> The lesson to learn is about the importance of MAC protocol. To get a
> efficient, low power, and mobile device you have to consider
> the impact of packet scheduling. If packets are scheduled regular, the MAC
> protocol can work more efficient. The more irregular
> packet arrive, the more expensive a packet transmission gets.
> Actually, you can translate the cost of packet scheduling to bits per
> packet. Depending on the wireless technology, it might vary
> substantially. The worst case is 802.11b at 11 Mbps at long preamble -
> then, you can add about 1300 bytes to every packet just for
> physical headers and MAC scheduling. However, more modern technologies like
> LTE and IEEE 802.11n are much more efficient in terms of
> per packet overhead.
> If you ask me, one important usage scenario is over wireless links
> supporting low-power mobile devices. If we ignore this scenario
> it will be a judge mistake:
> a) Battery powered mobile devices must be energy efficient to reduce the
> size of the batteries. Also, they should not demand to many
> computational resources, otherwise they would consume to much energy.
> b) Wireless IP access is also in scope because many devices get Internet
> access LTE, WLAN, Wimax, UMTS, etc.
> Bluetooth headsets are somewhat a special case. Actually, they are two
> cases:
> 1) Headphones (A2DP): For me it is not clear whether supporting the
> Internet CODEC on top of A2DP (which is - by the way - already
> possible according to Bluetooth spec A2DP V1.2) or using the Internet CODEC
> till the Bluetooth AP and transcoding to SBC is more
> efficient, cost effect, or energy saving.
> 2) Mic (HFP): Here is the scheduling of 3.75 or 7.5ms might be an important
> requirement that the Internet CODEC cannot fulfill
> always because it must adapt its parameters to the Internet transmission
> path not just to the Bluetooth link.
> Thus, I would recommend to write a liaison statement to Bluetooth AVT group
> and ask whether they would have interest to include the
> Internet CODEC into a future version of A2DP. Definitely, this must not
> happen soon because the they can do is only if the Internet
> CODEC is finishing. Supporting HFP might be more difficult than A2DP
> because of the very tough requirements on efficiency.
> With best regards,
>  Christian
> ---------------------------------------------------------------
> Dr.-Ing. Christian Hoene
> Interactive Communication Systems (ICS), University of Tübingen
> Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532
> >-----Original Message-----
> >From: [] On Behalf Of
> Raymond (Juin-Hwey) Chen
> >Sent: Monday, April 26, 2010 11:02 PM
> >To: Mikael Abrahamsson
> >Cc:
> >Subject: Re: [codec] #16: Multicast?
> >
> >Hi Mikael,
> >
> >Thanks for sharing your experience using a BT headset for Skype calls.  I
> think part of the quality
> >degradation that you experienced was due to the reduction of the audio
> bandwidth to narrowband (8 kHz
> >sampling, 3.4 kHz bandwidth), and another part of the degradation was due
> to the audible coding noise
> >of the CVSD codec, a 40-year-old coding technology first proposed in 1970.
> >
> >If a high-quality, low-complexity, wider bandwidth IETF codec mode can be
> implemented in Skype and the
> >Bluetooth headset to avoid the CVSD transcoding (together with wideband
> upgrade of the transducers and
> >audio path in the BT headset, of course), then not only will you get much
> better speech quality in
> >your Skype calls than what you have experienced, but also you will get a
> lower latency.  This is
> >because transcoding between the Skype codec and CVSD not only accumulates
> the coding distortion of the
> >two codecs, but also accumulates the coding delays.  Although CVSD is a
> sample-by-sample codec, BT
> >headsets still transmit the CVSD bit-stream in 3.75 ms or 7.5 ms packets,
> and they can potentially add
> >a one-way delay up to 20 ~ 25 ms through the Bluetooth headset (the exact
> delay depends on the
> >implementation).
> >
> >While we were discussing whether a 5 ms packet size can even be
> considered, for many years Bluetooth
> >headsets have been using an even smaller 3.75 ms packet size.
> >
> >Best Regards,
> >
> >Raymond
> >
> >-----Original Message-----
> >From: Mikael Abrahamsson []
> >Sent: Sunday, April 25, 2010 1:06 AM
> >To: Raymond (Juin-Hwey) Chen
> >Cc: Koen Vos;
> >Subject: Re: [codec] #16: Multicast?
> >
> >On Sat, 24 Apr 2010, Raymond (Juin-Hwey) Chen wrote:
> >
> >> (7) Already a lot of people are used to using Bluetooth headsets to make
> >> phone calls today.  If they have a choice, many of these people will
> >> also want to use Bluetooth headsets to make Internet phone calls, not
> >> only through computers, but also through smart phones connected to WiFi
> >> or cellular networks.  As more and more states and countries pass laws
> >> to ban the use of cell phones that are not in hands-free mode while
> >> driving, the number of Bluetooth headset users will only increase with
> >> time, and many of them will want to make Internet-based phone calls.
> >
> >I purchased a BT headset with the anticipation of using it with my
> >computer to make Skype calls. I tried it, but the sound quality when doing
> >bidirectional audio (whatever that mode is called) is not good enough, it
> >worsens the "skype IP" call quality. I agree that the use case is
> >interesting, but as long as BT sound quality is what it is, it's really
> >only the "low end" type  sound quality we're talking about.
> >
> >But yes, I make skype IP calls with my Nokia N900 using BT sometimes, so
> >the use case example is definitely valid.
> >
> >--
> >Mikael Abrahamsson    email:
> >
> >
> >_______________________________________________
> >codec mailing list
> >
> >
> _______________________________________________
> codec mailing list