A new IETF working group has been formed in the Real-time Applications and Infrastructure Area. For additional information, please contact the Area Directors or the WG Chairs. Internet Wideband Audio Codec (codec) --------------------------------------------------- Current Status: Active Working Group Chairs: * Michael Knappe (mknappe@juniper.net) * Peter Saint-Andre (stpeter@stpeter.im) Real-time Applications and Infrastructure Area Directors: * Robert Sparks (rjsparks@nostrum.com) * Cullen Jennings (fluffy@cisco.com) Real-time Applications and Infrastructure Area Advisor: * Cullen Jennings (fluffy@cisco.com) Technical Advisor(s): * Stephan Wenger (stewe@stewe.org) Mailing Lists: General Discussion: codec@ietf.org To Subscribe: codec-request@ietf.org 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 ensure the existence of 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. At present it appears that ensuring the existence of such a codec will require a development effort within the working group, however if a candidate codec is presented that achieves the goal then the working group should seriously consider stopping its development work. The core technical considerations for such a codec 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 and clean integration 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 a codec produced by this working group or another standards organization 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 or select 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. 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. In accordance with the liaison agreement in place, the working group will continue to coordinate with the ITU-T (Study group 16), 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 a 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 goals. Information about codecs being standardized will be available to other SDOs in the form of internet drafts and the working group welcomes technical feedback from other SDOs and experts from other organizations. 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 follow BCP 79, and adhere to the spirit of BCP 79. The working group cannot explicitly rule out the possibility of adopting encumbered technologies; however, the working group will try to avoid encumbered technologies that require royalties or other encumbrances that would prevent such technologies from being easy to redistribute and use. 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. Goals and Milestones: Mar-2010: Chairs update all milestone dates Apr-2010: WGLC on Codec Standardization Guidelines May-2010: Codec Standardization Guidelines to IESG (Informational) Jun-2010: WGLC on Requirements, liaise to other SDOs Jul-2010: Requirements to IESG (Informational) Aug-2010: Liaise requirements RFC to other SDOs Sep-2010: Receive information on suitability of existing codecs Dec-2010: Freeze codec structure, liaise to other SDOs Jun-2011: Finalize codec parameters, liaise to other SDOs Jul-2011: WGLC on codec specification, liaise to other SDOs Oct-2011: Submit codec specification to IESG (Standards Track) Nov-2011: Liaise codec RFC to other SDOs _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
