Hi Christian, Then perhaps it is good to specify that this WG is not going to look to narrowband and wideband but only to Superwideband and Fullband. That could be specified in that paragraph. The name IWAC (Internet Wideband Audio Codec (codec)) could be misleading if wideband is not going to be looked at. BTW, G.711 and G.722 are not speech codecs but PCM and ADPCM codecs without any source model assumption. Also, I don?t think efficient and high quality have the same meaning. Efficient usually brings to low bitrate and high quality audio to higher bitrates. Best regards Hervé -----Original Message----- From: Christian Hoene [mailto:hoene@xxxxxxxxxxxxxxxx] Sent: Friday, January 08, 2010 4:56 PM To: 'Herve Taddei'; 'IETF Discussion' Cc: 'IAB IAB'; codec@xxxxxxxx; 'IESG IESG' Subject: AW: [codec] WG Review: Internet Wideband Audio Codec (codec) Dear Herve, > "According to reports from developers of Internet audio applications > and > operators of Internet audio services, there are no standardized, > high-quality audio codecs that meet all of the following three > conditions: > 1. Are optimized for use in interactive Internet applications. > 2. Are published by a recognized standards development organization > (SDO) and therefore subject to clear change control. > 3. Can be widely implemented and easily distributed among application > developers, service operators, and end users." > > I think it was already pointed out a few times (at least see email from > Ingemar Johannson in November 2009), that this part needs to be > modified as > some existing standard codecs (at least G.711, G.722) are already > optimized > for interactive Internet applications, are published by recognized SDO > (ITU-T) and can be widely implemented ... with the difference that G.711 and G.722 are not audio but narrow and wideband speech codecs. They are not very efficient (=high-quality) either. With best regards, Christian > > Besides if easily implemented means RF it should certainly be > explicitely > written. Many of the codecs from e.g. ITU-T or 3GPP can be considered > as > easily implementable and distributable, optimized for internet > applications > and published by recognized SDOs. > > Best regards > > Herve > > > > > On Dec 23, 2009, at 9:15 , IESG Secretary wrote: > > > A new IETF working group has been proposed in the Real-time > Applications > > and Infrastructure Area. The IESG has not made any determination as > yet. > > The following draft charter was submitted, and is provided for > > informational purposes only. Please send your comments to the IESG > > mailing list (iesg@xxxxxxxx) by January 20, 2010. > > > > Internet Wideband Audio Codec (codec) > > --------------------------------------------------------------------- > ---- > > Last Modified: 2009-12-17 > > > > Proposed Chair(s): > > * TBD > > > > Real-time Applications and Infrastructure Area Director(s): > > * Robert Sparks <rjsparks@xxxxxxxxxxx> > > * Cullen Jennings <fluffy@xxxxxxxxx> > > > > Real-time Applications and Infrastructure Area Advisor: > > * Cullen Jennings <fluffy@xxxxxxxxx> > > > > Mailing Lists: > > General Discussion: codec@xxxxxxxx > > To Subscribe: codec-request@xxxxxxxx > > In Body: subscribe > > Archive: https://www.ietf.org/mailman/listinfo/codec > > > > Description of Working Group > > Problem Statement > > > > According to reports from developers of Internet audio applications > and > > operators of Internet audio services, there are no standardized, > > high-quality audio codecs that meet all of the following three > > conditions: > > > > 1. Are optimized for use in interactive Internet applications. > > > > 2. Are published by a recognized standards development organization > > (SDO) and therefore subject to clear change control. > > > > 3. Can be widely implemented and easily distributed among application > > developers, service operators, and end users. > > > > There exist codecs that provide high quality encoding of audio > > information, but that are not optimized for the actual conditions of > the > > Internet; according to reports, this mismatch between design and > > deployment has hindered adoption of such codecs in interactive > Internet > > applications. > > > > There exist codecs that can be widely implemented and easily > > distributed, but that are not standardized through any SDO; according > to > > reports, this lack of standardization and clear change control has > > hindered adoption of such codecs in interactive Internet > applications. > > > > There exist codecs that are standardized, but that cannot be widely > > implemented and easily distributed; according to reports, the > presence > > of various usage restrictions (e.g., in the form of requirements to > pay > > royalty fees, obtain a license, enter into a business agreement, or > meet > > other special conditions imposed by a patent holder) has hindered > > adoptions of such codecs in interactive Internet applications. > > > > According to application developers and service operators, an audio > > codec that meets all three of these would: (1) enable protocol > > designers to more easily specify a mandatory-to-implement codec in > > their protocols and thus improve interoperability; (2) enable > > developers to more easily easily build innovative, interactive > > applications for the Internet; (3) enable service operators to more > > easily deploy affordable, high-quality audio services on the > Internet; > > and (4) enable end users of Internet applications and services to > enjoy > > an improved user experience. > > > > Objectives > > > > The goal of this working group is to develop a single high-quality > audio > > codec that is optimized for use over the Internet and that can be > widely > > implemented and easily distributed among application developers, > service > > operators, and end users. Core technical considerations include, but > > are not necessarily limited to, the following: > > > > 1. Designing for use in interactive applications (examples include, > but > > are not limited to, point-to-point voice calls, multi-party voice > > conferencing, telepresence, teleoperation, in-game voice chat, and > live > > music performance) > > > > 2. Addressing the real transport conditions of the Internet as > > identified and prioritized by the working group > > > > 3. Ensuring interoperability with the Real-time Transport Protocol > > (RTP), including secure transport via SRTP > > > > 4. Ensuring interoperability with Internet signaling technologies > such > > as Session Initiation Protocol (SIP), Session Description Protocol > > (SDP), and Extensible Messaging and Presence Protocol (XMPP); > however, > > the result should not depend on the details of any particular > signaling > > technology > > > > Optimizing for very low bit rates (typically below 2.4 kbps) and for > > non-interactive audio is out of scope because such work might > > necessitate specialized optimizations. > > > > Although the codec produced by the working group might be used as a > > mandatory-to-implement technology by designers of particular Internet > > protocols, it is explicitly not a goal of the working group to > produce a > > codec that will be mandated for use across the entire IETF or > Internet > > community nor would their be any expectation that this would be the > only > > mandatory-to-implement codec. > > > > The goal of the working group is to produce only one codec. Based on > > the working group's analysis of the design space, the working group > > might determine that it needs to produce more than one codec, or a > codec > > with multiple modes; however, it is not the goal of working group to > > produce more than one codec, and to reduce confusion in the > marketplace > > the working group shall endeavor to produce as few codecs as > possible. > > > > In completing its work, the working group should collaborate with > other > > IETF working groups to complete particular tasks. These might > include, > > but would not be limited to, the following: > > > > - Within the AVT WG, define the codec's payload format for use with > the > > Real-time Transport Protocol (RTP). > > > > - Collaborate with working groups in the Transport Area to identify > > important aspects of packet transmission over the Internet. > > > > - Collaborate with working groups in the Transport Area to understand > > the degree of rate adaptation desirable, and to reflect that > > understanding in the design of a codec that can adjust its > > transmission in a way that minimizes disruption to the audio. > > > > - Collaborate with working groups in the RAI Area to ensure that > > information about and negotiation of the codec can be easily > > represented at the signaling layer. > > > > The working group will inform the ITU-T (Study group 16) of each new > > revision of working group drafts, with the intent of submitting the > > completed codec RFC for co-publication by the ITU-T if the ITU-T > finds > > that appropriate. The working group will communicate detailed > > description of the requirements and goals to other SDOs including the > > ITU-T, 3GPP, and MPEG to help determine if existing codecs meet the > > requirements and would therefore enable co-publication of an existing > > standard at the IETF. The working group will also continue to discuss > > with other standards bodies to determine if it becomes possible to > > satisfy the IETF requirements through a new or revised standard at > other > > bodies. > > > > Suggested Codec Standardization Guidelines and Requirements for > > achieving the foregoing objectives are provisionally outlined in > > draft-valin-codec-guidelines and draft-valin-codec-requirements > > respectively; these documents will form the starting point for > working > > toward consensus and, if accepted as work items of the working group, > > will be refined by the working group in accordance with the usual > IETF > > procedures. > > > > A codec that can be widely implemented and easily distributed among > > application developers, service operators, and end users is > preferred. > > Many existing codecs that might fulfill some or most of the technical > > attributes listed above are encumbered in various ways. For example, > > patent holders might require that those wishing to implement the > codec > > in software, deploy the codec in a service, or distribute the codec > in > > software or hardware need to request a license, enter into a business > > agreement, pay licensing fees or royalties, or attempt to adhere to > > other special conditions or restrictions. > > > > Because such encumbrances have made it difficult to widely implement > and > > easily distribute high-quality audio codecs across the entire > Internet > > community, the working group prefers unencumbered technologies in a > way > > that is consistent with BCP 78 and BCP 79. In particular, the > working > > group shall heed the preference stated in BCP 79: "In general, IETF > > working groups prefer technologies with no known IPR claims or, for > > technologies with claims against them, an offer of royalty-free > > licensing." Although this preference cannot guarantee that the > working > > group will produce an unencumbered codec, the working group shall > > attempt to adhere to the spirit of BCP 79. This preference does not > > explicitly rule out the possibility of adapting encumbered > technologies; > > such decisions will be made in accordance with the rough consensus of > > the working group. > > > > Deliverables > > > > 1. A set of Codec Standardization Guidelines that define the work > > processes of the working group. This document shall be Informational. > > > > 2. A set of technical Requirements. This document shall be > > Informational. > > > > 3. Specification of a codec that meets the agreed-upon requirements, > in > > the form of an Internet-Draft that defines the codec algorithm along > > with source code for a reference implementation. The text > description > > of the codec shall indicate which components of the encoder and > decoder > > are mandatory, recommended, and optional. It is envisioned that this > > document shall be a Proposed Standard document. > > > > Milestones > > > > Mar-2010: WGLC on Codec Standardization Guidelines > > May-2010: Codec Standardization Guidelines to IESG (Informational) > > May-2010: WGLC on Requirements > > Jul-2010: Requirements to IESG (Informational) > > Dec-2010: Freeze codec structure > > Jun-2011: Finalize codec parameters > > Jul-2011: WGLC on codec specification > > Oct-2011: Submit codec specification to IESG (Standards Track) > > _______________________________________________ > > codec mailing list > > codec@xxxxxxxx > > https://www.ietf.org/mailman/listinfo/codec > > _______________________________________________ > codec mailing list > codec@xxxxxxxx > https://www.ietf.org/mailman/listinfo/codec > > > _______________________________________________ > codec mailing list > codec@xxxxxxxx > https://www.ietf.org/mailman/listinfo/codec _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf