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