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

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!
Regards,
Silvia.

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.
>
> Brad
>
> ----------  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
> 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)
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce at ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
>
>
> -------------------------------------------------------
> _______________________________________________
> annodex-dev mailing list
> annodex-dev at lists.annodex.net
> http://lists.annodex.net/cgi-bin/mailman/listinfo/annodex-dev
>