[codec] Fwd: WG Review: Internet Wideband Audio Codec (codec)

[Cullen Jennings <[e-mail]>]

Begin forwarded message:

> From: IESG Secretary <[e-mail]>
> Date: December 23, 2009 10:15:01 AM MST
> To: [e-mail]
> Cc: [e-mail]
> Subject: [codec] WG Review: Internet Wideband Audio Codec (codec)
> Reply-To: [e-mail]
> 
> 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 ([e-mail]) 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 <[e-mail]>
> * Cullen Jennings <[e-mail]>
> 
> Real-time Applications and Infrastructure Area Advisor:
> * Cullen Jennings <[e-mail]>
> 
> Mailing Lists:
> General Discussion: [e-mail]
> To Subscribe: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/codec