[annodex-dev] Fwd: WG Review: Internet Wideband Audio Codec (codec)
silviapfeiffer1 at gmail.com
Wed Dec 23 14:23:51 PST 2009
If I am not mistaken, some Xiph people, in particular Jean-Marc (and
therefore cc-ed) is already involved in this.
Xiph is in fact more appropriate for this than Annodex.
Thanks for pointing it out!
On Thu, Dec 24, 2009 at 7:01 AM, Brad Hards <bradh at frogmouth.net> wrote:
> For info. Looks like something Annodex developers might be interested in
> getting involved in.
> For those that haven't seen IETF in action before, the working groups are a
> lot like free software projects. A few people do most of the work, a few
> people throw in comments on the mailing list, and out comes something that
> (usually) works. So all you need to do is to subscribe to the mailing list and
> lurk / contribute as required.
> ---------- Forwarded Message ----------
> Subject: WG Review: Internet Wideband Audio Codec (codec)
> Date: Thursday 24 December 2009
> From: IESG Secretary <iesg-secretary at ietf.org>
> To: ietf-announce at ietf.org
> 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 at ietf.org) 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 at nostrum.com>
> * Cullen Jennings <fluffy at cisco.com>
> Real-time Applications and Infrastructure Area Advisor:
> * Cullen Jennings <fluffy at cisco.com>
> Mailing Lists:
> General Discussion: codec at ietf.org
> To Subscribe: codec-request at 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
> 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
> 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.
> 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
> 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
> 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
> 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.
> 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
> 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.
> 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)
> IETF-Announce mailing list
> IETF-Announce at ietf.org
> annodex-dev mailing list
> annodex-dev at lists.annodex.net
More information about the annodex-dev