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

"Joel M. Halpern" <jmh@joelhalpern.com> Wed, 03 June 2009 17:40 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 A4EC53A7074; Wed, 3 Jun 2009 10:40:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.532
X-Spam-Level:
X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[AWL=0.067, 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 PChoUGB48Dho; Wed, 3 Jun 2009 10:40:23 -0700 (PDT)
Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id DC9CB3A7075; Wed, 3 Jun 2009 10:39:31 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id E1F63430254; Wed, 3 Jun 2009 10:39:33 -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 E266443023D; Wed, 3 Jun 2009 10:39:32 -0700 (PDT)
Message-ID: <4A26B54D.8070800@joelhalpern.com>
Date: Wed, 03 Jun 2009 13:39:25 -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: <021701c9e030$0a5deef0$1f19ccd0$%roni@huawei.com> <021201c9e46e$c1459c70$43d0d550$%roni@huawei.com>
In-Reply-To: <021201c9e46e$c1459c70$43d0d550$%roni@huawei.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 17:40:24 -0000

To be blunt, without some better explanation of why the IETF ought to do 
this, and how the IETF is likely to be successful in doing this, I think 
it would be a disservice to the folks who want to work on this to 
encourage them to believe that the only obstacle is a clear problem 
definition.

To be clear, I have absolutely no problem with a community using an IETF 
   based email list to discuss their codec ideas, work out why they want 
to work on a new one, organize thier ideas for where that work should be 
done, etc.

So far, what strikes me is that most of the folks who would be called 
upon to evaluate a requirements document, or an actual protocol, have 
little or no expertise in codec design either from a mathematical or a 
software perspective (there are a few exceptions in both those regards, 
folks like Henning), and have little or no experience in the observed 
difficulties in actually standardizing codecs.  (Folks I ahve talked to 
who have been down that road have indicated that it involves many 
aspects that are foreign to IETF experience and practice.)

Yours,
Joel M. Halpern

Roni Even wrote:
> 
> 
> Hi,
> 
> I would like to clarify that I am not against the discussion of codecs 
> at the IETF  but I think that before deciding to standardize one at the 
> IETF we should write requirements and analyze current codecs (standard 
> as well as non-standards) and see if they provide a good fit.
> 
>  
> 
> One of my points is that having an IETF standard track codec does not 
> make it widely deployed as long as the IETF do not mandate codecs. I 
> think that you can look at the discussion in the SIP forum about 
> specifying a codec.
> 
>  
> 
> I also think (and I will keep mentioning it) that one of the advantages 
> of voice on IP or over the Internet is that you can have a higher 
> quality user experience by using a wideband codec, it is a pity that 
> G.711 is still widely used taking bigger bandwidth than current wideband 
> audio with lower quality.
> 
>  
> 
> Roni Even
> 
>  
> 
>  
> 
>  
> 
> All,
> 
>  
> 
> I would like to request agenda time inside the DISPATCH meeting to 
> propose the formation of a new working group to define a Proposed 
> Standard wideband audio codec.
> 
>  
> 
> The text of the proposal is below. Comments, questions, and suggestions 
> welcomed.
> 
>  
> 
> Regards,
> 
> Jason
> 
>  
> 
>  
> 
> Internet Wideband Audio Codec (IWAC)
> 
> Mailing Lists: TBD
> 
> Chairs: TBD
> 
> Area Directorate: Real Time Applications (RAI)
> 
>  
> 
> Purpose:
> 
>  
> 
> This new working group would be chartered with the purpose of collecting
> 
> expertise within the IETF in order to review the design of audio codecs
> 
> specifically for use with the Internet. Unlike other SDOs, these codecs
> 
> would be optimized for use on the Internet, and as much as possible choose
> 
> technology that does not require paying patent royalties.
> 
>  
> 
> The Internet Low Bit Rate Codec (iLBC)  work was done in AVT but it was 
> felt
> 
> that subsequent work should not be done in the AVT working group. This new
> 
> working group will have as its primary purpose the standardization of a
> 
> multi-purpose audio codec that can be used in various situations on the
> 
> Internet. Some of the proposed Internet-specific requirements include:
> 
> * scalable and adaptive bit rate;
> 
> * various sampling rate profiles from narrow-band to super-wideband;
> 
> * scalable complexity;
> 
> * low latency; and
> 
> * resilience to packet loss.
> 
>  
> 
> There are a number of wide-band capable codecs defined by other SDOs. For
> 
> instance, G.722 is seeing adoption in Enterprise applications since it is
> 
> relatively simple and low-cost to deploy. However, it has a high, fixed
> 
> bitrate and is not appropriate for mobile applications where spectrum
> 
> efficiency is important or in consumer applications where available
> 
> bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been 
> adopted
> 
> by the 3GPP as a wideband standard for mobile applications. G.722.2 is
> 
> relatively high cost due to patent royalties and is seeing minimal
> 
> deployments outside of mobile handsets making it challenging to create
> 
> wideband experiences on Internet-capable mobile devices when extending
> 
> beyond the mobile network. In other cases, proprietary codecs are being
> 
> adopted which further create islands with no interoperability unless
> 
> widespread transcoding is performed. Transcoding leads to higher costs and
> 
> lower quality.
> 
>  
> 
> The goal of this working group is to define a single codec with multiple
> 
> profiles which can be made available on a wide variety of Internet-capable
> 
> devices including low-power, mobile devices as well as devices capable of
> 
> utilizing high quality, high bitrate audio.
> 
>  
> 
> Proposed Deliverables:
> 
>  
> 
> 1) Requirements for wideband, Internet audio codec(s).
> 
> 2) Algorithm description for wideband, Internet audio codec(s) as Proposed
> 
> Standard.
> 
> 3) Specification of payload format(s) for defined codecs as Proposed
> 
> Standard
> 
>  
> 
> _______________________________________________
> 
> dispatch mailing list
> 
> dispatch@ietf.org <mailto:dispatch@ietf.org>
> 
> https://www.ietf.org/mailman/listinfo/dispatch
> 
>  
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.org/mailman/listinfo/dispatch