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

From: Roni Even <[email-masked]>
Date: Wed, 03 Jun 2009 20:14:04 +0300

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

[email-masked]

https://www.ietf.org/mailman/listinfo/dispatch

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 03 Jun 2009 14:48:03 -0400

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

Let me start by stating that codec design is no rocket science. There 
are many people out there who know how to write audio codecs and many 
more who have sufficient skills to contribute. At this point, there is 
already interest from several people with actual codec design experience 
at Skype, Xiph.Org and SPIRIT. The internet community has clear and 
considerable needs which are not being adequately met by the existing 
standards bodies. We have parties experienced with codec development who 
want to work together within the IETF. Why do you believe the risk of 
not succeeding justifies not even attempting the effort?

Cheers,

    Jean-Marc

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 03 Jun 2009 13:39:25 -0400

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.
> 
>  
> 
> [email-masked] <mailto:[email-masked]>
> 
> ------------------------------------------------------------------------
>