WG Review: Internet Wideband Audio Codec (codec)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@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@nostrum.com>
 * Cullen Jennings <fluffy@cisco.com>

Real-time Applications and Infrastructure Area Advisor:
 * Cullen Jennings <fluffy@cisco.com>

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 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@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce

[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux