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

Eric Burger <eburger@standardstrack.com> Wed, 03 June 2009 01:51 UTC

Return-Path: <eburger@standardstrack.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 1B9EC3A6A15; Tue, 2 Jun 2009 18:51:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.005
X-Spam-Level:
X-Spam-Status: No, score=-2.005 tagged_above=-999 required=5 tests=[AWL=0.594, BAYES_00=-2.599]
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 J9Z0hc2lyZX2; Tue, 2 Jun 2009 18:51:56 -0700 (PDT)
Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 4DA393A68DE; Tue, 2 Jun 2009 18:51:56 -0700 (PDT)
Received: from [12.46.252.162] (helo=[172.17.136.184]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <eburger@standardstrack.com>) id 1MBfdp-00068B-Uk; Tue, 02 Jun 2009 18:51:47 -0700
Message-Id: <B678F1CB-0000-4774-BF03-6B53C333F15D@standardstrack.com>
From: Eric Burger <eburger@standardstrack.com>
To: Henning Schulzrinne <hgs@cs.columbia.edu>
In-Reply-To: <D1611ACB-4739-4A65-94F0-403FC24CDC43@cs.columbia.edu>
Content-Type: multipart/signed; boundary="Apple-Mail-335--601262898"; micalg="sha1"; protocol="application/pkcs7-signature"
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Tue, 02 Jun 2009 21:51:49 -0400
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>
X-Mailer: Apple Mail (2.935.3)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: dispatch@ietf.org, 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 01:51:57 -0000

I would strike
> - somebody will claim IPR on the resulting work
from the list of risks. The *resulting* work would clearly be  
predicated by both prior art and Note Well.

On Jun 2, 2009, at 12:15 PM, Henning Schulzrinne wrote:

> I view this as a trade-off. If we pursue this, there are risks:
>
> - nothing may come of it since there are no experts willing to help
> - somebody will claim IPR on the resulting work
> - the quality of the codec may not be competitive
>
> However, if we don't do this, we are stuck with the status quo,  
> which is not all that satisfactory. Thus, unless there are  
> significant costs for "innocent bystanders", I see this as a risk  
> worth taking. In the worst case, we are no worse off than we are  
> today. In all other cases, we'll have an additional choice for a  
> wideband codec, even if it's not "the best", just "good enough".  
> After all, most people use G.711 today, which has a really hard time  
> making that claim.
>
> Most real work in the IETF is done by very small teams, typically  
> less than 10, so as long as we have a handful of people that are  
> willing to contribute, this can work. It might even work better,  
> since you may get fewer people who have half-baked opinions - we may  
> skip the binary vs. XML debates...
>
> We can set some ground rules ("must be tested with packet loss of  
> 5%") and then see what happens. Compared to most network protocols,  
> the likely negative impacts (such as security or congestion control  
> issues) of even a badly-designed codec are pretty limited.
>
> Henning

> [snip]