Re: [dispatch] [AVT] Proposal to form Internet Wideband Audio Codec WG

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 03 June 2009 19:57 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: dispatch@core3.amsl.com
Delivered-To: dispatch@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1F0628C189; Wed, 3 Jun 2009 12:57:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.542
X-Spam-Level:
X-Spam-Status: No, score=-3.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 N-bhtFBmqVZC; Wed, 3 Jun 2009 12:57:22 -0700 (PDT)
Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 001E53A67E6; Wed, 3 Jun 2009 12:57:21 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1956D43029A; Wed, 3 Jun 2009 12:57:24 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net
Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 4CD0943025E; Wed, 3 Jun 2009 12:57:23 -0700 (PDT)
Message-ID: <4A26D59B.20905@joelhalpern.com>
Date: Wed, 03 Jun 2009 15:57:15 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: dispatch@ietf.org
References: <AA5A65FC22B6F145830AC0EAC7586A6C04BF8E77@mail-srv.spiritcorp.com> <00a401c9e388$b25c2350$171469f0$%roni@huawei.com> <4A2541B9.2000805@octasic.com> <00d501c9e39a$dcbbbe50$96333af0$%roni@huawei.com> <D1611ACB-4739-4A65-94F0-403FC24CDC43@cs.columbia.edu> <B678F1CB-0000-4774-BF03-6B53C333F15D@standardstrack.com> <CE8BFF1C-6F4D-4AF7-A5A7-20FD7C516D12@voxeo.com>
In-Reply-To: <CE8BFF1C-6F4D-4AF7-A5A7-20FD7C516D12@voxeo.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: avt@ietf.org
Subject: Re: [dispatch] [AVT] Proposal to form Internet Wideband Audio Codec WG
X-BeenThere: dispatch@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: DISPATCH Working Group Mail List <dispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dispatch>
List-Post: <mailto:dispatch@ietf.org>
List-Help: <mailto:dispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dispatch>, <mailto:dispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Jun 2009 19:57:22 -0000

Let's be clear.  I am not trying to argue that the existing codecs are 
good enough.  I hear everyone saying that they are not.
However, the IETF is not the answer to all the worlds standards problems.

In this case, there are a number of existing bodies addressing these 
problems.  There also are apparently existing solutions with near the 
right properties.
1) The IETF is structurally not well suited to dealing with the kinds of 
patent problems that we are dealing with.
2) The IETF, based on history, is not very good at dealing with market 
acceptance issues (questions such as why isn't Speex or SILK being 
accepted.)
3) IETF WGs are very bad at working out what the real problems are. 
THey are good at working out protocol issues.  But this is not primarily 
a protocol issue, from what everyone is saying.

I have heard rumors of several other bodies that are working in this 
space.  Given that we have lately been working very hard to keep other 
folks from encroaching on our patch, we ought to be sensitive to 
encroaching on theirs.

And now, before I start repeating myself, I will try to stay quite for a 
few days and keep listening.
Yours,
Joel


Dan York wrote:
> I've been reading this thread with great interest as for the past 
> probably 6 years or so I've been saying to anyone who will listen (and 
> to those who won't ;-) that one factor that will help "IP 
> communications/VoIP/UC/whatever-marketing-term-we-want-to-rename-our-products-to-this-week" 
> to really find wide adoption is to provide a "rich communication 
> experience" better than what people are used to now.
> 
> Wideband audio is, to me, a huge part of that.
> 
> However, I completely agree with Henning on this point:
> 
>> On Jun 2, 2009, at 12:15 PM, Henning Schulzrinne wrote:
>>
>>> However, if we don't do this, we are stuck with the status quo, which 
>>> is not all that satisfactory.
> 
> 
> The status quo is not satisfactory.  If you want to add wideband audio 
> to your product, you've got an alphabet soup of mutually incompatible 
> options with vastly different licensing terms/fees/options and source 
> code availability.
> 
> I think we ultimately need a "G.711 for wideband", i.e. a wideband codec 
> that anyone can implement in any device.  I'd argue that a large part of 
> the reason we are "stuck" with so many people in VoIP using G.711 is 
> precisely because ANYONE can implement it in basically ANY device.  You 
> can buy a G.711 codec implementation or you can write your own or find 
> some code on the Internet (google "G.711 source code"). You can 
> implement G.711 in your big softswitch or IP-PBX... or you can implement 
> it in some small embedded device.
> 
> And it interoperates.
> 
> We need that kind of codec for wideband.... which I would say is 
> "royalty-free" and needs to have "open source" implementations 
> available.   (And yes, I know Speex is out there - I don't have a view 
> as to why it is not more widely implemented.  And yes, I know Skype is 
> giving away SILK royalty-free, but it's not open source.)
> 
> Can the IETF help with this?  I don't know... but I think it's worth a 
> shot.  If there is a group that is passionate about this (and there 
> seems to be) then lets get the mailing list set up and have it go the 
> regular List -> BOF -> Working Group trajectory.
> 
> In the best case perhaps we come out with the codec we want/need.  At 
> the very worst I think we'd wind up with at least creating some good 
> discussions and requirements for what we do need.
> 
> My 2 cents,
> Dan
>