IETF Logo Mail Archive

Re: [codec] #16: Multicast?

"Benjamin M. Schwartz" <bmschwar@fas.harvard.edu> Sun, 09 May 2010 21:52 UTC

Return-Path: <bmschwar@fas.harvard.edu>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56DE53A6A7A for <codec@core3.amsl.com>; Sun, 9 May 2010 14:52:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=-3.600, BAYES_50=0.001, J_CHICKENPOX_66=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IaImEisyNJS for <codec@core3.amsl.com>; Sun, 9 May 2010 14:52:35 -0700 (PDT)
Received: from smtpx1.unix.fas.harvard.edu (smtpx1.unix.fas.harvard.edu [140.247.34.254]) by core3.amsl.com (Postfix) with ESMTP id 7DB823A6A6F for <codec@ietf.org>; Sun, 9 May 2010 14:52:35 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpx1.unix.fas.harvard.edu (Postfix) with ESMTP id 857AC17CAA; Sun, 9 May 2010 17:52:23 -0400 (EDT)
X-Amavis-Alert: BAD HEADER SECTION, Header line longer than 998 characters: References: <06...
Received: from us41.unix.fas.harvard.edu (us41.unix.fas.harvard.edu [140.247.35.232]) by smtpx1.unix.fas.harvard.edu (Postfix) with ESMTP; Sun, 9 May 2010 17:52:19 -0400 (EDT)
Received: from c-71-192-160-188.hsd1.nh.comcast.net (c-71-192-160-188.hsd1.nh.comcast.net [71.192.160.188]) by webmail.fas.harvard.edu (IMP) with HTTP for <bmschwar@localhost>; Sun, 9 May 2010 17:52:19 -0400
Message-ID: <1273441939.4be72e937fdf5@webmail.fas.harvard.edu>
Date: Sun, 09 May 2010 17:52:19 -0400
From: "Benjamin M. Schwartz" <bmschwar@fas.harvard.edu>
To: Koen Vos <koen.vos@skype.net>
References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <D6C2F445-BE4A-4571-A56D-8712C16887F1@americafree.tv> <C0347188-A2A1-4681-9F1E-0D2ECC4BDB3B@csperkins.org> <u2x6e9223711004210733g823b4777y404b02330c49dec1@mail.gmail.com> <000001cae173$dba012f0$92e038d0$@de> <r2q6e9223711004211010gfdee1a70q972e8239fef10435@mail.gmail.com> <001101cae177$e8aa6780$b9ff3680$@de> <t2t6e9223711004211119i6b107798pa01fc4b1d33debf1@mail.gmail.com> <002d01cae188$a330b2c0$e9921840$@de> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A017@IRVEXCHCCR01.corp.ad.broadcom.com> <4BD11C50.2020206@usherbrooke.ca> <CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A287@IRVEXCHCCR01.corp.ad.broadcom.com> <002c01cae939$5c01f400$1405dc00$@de> <CB68DF4CFBEF4942881AD37AE1A7E8C74B903454B3@IRVEXCHCCR01.corp.ad.broadcom.com>, <009901caede1$43f366d0$cbda3470$@de> <BCB3F026FAC4C145A4A3330806FEFDA93AB072BCC6@EMBX01-HQ.jnpr.net> <CB68DF4CFBEF4942881AD37AE1A7E8C74B90345C0D@IRVE XCHCC...
In-Reply-To: <20100509143636.21296os5ryogl1ic@mail.skype.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.5
X-Originating-IP: 71.192.160.188
Cc: "codec@ietf.org" <codec@ietf.org>
Subject: Re: [codec] #16: Multicast?
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: bens@alum.mit.edu
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 May 2010 21:52:36 -0000

Quoting Koen Vos <koen.vos@skype.net>:
> For typical VoIP applications, Moore's law has lessened the pressure
> to reduce bitrates, delay and complexity, and has shifted the focus to
> fidelity instead.

I think this is a typo, and you mean "lessened the pressure to reduce bitrates
and complexity, and has shifted the focus to fidelity and delay instead".

> 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...?

Me too; I'd also like some clarification as to whether we're talking about (a)
existing Bluetooth headsets or (b) future hardware designed to support the
IWAC.  If (b), then this is just a matter of negotiating the acceptable
encode+decode complexity, for eventual implementation by DSP or ASIC.  If (a)
... I'm surprised that such a retrofit is even conceivable.  If it is in fact
possible, I would very much appreciate instructions on how to experiment with
new codecs on existing headsets.  Once we know how to build test rigs, we can
see what the complexity requirement there is.  If we can't test it, I don't
think we can target it.

--Ben

v2.19.0 | Report a Bug | By Email