|
RE: [codec] WG Review: Internet Wideband Audio Codec (codec)
2010-01-19 11:35:15
Hi
It is not clear for me how is handled the editing process of the Charter and
how the agreement or not on the different points contained in it can be
assessed !
The current version is not acceptable, at least with respect to the way
relationships with other SDOs are considered by IETF :
The Charter states first the "The goal of this working group is to develop a
single high-quality audio codec" considering (on what basis ?) that "there are
no standardized, high-quality audio codecs that meet all of the following three
conditions"
However in a next section it is said that "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"
It clearly means that IETF do not care about the answer from these SDOs since
the Group already knows the answer that is already written in the first
sentence of the Charter and that the objective is anyway to develop something
whatever the answers and proposals from these SDOs are
Best regards
Stéphane
-----Message d'origine-----
De : codec-bounces(_at_)ietf(_dot_)org
[mailto:codec-bounces(_at_)ietf(_dot_)org] De la part de Xavier Marjou
Envoyé : lundi 11 janvier 2010 21:19
À : Cullen Jennings
Cc : IAB IAB; codec(_at_)ietf(_dot_)org; IETF Discussion; IESG IESG
Objet : Re: [codec] WG Review: Internet Wideband Audio Codec (codec)
Hi,
We fully share the points 1) and 2) stated in the e-mail below from Cullen
since implementing and deploying a new codec in networks (gateways, service
plate-forms, mediaservers...) and in terminals represents high costs for
service providers, manufacturers and chipset providers in terms of development,
deployment and testing with risks to create bugs and problems affecting
customers. Furthermore, this multiplies the problems of interoperability with
already deployed codecs and the transcoding needs to be addressed with related
costs
(gateways) and quality degradations.
Therefore, the 3 stages mentionned are essential to be run sequentially:
"(1) get consensus on the requirements, (2) see if an existing codec meets the
requirements, and (3) specify a new codec only if none are found in stage 2.
Initially the WG would be chartered for (1) and when that was done it would be
re-charted for (2) and so on. "
Requirements established first in stage 1 shall be sent for stage 2 to other
SDOs as stated in the current version of the Charter:
" 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 "(however in the current version of
the Charter, it is inconsistent to state first that the goal of the WG is to
develop of a new codec and to state some lines after that existing codecs will
be considered...)
Based on the answers collected from these SDOs, conclusion for stage 2 shall be
delivered and constitute the input and prerequisit for any decision to continue
in stage 3 to produce a new codec and re-Charter the Group for this
We therefore propose to limit the Charter to stage 1 and re-formulate it as
follows :
---------------------------------------------------------------------------------
Developers of Internet audio applications and operators of Internet
audio services have expressed the need for 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.
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 produce a set of requirements for
an 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.
Once the first requirement establishment stage completed, the working
group will then communicate detailed description of the requirements
and goals to other SDOs including the ITU-T, 3GPP, and MPEG to jointly
analyse and determine if existing standardized codecs meet the
requirements or can be efficiently adapted to meet them. This work
will constitute a second stage that will be discussed and agreed with
the relevant SDOs and the WG Charter will be updated accordingly
If no existing standardized codec fullfill the requirements nor can be
easily adapted to meet them, the working group will analyse and decide
if such codec can be produced which may constitute the last stage of
the work for which the WG will be re-chartered again.
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:
- 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.
Deliverables
1. A set of technical Requirements. This document shall be
Informational.
Milestones
May-2010: WGLC on Requirements
Jul-2010: Requirements to IESG (Informational)
Jul-2010: Requirements sent to other SDOs (including 3GPP, ITU-T,
MPEG) _______________________________________________
Cheers,
Xavier and colleagues of him
PS: Here is a Word diff version of the charter
http://xavier.marjou.pagesperso-orange.fr/modified-charter.doc
On Thu, Jan 7, 2010 at 6:27 PM, Cullen Jennings <fluffy(_at_)cisco(_dot_)com>
wrote:
Before the IESG sent the proposed CODEC charter out for community review, we
received some concerns about this proposed charter. I had hoped these would
be discussed during the WG charter review. I'm raising these issues now to
make sure that the IESG has an opportunity to hear from the whole community.
As a starting point for the discussion, I am providing some of my own
thoughts on these issues.
1) The charter should allow for the proposed WG to decide to select an
existing codec
My read of the current charter is that selecting an existing codec is
allowed, and this would be a very good outcome. This topic has been
discussed in the past; my recollection is that people that have expressed
opinions on existing codecs also believe that it would be a good thing for
the WG to be able to choose an existing one as long as it meets the goals. If
there is something that needs to be clarified in the proposed charter to make
this clear, please help by suggesting wording.
2) Some people have proposed the WG should be chartered in three stages. (1)
get consensus on the requirements, (2) see if an existing codec meets the
requirements, and (3) specify a new codec only if none are found in stage 2.
Initially the WG would be chartered for (1) and when that was done it would
be re-charted for (2) and so on.
We have received excellent liaison about existing codecs and their IPR
status and many of the participants on the list have a reasonable
knowledge of the currently available codecs. I have not heard people
making strong arguments that one of the existing codecs meets the
requirements and goals that the list seems to be converging on. The
key issues here is that even *after* codec work is started, the WG
still needs to be able to choose an existing codec as the IPR status
of existing codec. Specifically if some patent holders of one of the
existing codecs decided to make the codec royalty free, the WG very
well could choose to abandon ongoing work and choose the existing
codec. Also as the work evolves, participants will get better
information about the quality of any codec being developed and this
may change the consensus regarding the need to develop a new codec.
Given all of these, chartering in multiple stages seems to add to the
process burden and does not seem to have a
strong benefit in producing a better final outcome one way or the other.
3) There should be a only a single codec coming out of the proposed WG
and forbid more than one
Most codecs of this type end of having various algorithm parameter values in
the payload that make it hard to enforce something like this. Various codec
experts have explained to me that it is easy to make a codec where one of the
bits ends up selecting which coding technique to use. Adding constraints like
this is likely to just create incentives for a WG to do patchwork designs to
work around process constraints. In the end, I suspect we need to rely on the
WG consensus process to cause the correct thing to happen.
4) Some people suggested that the WG needs to demonstrate the codec is
superior to all existing codecs in ways other than just IPR
considerations
I observe it is unlikely that a codec that tries to avoid any modern IPR
would end up being better in all other ways to codecs that incorporated
modern advances in codec design that are patented. My current read of the
input from the list discussion and BOFs is that that the bulk of the
participants do not view this as a needed to meet the envisioned use cases.
5) The WG should have consensus that any codec they select is not IPR
encumbered or is royalty free.
The IETF IPR policy attempts to get relevant information from the
participants of the a WG about IPR associated with contributions. This
allows the WG to make informed decisions when deciding on mechanisms. All
chartered WGs must work within the current IETF IPR rules. The proposed
codec WG is no exception, and this has been very clearly stated in the BOFs
and other discussions about this work. BCP 79 says the IETF "will take no
position on the validity or scope of any such IPR claims".
Thanks, Cullen <RAI AD>
On Dec 23, 2009, at 9:15 , IESG Secretary wrote:
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(_dot_)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(_dot_)com>
* Cullen Jennings <fluffy(_at_)cisco(_dot_)com>
Real-time Applications and Infrastructure Area Advisor:
* Cullen Jennings <fluffy(_at_)cisco(_dot_)com>
Mailing Lists:
General Discussion: codec(_at_)ietf(_dot_)org
To Subscribe: codec-request(_at_)ietf(_dot_)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)
_______________________________________________
codec mailing list
codec(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/codec
_______________________________________________
codec mailing list
codec(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/codec
_______________________________________________
codec mailing list
codec(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/codec
*********************************
This message and any attachments (the "message") are confidential and intended
solely for the addressees.
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration.
France Telecom Group shall not be liable for the message if altered, changed or
falsified.
If you are not the intended addressee of this message, please cancel it
immediately and inform the sender.
********************************
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
|
|