Subject: Re: WG Review: Internet Wideband Audio Codec (codec)

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Dec 2009 22:26:07 -0500

I don't think it is a very good idea to attempt this type of work in
the IETF. We have enough difficulty doing crypto algorithms and that
is an area where we have tens of people with decades worth of
expertise who pretty much mostly agree on the algorithms to use in any
case.

An unencumbered CODEC would be very useful, but any new CODEC that was
developed would be subject to attack by patent trolls. So the group
would be pretty much limited to reviewing existing technologies and
attempting to select one that is out of patent.

Looking at technologies that are out-of-patent or soon to be out of
patent, well DVD came out in 1995 and the patent licensing terms are
reasonably well defined. MP3 and AC3 are the existing industry
standards. If we know when the patents drop dead, I can't see how IETF
imprimatur is going to add or detract anything there. Its not as if
the IETF can stand behind the spec and say that it is definitively
unencumbered. So the most we are going to have is a document that
brings together all the relevant information and allows people to
quickly come to a degree of confidence that the technology will be
inencumbered on a certain date.

On Thu, Dec 24, 2009 at 8:56 AM, Roni Even <[email-masked]> wrote:
> Hi,
> In line
> Roni Even
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Thursday, December 24, 2009 11:47 AM
>> To: Roni Even
>> Cc: 'Tschofenig, Hannes (NSN - FI/Espoo)'; [email-masked];
>> [email-masked]; [email-masked]
>> Subject: Re: WG Review: Internet Wideband Audio Codec (codec)
>>
>>     Date:        Thu, 24 Dec 2009 08:50:30 +0200
>>     From:        "Roni Even" <[email-masked]>
>>     Message-ID:  <[email-masked]>
>>
>>   | I am not sure but are you suggesting that the IETF will define the
>>   | requirements, metric and quality assessment requirements and all
>> proposed
>>   | codecs should provide the results and then the WG will choose the
>> best codec
>>   | bases without discussing the codec itself. This is what I would
>> call a
>>   | selection process (at least in ITU terms).
>>
>> The WG can decide how it wants to go about the process, I'd just prefer
>> that
>> the charter not (effectively) rule out selection of something that
>> already
>> exists with an assumption that something entirely new will be created.
>>
>>   | The problem is that the IETF process allows anyone to contribute to
>> existing
>>   | work hopefully leading to a better the end result.
>>
>> Of course, but also be aware that there's no one definition of
>> "better".
>> Something that can be defined quickly and used immediately might be
>> much
>> better than something it takes 5 years to create and more to implement,
>> even if the invented one saves a little bandwidth or has better loss
>> recovery characteristics.
>
> This is the IETF process for better or worse, I asked similar questions and
> the response is that the IETF decide what is better is based on rough
> consensus.
> BTW: my personal view is that your suggestion is in line with the process at
> the ITU when doing codec selection, but there are people who prefer doing it
> at the IETF using the IETF procedures for other reasons.
>
>
>>
>>   | What about the change control, does it stay with the original
>> contributor or
>>   | can the IETF modify the codec based on input from other parties,
>> which means
>>   | that the codec may change by the IETF anyhow.
>>
>> The IETF will have change control over its protocol, of course, which
>> may
>> cause it to diverge from that upon which it was originally based.  And
>> yes,
>> everything changes with time.
>>
>> kre
>
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf
>

-- 
-- 
New Website: http://hallambaker.com/
View Quantum of Stupid podcasts, Tuesday and Thursday each week,
http://quantumofstupid.com/

---

From: Koen Vos <[email-masked]>
Date: Thu, 24 Dec 2009 23:55:30 -0800

Quoting Phillip Hallam-Baker:
> MP3 and AC3 are the existing industry standards.

These codecs are rarely used for real-time communications, mostly  
because of their high bitrates/poor quality for voice signals.

> So the most we are going to have is a document that

Any difference with other standards?

koen.

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 4 Jan 2010 17:57:56 +0100

We actually already have done work in this area, RFC 3951.

What I think you say is that it in the IETF is hard to do work starting with a white sheet of paper. And I agree with that. I do though think that is not something special for IETF as an SDO, and I do specifically not think that is specific for this kind of work.

   Patrik

---

From: Mans Nilsson <[email-masked]>
Date: Mon, 4 Jan 2010 22:43:38 +0100

> What I think you say is that it in the IETF is hard to do work starting with a white sheet of paper. And I agree with that. I do though think that is not something special for IETF as an SDO, and I…

	(I'm answering both Patrik and Philip here)

But we are not running out of proposals for codecs to adapt. Both CELT
and SILK seem reasonable.

The patent troll threat is a more sinister one, since a lot of revenue
and lock-in is won by FUDing  people into buying unfree codecs --
giving a lot of companies ample reason to fight this.

The users need CODEC. The industry maybe does not, at least not the
myopic parts of it. Do we build and document what the users need or
what the industry orders?

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Jesuit priests are DATING CAREER DIPLOMATS!!

---

From: Sam Hartman <[email-masked]>
Date: Mon, 04 Jan 2010 17:40:52 -0500

I've been thinking about the codec issue for a while.  I think it is
really desirable for the IETF to charter this group.  I don't think the
charter should prohibit the working group from selecting some existing
codec nor should it prohibit doing new work in this space.

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 4 Jan 2010 20:43:13 -0500

+1 Emphatically 

If people want to do the work, why not let them try.  

If they cannot succeed then shut it down. 

That does bring up the more sensitive subject that the IETF as a whole needs
to consider which is when can it be determined that a WG is not succeeding.
That is a much much longer thread. 

>  From: [email-masked] [mailto:[email-masked]] On Behalf
>  Of Sam Hartman
>  Sent: Monday, January 04, 2010 5:41 PM
>  To: Patrik Fältström
>  Cc: [email-masked]; Phillip Hallam-Baker; [email-masked];
>  [email-masked]; [email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 5 Jan 2010 07:25:36 +0100

> codec nor should it prohibit doing new work in this space.

I agree with this.

   Patrik

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Tue, 5 Jan 2010 11:16:10 +0100

> and SILK seem reasonable.

Speaking for me as a user, MP3 and AAC are at least worthy of 
consideration. Someone said on this list that they waste bandwidth, but 
VoIP's main problem for me as a user is low speech quality, not 
unacceptable traffic. I hear fine voice quality on 128kbps mp3 radio 
streams and really fine on 176kbps ogg; I'd like to have that for phone 
calls.

rnt

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 5 Jan 2010 09:32:36 -0500

Just as an amusing side bar to the discussion ..you all know that any
wideband codec kills fax don’t you?

>  Of Arnt Gulbrandsen
>  Sent: Tuesday, January 05, 2010 5:16 AM
>  To: [email-masked]; [email-masked]
>  Cc: Phillip Hallam-Baker; Mans Nilsson; Patrik Fältström;
>  [email-masked]

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 05 Jan 2010 08:07:15 -0800

Catering to the backwards compatibility needs of qam v.34bis doesn't
seem like a terribly high priority application for a wideband voice
codec... Your user agent can just use g.711 for that application.

---

From: Brian West <[email-masked]>
Date: Mon, 4 Jan 2010 16:20:31 -0600

I think CELT and SILK are both great codecs.. I was under the impression that SILK ran at 32kHz and did internal resampling but that doesn't appear to be the case.  Either way we have six sample rates to pick from between the two codecs giving you bandwidth vs quality options that really do fit most needs in my opinion.  8,12,16,24,32 and 48kHz are some great choices and we support all 6 native rates in FreeSIWTCH now.

What other codecs did I miss that were submitted?  We have BV16 and BV32 in FreeSWITCH now too.

/b

---

From: Brian West <[email-masked]>
Date: Mon, 4 Jan 2010 18:39:32 -0600

Is the source and spec for the SPIRIT codec out there?  I would be interested in trying this out in FreeSWITCH... I'm a codec whore... if you haven't noticed.  :P

/b

On Jan 4, 2010, at 4:29 PM, Jean-Marc Valin wrote:

> The one you misses is SPIRIT's IP-MR codec. As you say, with the four
> codecs proposed so far we can cover a wide range of applications. There's a
> lot of potential for having a great codec come out of this.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 4 Jan 2010 17:48:08 -0500

I can see the motivation to pay big bucks for video codecs. Using
Mpeg4 can reduce your bandwidth costs and save real money. I can see
why there was a big incentive to save money on audio codecs in the
1990s.

At this point an audio codec is going to have to save a huge amount ot
bandwidth to be worth the hassle, let alone the cost of using
encumbered technology. A useful starting point would be to establish a
safe fallback using technology such a mu-law or a-law that nobody can
possibly claim they own without being referred to the reply given in
the famous case of Arkel vs. Pressdram.

The objective here is not necessarily to use mu-law as the default
codec (but I really don't think that is unthinkable as some have
suggested in the past), the objective is to reduce the bargaining
leverage of any possible patent troll from being able to demand the
economic value of the bandwideth saved by using their codec.

---

From: Jean-Marc Valin <[email-masked]>
Date: Mon, 04 Jan 2010 17:29:09 -0500

Brian West wrote:
> I think CELT and SILK are both great codecs.. I was under the impression
> that SILK ran at 32kHz and did internal resampling but that doesn't
> appear to be the case.  Either way we have six sample rates to pick from
> between the two codecs giving you bandwidth vs quality options that
> really do fit most needs in my opinion.  8,12,16,24,32 and 48kHz are
> some great choices and we support all 6 native rates in FreeSIWTCH now.
> 

	Jean-Marc

---

From: "Roni Even" <[email-masked]>
Date: Tue, 5 Jan 2010 20:10:06 +0200

Hi,
I do not think that the IETF should accept any work because people want to
do it, if this is the case a group of people can come and ask to start
working on any idea they have that has some relation to the Internet. IETF
should accept work that is in scope for of the IETF  and for which there is
enough knowledge to evaluate the work by the participants. 

I am also curious about which area should have this WG, I am not sure it is
RAI work, in the past there were discussions if even AVT should be in RAI or
transport.

Roni Even

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Richard Shockey
> Sent: Tuesday, January 05, 2010 3:43 AM
> To: 'Sam Hartman'; 'Patrik Fältström'
> Cc: 'Phillip Hallam-Baker'; [email-masked]; [email-masked];
> Subject: RE: WG Review: Internet Wideband Audio Codec (codec)
> 
> +1 Emphatically
>

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 5 Jan 2010 12:47:24 -0500

>  encumbered technology.

Its not about the bandwidth. Its about the quality of the voice in
occasionally lossy networks landline or mobile.

---

From: Dean Willis <[email-masked]>
Date: Tue, 5 Jan 2010 15:05:02 -0600

> occasionally lossy networks landline or mobile.

Also critically, it's about the latency introduced by the coder/ 
decoder and by any buffering necessary to account for variable latency  
in the network.

Streaming MP3 might sound really good, but it does so at the expense  
of lots of buffering that compensates for the variable latency of the  
network and associated TCP transport. Trying to use it for a phone  
call would not work so well, unless you're used to making phone calls  
to someplace well outside lunar orbit.

--
Dean

---

From: Sam Hartman <[email-masked]>
Date: Tue, 05 Jan 2010 16:36:23 -0500

>>>>> "Roni" == Roni Even <[email-masked]> writes:

    Roni> Hi, I do not think that the IETF should accept any work
    Roni> because people want to do it, if this is the case a group of
    Roni> people can come and ask to start working on any idea they have
    Roni> that has some relation to the Internet. IETF should accept
    Roni> work that is in scope for of the IETF and for which there is
    Roni> enough knowledge to evaluate the work by the participants.

I agree.  It's quite clear to me that when I read the mission statement
of the IETF, this is in scope.  My personal belief is that we have or by
chartering this work will obtain the necessary experts to evaluate the
results.

What area this belongs in seems an excellent question for the IESG.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 05 Jan 2010 20:48:34 -0700

On 1/4/10 5:39 PM, Brian West wrote:
> Is the source and spec for the SPIRIT codec out there?

http://tools.ietf.org/html/draft-spiritdsp-ipmr-00

/psa

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 05 Jan 2010 21:29:14 -0700

> enough knowledge to evaluate the work by the participants. 

Statements like this puzzle me. What is "the IETF" if not the people who
show up at our meetings, post to our mailing lists, and seek to work in
good faith within our organizational and legal framework for the benefit
of the Internet?

In the case of the proposed Codec WG we seem to have a group of
technically competent volunteers who want to "make the Internet work
better by producing high quality, relevant technical documents that
influence the way people design, use, and manage the Internet"
<http://www.ietf.org/about/mission.html> ...

These volunteers seem to be part of the "large open international
community of network designers, operators, vendors, and researchers
concerned with the evolution of the Internet architecture and the smooth
operation of the Internet" <http://www.ietf.org/about/> ...

Yes, it is true that "the issues on which the IETF produces its
documents are issues where the IETF has the competence needed to speak
to them, and that the IETF is willing to listen to technically competent
input from any source" <http://www.ietf.org/about/mission.html> ...

But I don't think we can say that relevent members of the IETF community
do *not* have the competence to work on an audio codec or that they are
*not* willing to listen to technically competent input from any source
when it comes to codec technologies. Indeed, the two BoFs at Stockholm
and Hiroshima would lead, I think, to the opposite conclusion: the
people who want to do this work appear to be competent (they have
already developed codecs like Speex, CELT, SILK, IPMR, BV16, and BV32)
and to be quite committed to rough consensus and running code, we have
some precedent for doing work of this kind within the IETF (e.g., RFC
3951), several longtime IETF participants have experience with digital
signal processing and similar technologies, a codec working group would
attract new participants with relevant areas of expertise, and people at
the BoFs appeared to be quite open to input from the IETF community or
any interested individual.

I agreed to co-chair the BoF in Hiroshima to give these folks a chance
to present their case for working within the Internet Standards Process,
and I think that case is strong. Yes, they might fail to achieve their
goals or to solve the problems they set out to solve, but that is true
of any WG for any number of reasons. We won't know unless we try, and I
see no reason to prevent them from trying.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Benjamin M. Schwartz" <[email-masked]>
Date: Tue, 05 Jan 2010 13:42:58 -0500

Brian West wrote:
> Wouldn't this go over the MTU on the RTP packets and cause some issues on the public internet?

1.  What's "this"?
2.  Send packets more frequently.

--Ben

---

From: Brian West <[email-masked]>
Date: Tue, 5 Jan 2010 12:39:17 -0600

/b

On Jan 5, 2010, at 12:13 PM, Gregory Maxwell wrote:

> "full quality" mono audio takes around 44.1/16bit linear, you can argue that a little higher or lower is required for full transparency in some conditions or another, but 44.1k/16 is what CDDA provides. It's a good number and commonly available on hardware today.
> 
> As uncompressed thats 705kbit/sec before you get into packetization overhead.  Thats per-communication channel, each way. A good perceptual lossy codec can get you down to under 100kbit/sec while preserving transparency for most material, with most listeners, most of the time.

---

From: Brian West <[email-masked]>
Date: Tue, 5 Jan 2010 12:47:16 -0600

Sending packets at lower intervals wouldn't fully solve issues related to this... you should never go over the MTU in practice anyway... and you shouldn't be running small packet times if you ever wish it to scale... sending anything less than 10ms packet times is wasteful for both the client and the server... but then again nobody seems to think of the server side of things when they design anything these days.... I just hope that everyone does consider that aspect.

/b

---

From: Brian West <[email-masked]>
Date: Tue, 5 Jan 2010 21:50:23 -0600

Hrm No source... looks like I'll have to dig more.

/b

---

From: Gregory Maxwell <[email-masked]>
Date: Tue, 5 Jan 2010 10:13:00 -0800

Networks have improved a lot. It actually is viable to send uncompressed CDDA across many wide-area networks today, at least in small amounts,  but I think we're a long way from when compression doesn't have considerable advantages, even for audio.  I think it would be fair to say that networks have become fast enough other considerations such as error robustness, perceived-transparency,  computational cost, latency, licensing considerations, etc.  are now often more important than the absolute minimization of bandwidth. but savings on the order of 8-12 : 1 are not something which can be ignored. 

8-12:1 is still a material difference in capacity and cost.   Audio is cheaper now relative to the network, but that just means we can do more of it: More quality, more capacity.

Moreover, every bit wasted on uncompressed audio could instead be spent on additional redundancy.   In a bandwidth plentiful model I'd much rather run a 128kbit/sec/ch codec sending each packet three times than a 705kbit/sec lossless stream.

---

From: Gregory Maxwell <[email-masked]>
Date: Tue, 5 Jan 2010 10:47:26 -0800

> Wouldn't this go over the MTU on the RTP packets and cause some issues on the public internet?

...

44100 samples/second * 2 bytes/sample  * 10ms/frame = 882 bytes/frame.
You might have trouble with an X.25 network in the path.

Viideo is typically operated at much higher bitrates and much much higher numbers of bytes per coding unit, in any case.

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 05 Jan 2010 20:45:02 -0800

> any interested individual.

+1

This is work we've done before and there seems to be no particular
reason that it should not be done here again.

---

From: Adrian Farrel <[email-masked]>
Date: Thu, 07 Jan 2010 10:25:23 +0000

Hi Ben,

>> I appreciate the potential difficulty of guaranteeing the unencumbered
>> status of any output of this group. However, I would like this statement 
>> to
>> be stronger, saying that this group will only produce a new codec if it 
>> is
>> strongly believed by WG rough consensus to either be unencumbered,
>> or freely licensed by the IPR holder(s), if any.
>
> For political reasons, this is unlikely to happen.

Could you elaborate?

Thanks,
Adrian

---

From: "Andrew G. Malis" <[email-masked]>
Date: Wed, 6 Jan 2010 17:59:05 -0500

As I've said before, there is a high cost to service providers every time
a new codec is introduced operationally, at the very least in the form of
full-mesh transcoding. Thus, new codecs should not be developed
lightly.

The world already has enough encumbered codecs, and there's no point in
adding yet another.

However, the draft charter states:

> 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.

I appreciate the potential difficulty of guaranteeing the unencumbered
status of any output of this group. However, I would like this statement to
be stronger, saying that this group will only produce a new codec if it is
strongly believed by WG rough consensus to either be unencumbered,
or freely licensed by the IPR holder(s), if any.

Thanks,
Andy

---

From: "Benjamin M. Schwartz" <[email-masked]>
Date: Wed, 06 Jan 2010 18:06:21 -0500

> or freely licensed by the IPR holder(s), if any.

For political reasons, this is unlikely to happen.  Instead, I hope you
will participate in the WG.  Then that rough consensus will depend on your
opinion (roughly).

--Ben

---

From: Russ Housley <[email-masked]>
Date: Thu, 07 Jan 2010 11:46:49 -0500

> or freely licensed by the IPR holder(s), if any.

I do not think that anyone wants the outcome to be yet another 
encumbered codec.  I think these words are trying to say what you want, 
but they are also trying to be realistic.

Does the following text strike a better balance?

   Although this preference cannot guarantee that the working
   group will produce an unencumbered codec, the working group shall
   follow BCP 79, and adhere to the spirit of BCP 79.  The working
   group cannot explicitly rule out the possibility of adapting
   encumbered technologies; however, the working group will try to
   avoid encumbered technologies that require royalties.

Russ

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 7 Jan 2010 09:27:42 -0800

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 ([email-masked]) 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 <[email-masked]>
> * Cullen Jennings <[email-masked]>
> 
> Real-time Applications and Infrastructure Area Advisor:
> * Cullen Jennings <[email-masked]>
> 
> Mailing Lists:
> General Discussion: [email-masked]
> To Subscribe: [email-masked]
> 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
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 7 Jan 2010 13:30:24 -0500

Russ,

Yes, that's better, thanks.

Cheers,
Andy

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 07 Jan 2010 12:08:16 -0700

>   avoid encumbered technologies that require royalties.

That seems reasonable. Although I was only the BoF co-chair, I'll
volunteer to hold the pen on edits to the proposed charter.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 07 Jan 2010 11:46:04 -0800

Hi,

Russ' language is an improvement.  But let's not forget that there are
encumbrances that have nothing to do with paying royalties, but are equally
problematic from an adoption viewpoint.  Examples:

1. Co-marketing requirement: need to put a logo of the rightholder company
on one's products acknowledging using the protected technology.
2. Unreasonable (from the viewpoint of the adopter) reciprocity
requirements: one of many examples would be "if you use this technology, you
agree not to assert, against me or my customers, any of your patents.
Otherwise your license terminates.".
3. Requirement for a "postcard license".  Such a requirement may rule out
open source implementations under certain open source licenses.

I believe strongly that a charter that discusses IPR issues should mention
at least those three aspects, and/or provide sufficiently vague language to
allow for an appropriate reaction to those and other encumbrances that may
show up.  

Royalties are the least of our problems.

Regards,
Stephan

Disclaimer: I have clients that would have problems with all three
encumbrances mentioned above.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 07 Jan 2010 16:04:45 -0500

>>>>> "Peter" == Peter Saint-Andre <[email-masked]> writes:

    Peter> On 1/7/10 9:46 AM, Russ Housley wrote:
    >>>> 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.
    >>> 
    >>> I appreciate the potential difficulty of guaranteeing the
    >>> unencumbered status of any output of this group. However, I
    >>> would like this statement to be stronger, saying that this group
    >>> will only produce a new codec if it is strongly believed by WG
    >>> rough consensus to either be unencumbered, or freely licensed by
    >>> the IPR holder(s), if any.
    >> 
    >> encumbered codec.  I think these words are trying to say what you
    >> want, but they are also trying to be realistic.
    >> 
    >> Although this preference cannot guarantee that the working group
    >> will produce an unencumbered codec, the working group shall

I agree with the concerns that Stephan expressed.  Royalties are only
one source of significant problems.

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 07 Jan 2010 14:22:28 -0800

Let me suggest to substitute "Making it easy to redistribute" with "Making
it easy to redistribute and use".

Shareware and Trialware are often freely redistributable, but not
necessarily free to use in a monetary sense.  The mechanisms that make
Trial/Shareware not freely usable are often partly of technical nature, and
not only based legal language, but that doesn't make things different in our
context.

Stephan

On 1/7/10 12:13 PM, "Jean-Marc Valin" <[email-masked]> wrote:

> Hi,
> 
> I'm not sure royalties are the *least* of out problems, but I certainly
> agree with Stephan that annoyances go further than just royalties. I
> understand that BCP79 restricts what we can say about that in the charter,
> but at least mentioning the problem as Stephan suggests is a good idea IMO.
> In some sense, this is again part of the "making it easy to redistribute".
> 
> Jean-Marc
> 
> Stephan Wenger wrote:
>> Hi,
>>

---

From: Mans Nilsson <[email-masked]>
Date: Fri, 8 Jan 2010 07:32:15 +0100

> streams and really fine on 176kbps ogg; I'd like to have that for phone  

Not free, not fast, not possible to adapt. 

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
I'm dressing up in an ill-fitting IVY-LEAGUE SUIT!!  Too late...

---

From: Herve Taddei <[email-masked]>
Date: Fri, 08 Jan 2010 16:40:05 +0100

With regard to this proposed WG, I have some comments on the sentences at
its beginning:
"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."

I think it was already pointed out a few times (at least see email from
Ingemar Johannson in November 2009), that this part needs to be modified as
some existing standard codecs (at least G.711, G.722) are already optimized
for interactive Internet applications, are published by recognized SDO
(ITU-T) and can be widely implemented. 

Besides if easily implemented means RF it should certainly be explicitely
written. Many of the codecs from e.g. ITU-T or 3GPP can be considered as
easily implementable and distributable, optimized for internet applications
and published by recognized SDOs. 

Best regards

Herve

---

From: Herve Taddei <[email-masked]>
Date: Fri, 08 Jan 2010 17:19:55 +0100

Hi Christian,

Then perhaps it is good to specify that this WG is not going to look to
narrowband and wideband but only to Superwideband and Fullband. That could
be specified in that paragraph. The name IWAC (Internet Wideband Audio Codec
(codec)) could be misleading if wideband is not going to be looked at. 

BTW, G.711 and G.722 are not speech codecs but PCM and ADPCM codecs without
any source model assumption. Also, I don’t think efficient and high quality
have the same meaning. Efficient usually brings to low bitrate and high
quality audio to higher bitrates. 

Best regards

Hervé

-----Original Message-----
From: Christian Hoene [mailto:[email-masked]] 
Sent: Friday, January 08, 2010 4:56 PM
To: 'Herve Taddei'; 'IETF Discussion'
Cc: 'IAB IAB'; [email-masked]; 'IESG IESG'
Subject: AW: [codec] WG Review: Internet Wideband Audio Codec (codec)

Dear Herve,

> (ITU-T) and can be widely implemented

... with the difference that G.711 and G.722 are not audio but narrow and
wideband speech codecs. 
They are not very efficient (=high-quality) either.

With best regards,

 Christian

---

From: Herve Taddei <[email-masked]>
Date: Thu, 07 Jan 2010 17:59:48 +0100

What do you mean by "this is work we have done before"? At least it has
never been the case in IETF, if that was the case why were there all these
discussions that IETF do not have the expertise to do that work?

There have been some activities to rubberstamp some codecs (iLBC, Speex
following some experimental tracks) but no activities related to the
standardization of new audio codecs.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Joel Jaeggli
Sent: Wednesday, January 06, 2010 5:45 AM
To: Peter Saint-Andre
Cc: [email-masked]; [email-masked]; 'Sam Hartman'; [email-masked];
'Richard Shockey'; ik Fältström'; [email-masked]; "'Patr"@core3.amsl.com;
'Phillip Hallam-Baker'
Subject: Re: [codec] WG Review: Internet Wideband Audio Codec (codec)

+1

---

From: "Christian Hoene" <[email-masked]>
Date: Fri, 8 Jan 2010 16:55:46 +0100

Dear Herve,

With best regards,

 Christian

---

From: Joel Jaeggli <[email-masked]>
Date: Thu, 07 Jan 2010 12:04:37 -0800

> standardization of new audio codecs.

I find it unlikely in the extreme that a bunch of engineers will sit
around in an ietf meeting and dream up a new audio codec. instead
inviduals will bring existing work into a working group, where it will
be accepted or not based on the charter, interest in the work etc.

To pick out speex for example audio codec geeks know the history of
celp, they also know the history of the development of speex by
Jean-Marc Valin. that's fairly congruent with my expectations as to how
this process would work on the front-end.

Show up with draft text and running code is vastly prefered to starting
with nothing.

---

From: John C Klensin <[email-masked]>
Date: Thu, 07 Jan 2010 21:59:20 -0500

--On Thursday, January 07, 2010 11:46 -0500 Russ Housley
<[email-masked]> wrote:

> encumbered codec.  I think these words are trying to say what
> you want, but they are also trying to be realistic.
> 
> shall

Yes.  Considerable improvement, IMO.  Out of deference to
often-stated other concerns, "require royalities" should be
something like "require royalties or explicit per-implementation
or per-user licensing", but I think that is in the spirit of
where you are going.

    john

---

From: Mans Nilsson <[email-masked]>
Date: Fri, 8 Jan 2010 21:05:37 +0100

> (ITU-T) and can be widely implemented. 

G.711 and G.722 are not broadcast quality, while for example CELT is
suitable for music. Some realtime interactive uses of audio over IP
would greatly benefit from 20KHz bandwidth and stereo. Stopping att the
bakelite receiver is a  mistake.
 
/Måns
-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
Please come home with me ... I have Tylenol!!

---

From: Russ Housley <[email-masked]>
Date: Fri, 08 Jan 2010 18:14:46 -0500

Good improvement.  I'd go a slide bit further:

    Although this preference cannot guarantee that the working
    group will produce an unencumbered codec, the working group shall
    follow BCP 79, and adhere to the spirit of BCP 79.  The working
    group cannot explicitly rule out the possibility of adapting
    encumbered technologies; however, the working group will try to
    avoid encumbered technologies that would hinder free
    redistribution in any way.

Russ

On 1/7/2010 3:13 PM, Jean-Marc Valin wrote:
>> On 1/7/10 11:08 AM, "Peter Saint-Andre"<[email-masked]>  wrote:
>>

---

From: Adrian Farrel <[email-masked]>
Date: Sat, 09 Jan 2010 00:20:06 +0000

"adapting" or "adopting"?
----- Original Message ----- 
From: "Russ Housley" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Friday, January 08, 2010 11:14 PM
Subject: Re: [codec] WG Review: Internet Wideband Audio Codec (codec)

>>>>>> unencumbered
>>>>> want,

---

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 8 Jan 2010 18:32:50 -0600

I would have guessed "adopting" (nice catch. I missed it completely). but 
other than this, I wanted to say that Russ's new formula seemed more in 
synch with what I've been seeing on this list - much stronger than "will 
try" (would be nice).

Thanks,

Spencer

---

From: Jean-Marc Valin <[email-masked]>
Date: Fri, 08 Jan 2010 21:43:49 -0500

I like that.

---

From: Jean-Marc Valin <[email-masked]>
Date: Mon, 11 Jan 2010 10:32:53 -0500

Hi,

Regardless of the exact status of the PLC IPR, I don't think it would be a good
idea to just say that "the Internet should just follow ITU-T standards with a
20-year lag". As it has been already shown with the codec proposals received to
date, it should be possible to create RF codecs that are *much* better than
G.722 and G.711.

   Jean-Marc

Quoting Steve Underwood <[email-masked]>:

> On 01/11/2010 11:00 PM, Christian Hoene wrote:
> > Dear Herve Taddei,
> >
> >
> >> Besides, I don't think you would have any trouble to propose at ITU-T some
> >> new appendices to G.711 and G.722 that could fit your goals. An appendix
> is
> >> non normative (a bit like the informative reference to G.711 PLC in iLBC).
> >> By the way, if I am not wrong, some basic ITU-T G.722 PLCs are RF.
> >>
> > This was my understanding, too.
> >
> The G.722 spec is 23 years old, so it would be difficult for any of the
> patents on that spec to still be valid. The ITU patent database does
> list US patent 5528629 as related to G.722, but I assume this is an
> error. The patent dates from so long after G.722 came out, and its
> contents do not appear relevant to G.722. However, the recent additions
> for PLC are:
>
>      G.722 (1988) App IV - Broadcom has claims
>      G.722 Appendix III - Broadcom has claims
>      G.722 Appendix IV - France Telecom has claims.
>
> Have you seen any clear statements that those patents may be used
> royalty free?
>
> Steve
>

---

From: Jean-Marc Valin <[email-masked]>
Date: Thu, 07 Jan 2010 15:13:00 -0500

Hi,

	Jean-Marc

---

From: "Michael Ramalho (mramalho)" <[email-masked]>
Date: Fri, 8 Jan 2010 11:46:32 -0600

Jean-Marc,

FWIW, I agree with the "other encumbrances" issues that Stephan raises.

The "Co-Marketing" requirement assumes that a logo (or other
acknowledgement form) has marketing VALUE to the rightholder. In that
sense, such a requirement has a worth (i.e., has some value related to
money) that is the equivalent of a monetary payment for some. Indeed,
many companies would reject use of the technology for this reason (this
has been the case for some audio codecs already).

The "co-marketing" encumbrance does NOT affect the easiness or hardness
of the redistribution per se ... but rather the attractiveness of the
receiving company to accept it.

These "annoyances" are sticky wickets indeed ... limited only be
creativeness of people to put "non-monetary" conditions on the
technology after-the-fact (as is their right).

FWIW#2 - I think you have probably addressed the issue as far as
feasible for now.

Ciao,

Michael Ramalho

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Jean-Marc Valin
Sent: Thursday, January 07, 2010 3:13 PM
To: Stephan Wenger
Cc: [email-masked]; Russ Housley; [email-masked]; [email-masked]
Subject: Re: [codec] WG Review: Internet Wideband Audio Codec (codec)

Hi,

I'm not sure royalties are the *least* of out problems, but I certainly
agree with Stephan that annoyances go further than just royalties. I
understand that BCP79 restricts what we can say about that in the
charter,
but at least mentioning the problem as Stephan suggests is a good idea
IMO.
In some sense, this is again part of the "making it easy to
redistribute".

	Jean-Marc

unencumbered
>>>> be stronger, saying that this group will only produce a new codec
if
>>>> it is
want,

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Mon, 11 Jan 2010 18:24:36 +0200

I wonder how far away from the original discussion about the charter we
already are. 
Many of these discussions should happen in a future working group. 

Ciao
Hannes

---

From: Stephan Wenger <[email-masked]>
Date: Mon, 11 Jan 2010 11:43:36 -0800

Hi Jean-Marc,

I don't think anything "has been shown", with respect to IPR and RF
properties of the current input proposal documents.  And I don't believe
anything conclusive will be shown, ever.  At best, arguably, nothing
substantial has been shown against an RF claim of the input proposals.
Arguably", because the Skype assurance in
https://datatracker.ietf.org/ipr/1164/ is hardly a strongly worded, binding,
non-assert or license.

Theoretically, even the 23 year timeframe (of publication of G.722) does not
(yet) provide full certainty under US law against patent encumbrances;
though the position of a G.722 user is probably very strong now.  Look up
"prosecution laches" if you want to know how I came to these conclusions.

I completely agree that we should not exclusively rely on 20 year old
technologies on a mission to "make the Internet work better", not even on
the grounds of patent fears.  Expect me to use this argument occasionally
:-)
 
Stephan

---

From: Jean-Marc Valin <[email-masked]>
Date: Mon, 11 Jan 2010 13:22:57 -0500

Sorry, my "has been shown" statement was about "making something much better
than G.722/G.711". The IPR part is something that would need to be discussed
within a future WG (subject to BCP79 and all).

   Jean-Marc

Quoting Stephan Wenger <[email-masked]>:

> > 20-year lag". As it has been already shown with the codec proposals
> received
> > to

---

From: "Roni Even" <[email-masked]>
Date: Mon, 11 Jan 2010 21:01:20 +0200

Hannes,
To me the discussion suggests that what is missing in the charter is a
requirement for a gap analysis document after finalizing the requirements.
There was an email from Cullen on January 7th discussing this point
Roni Even

> Tschofenig, Hannes (NSN - FI/Espoo)
> Sent: Monday, January 11, 2010 6:25 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [codec] WG Review: Internet Wideband Audio Codec (codec)
>

---

From: Xavier Marjou <[email-masked]>
Date: Mon, 11 Jan 2010 21:18:38 +0100

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
> 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)
>
> the result should not depend on the details of any particular
> signaling technology
>
> 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:

> 1. A set of technical Requirements. This document shall be
> Informational.
>
> Milestones
>
> 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 <[email-masked]> wrote:
> 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.
>

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Tue, 12 Jan 2010 10:59:37 +0100

Hi Christian and others

Timescaling and jitter buffer management is AFAIK not included in the codec specifications done in other standards foras. But that does not mean that it is left unspecified. In 3GPP TS we settled with a specification of only the requirements
http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-910.zip 
There are many reasons to why we did this, one is that we regard time scaling as yet another pre/post processing algo like packet loss concealment, echo cancellation or noise suppression, and the hard cold truth is that the less one need to specify in terms of code so much the better (go figure..). We needed however to set some requirements however to avoid poor implementations. 

With the above in mind I would claim that it is wrong to state that the answer to statement 2) below is a NO.

/Ingemar 

From: "Christian Hoene" <hoene at uni-tuebingen.de> 
To: "'Xavier Marjou'" <xavier.marjou at orange-ftgroup.com> 
Cc: 'IAB IAB' <iab at iab.org>, codec at ietf.org, 'IETF Discussion' <ietf at ietf.org>, 'IESG IESG' <iesg at ietf.org> 
Date: Tue, 12 Jan 2010 01:27:43 +0100 
In-reply-to: <458913681001111218o3b232e4sd785b3c09809fcbc at mail.gmail.com> 
References: <20091223171501.7BAE33A697D at core3.amsl.com> <13194D66-2110-4CB2-B130-8807BE57488B at cisco.com> <458913681001111218o3b232e4sd785b3c09809fcbc at mail.gmail.com> 

--------------------------------------------------------------------------------

Snip snip...

> that was done it would be re-charted for (2) and so on. "

Obviously, the current requirements document does contain features which are
not supported by today's standardized codecs. As an example, take time
stretching and time compression. Thus, everybody following the discussion
must come to the conclusion that (2) has been answered with no. 

=================================
INGEMAR JOHANSSON  M.Sc. 
Senior Research Engineer 

Ericsson AB
Multimedia Technologies
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289
[email-masked]
www.ericsson.com 
Visit http://labs.ericsson.com !
=================================

---

From: Adrian Farrel <[email-masked]>
Date: Tue, 12 Jan 2010 12:14:18 +0000

Stefan,

> until now other SDOs have failed to produce a widely distributed good 
> quality wideband and full-band codec that would be suitable for the 
> Internet - especially one that is easily distributable - even though the 
> necessary technology has been available for a long time. Further, nothing 
> has substantially changed lately to make it likely that other SDOs are now 
> suddenly willing to or capable of doing that.
>
> The proposal to make IETF CODEC development depend on other SDOs is thus 
> not a constructive one and should not be followed.

Your logic may be flawed.

Until now the IETF has failed to produce a widely distributed good
 quality wideband and full-band codec that would be suitable for the
 Internet - especially one that is easily distributable - even though the
 necessary technology has been available for a long time.

But you don't suggest that as a reason not to do the work in the IETF.

The proposed draft charter does not state that the IETF work should be gated 
on other SDOs nor that the IETF shall not develop a Codec. Rather, it states 
the value of sharing the requirements work developed in the IETF with other 
SDOs, and it notes the benefits of listening to other SDOs if they point to 
existing Codecs that meet or nearly meet the requirements.

In the unlikely event that another SDO says "thanks for the requirements we 
would like to develop a solution in our SDO" we will need to examine the 
feasibility of their proposal and how people can best work on a solution. 
There does not seem to be any benefit in developing two Codecs to meet the 
same set of requirements.

As to Xavier's point: I think he is right that the wording in the charter 
could be usefully re-ordered so that the consultation is mentioned before 
the determination to develop a new solution.

Cheers,
Adrian

---

From: "Christian Hoene" <[email-masked]>
Date: Tue, 12 Jan 2010 01:27:43 +0100

Dear Xavior Marjou,

> (gateways) and quality degradations.

I have heard similar concerns from German traditional telcos, too. However,
the currently envisioned codec is based on a more Internet like scenario: a
dumb network and smart end terminal. This means: fewer gateways and less
transcoding inside the network but smarter end terminals (=phones). Also,
the codec is intended to be used in an end-to-end fashion with the encoding
and decoding done at the Internet phones. 

If a phone needs to communicate with a gateway, it can use G.729 or G.711.
Thus, I do not see an immediate need to enhance gateways to support the new
codec nor any costs involved with that. Similar, phones must not be updated
if the old small or wideband quality is sufficient. 

Every new technology comes with bugs and problems at the beginning. But the
new codec will have new features and better quality (e.g. playing music and
listening to music, higher reliability because of rate adaptation, etc.),
which will attract customers. Thus, one should bear the costs to deploy it;
otherwise a provider will lose its market share.

> decision to continue in stage 3 to produce a new codec and re-Charter

Your changes look like an attempt to slow down and hinder the work. As
Monty, I have to object your arguments.

With best regards,

 Christian

---

From: Stefan Sayer <[email-masked]>
Date: Tue, 12 Jan 2010 10:54:40 +0100

Hello,

until now other SDOs have failed to produce a widely distributed good 
quality wideband and full-band codec that would be suitable for the 
Internet - especially one that is easily distributable - even though the 
necessary technology has been available for a long time. Further, 
nothing has substantially changed lately to make it likely that other 
SDOs are now suddenly willing to or capable of doing that.

Best Regards
Stefan Sayer

---

From: Monty Montgomery <[email-masked]>
Date: Mon, 11 Jan 2010 17:22:16 -0500

This is about to start another time around the same circle, but if the
arguments need to be restated, I'll take a turn on this lap.

> (gateways) and quality degradations.

Although it is something of an aside, I find it difficult to believe
that this would ever be seriously considered within the ITU as a
reason why a clearly better codec should not be implemented and
offered for sale*[1].

I also find it somewhat difficult to believe, despite the real costs
of adding another row/column to full-matrix transcode, that commercial
providers would become very cross at the idea of a higher performance
standardized codec for free.

> that was done it would be re-charted for (2) and so on. "

Dibs on the first donut at the meeting planning meeting pre-meeting!

To address the points:

1) yes, we need a consensus on requirements. We can synthesize
requirements as a low-bar aggregation of the performance numbers of
already-demonstrated best of breed. At least, that's a decent enough
empirical strategy.  We know what the current commercial codecs can
do, we know what the available free codecs can do that will be inputs
to this process and we know that there's demand for unencumbered
deployment.  The requirements doc, as screenwriters might say, "writes
itself" (the union of what we can do and what the world needs).  It
does need to be done of course, and screenwriters can't live without
thoughful editors, but what part of this is actually controversial?

2) we are here because the lack of a suitable standardized codec has
already been demonstrated.  The driving impetus behind the proposal is
only partly technical.  If, for example, the ITU wanted to view this
as an insurrection to be crushed*[2], it could do so by offering
suitable current-generation codecs without licensing strings, but we
believe this isn't possible and it's not even fair to offer as a
straw-man.  Further, we believe that it is also not possible to start
fresh and arrive at a royalty-free result solely within the ITU or
MPEG or elsewhere as there are no examples of such. That said,
collaboration is highly desirable.  I don't presume to posess
technical insight superior to the ITU.

> discussed and agreed with the relevant SDOs and the WG Charter will be

...which effectivly amounts to first stopping dead, and then ceding
large chunks of the decision making process to outside groups with no
previously demonstrated interest in our goals.  This doesn't make much
sense.  'Collaboration with the IETF' becomes a
joint-venture-by-committee at best.  Though it is important to be in
active communication with other SDOs, the idea of proceeding within
the IETF is because IETF participants have expressed interest where
other SDOs haven't.  I propose that we do not wait for any and all
passengers to meander to the station in their good time; those who
show up before the train leaves according to schedule are welcome to
get on board*[3]. There will be multiple stations along the route, of
course.

3) Several free codecs have been demonstrated that fufill basic
operating requirements. However, we have a unique opportunity to
leverage the strengths of several members of the field into an even
stronger contender.  As stated multiple times in this process, we are
not interested in rubber stamping.  I would consider it a wasted
opportunity.  We have the rare spectacle of multiple groups of experts
willing to work together to produce a new, state-of the art audio
codec (or codecs) with no royalty or licensing strings attached at the
same time there is demand for exactly this!  There is demand, there is
interest, there is motivation.

Monty
Xiph.Org

[1] one would expect the result to be a commercial product
[2] "You are a Rebel and a Traitor!  Take her away!" I always thought
it was better in David Prowse's own voice honestly.
[3] Please mind the doors. Another train will doubtless be along presently.

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 12 Jan 2010 15:50:13 -0500

Quoting stephen botzko <[email-masked]>:

> I kind of like the joint body idea.
>
> One reason is that it brings the ITU codec characterization/testing
> strengths into the process.
>
> Though it might take a little longer to get going, it could save a lot of
> time at the end (IMHO).

I fully agree here. We should seek to collaborate with the ITU if possible. At
the same time, I think we should not assume that such collaboration will be
possible in the end, so the best would be to get started while at the same time
seeking to collaborate. Considering that the main strength of the ITU process
is in characterization/testing, there's a lot we can accomplish before reaching
that stage.

   Jean-Marc

> Stephen Botzko
> Polycom
>
> On Tue, Jan 12, 2010 at 12:03 PM, Jean-Marc Valin <
> [email-masked]> wrote:
>
> > Hi Adrian,
> >
> > During the last BoF in Hiroshima, there was a very useful presentation by
> > Yusuke Hiwasaki (SG16-Q10 Associate Rapporteur) about how the ITU-T works
> > (slides at: http://www.ietf.org/proceedings/76/slides/codec-2.pdf). From
> > what I understand, there are two main reasons why the ITU-T cannot take on
> > this work by itself:
> > 1) Membership isn't open like the IETF, but most importantly
> > 2) IPR/licensing issues cannot be discussed during the development period
> >
> > There were two proposed workarounds to these (see slide 15). First a focus
> > group was proposed to allow non-ITU members to discuss. Unfortunately, that
> > solution does not address the IPR issue, nor does it address the fact that
> > ITU focus groups cannot create standards in the first place. So the only
> > alternative that was left was to do a joint body with an IETF WG (similar
> > to the JVT between MPEG and ITU that led to H.264). That means we need an
> > IETF WG that can actually develop codecs to begin with.
> >
> > In general, I think it's really time to get the work going and, as Monty
> > put it, not get into meeting pre-meetings to discuss whether we will hold
> > future meetings. At this point, there is significant interest, there are
> > people willing to do the work and there are even four proposals on the
> > table. Right now, the only concern that has been expressed over this work
> > was about having one more codec that vendors would have to support. I don't
> > think that's a very strong argument considering the existing number of
> > codecs out there and especially the fact that what we are proposing here is
> > to take *four* non-standard codecs and make one standard codec out of them.
> > I can't see how that would be a bad thing.
> >
> > Cheers,
> >
> >        Jean-Marc
> >
> >
> >
> > Adrian Farrel wrote:
> > > Stefan,
> > >
> > nothing

---

From: "Roni Even" <[email-masked]>
Date: Wed, 13 Jan 2010 15:04:58 +0200

Hi Jean-Marc,
I was happy to see your sentence " especially the fact that what we are
proposing here is to take *four* non-standard codecs and make one standard
codec out of them." 
I hope that the charter will be strict about that.

Roni Even

> Sent: Tuesday, January 12, 2010 7:04 PM
> To: Adrian Farrel
> Cc: [email-masked]; IETF Discussion; IAB IAB; IESG IESG
> >> has substantially changed lately to make it likely that other SDOs
> are
> >> now
> > The proposed draft charter does not state that the IETF work should
> be
> > gated

---

From: Russ Housley <[email-masked]>
Date: Wed, 13 Jan 2010 10:05:20 -0500

>> I see absolutely no good reason not to start the work and do
>> negotiations with other SDOs on the side.
>
> That is thw way these joint bodies are usually formed (at least the
> MPEG/ITU-T ones).  The group(s) form, and begin their
> work.(independently)  In parallel the chairs and SDO management work out
> the joint body organization.  It is easiest if the discussions on joint
> body organization begin as soon as possible.

My experience is different.  When the IETF works with another SDO, the 
final steps in approval are extremely painful.  The IETF process does 
not meld well with others, and the result is that getting the exact same 
words published by both organizations is a near deadlock experience.  It 
has been done, but only because of heroic efforts by chairs and editors. 
  For this reason, I prefer a situation where one SDO runs their own 
process and the result is submitted to partners after the words are 
final.  Of course, collaboration during the development of the document 
is most welcome, but the process rules of one SDO are governing the 
development.

Russ

---

From: "Gregory M. Lebovitz" <[email-masked]>
Date: Wed, 13 Jan 2010 08:14:52 -0800

At 07:05 AM 1/13/2010, Russ Housley wrote:

>My experience is different.  When the IETF works with another SDO, 
>the final steps in approval are extremely painful.  The IETF process 
>does not meld well with others, and the result is that getting the 
>exact same words published by both organizations is a near deadlock 
>experience.  It has been done, but only because of heroic efforts by 
>chairs and editors.  For this reason, I prefer a situation where one 
>SDO runs their own process and the result is submitted to partners 
>after the words are final.  Of course, collaboration during the 
>development of the document is most welcome, but the process rules 
>of one SDO are governing the development.

Agreed. And now we are continuing to re-trace old steps repeatedly. 
We had this discussion already before the Hiroshma BoF, and in the 
Hiroshima BoF. We concluded that likely the most positive form of 
collaboration we could have with the other SDO's on this topic was 
for the IETF work to run it's course, -- while (a) inviting the 
individuals and companies and experts from the other SDOs to 
participate and contribute openly, and (b) liaising regularly on our 
progress and inviting input -- publish it's first set of RFC's (and 
remember, RFC's are documents that may be standards track, but new 
work doesn't start as a standard, only a proposed standard, i.e. we 
can revise them over time, or kill them later, if we so choose), then 
work with other SDOs on modifications or joint promotion or whatever. 
The key here is that the IETF first needs to run its own process so 
that we know clearly what we want technically and business-wise, and 
have an example of something we think fits the description, and we 
document those in an RFC or two. Then we can more effectively engage 
with other SDOs at a textual level. This is my take away from the 
lessons learned to which Russ refers.

Hth,
Gregory

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 13 Jan 2010 11:21:38 -0500

While I see the burden and pain Russ mentions, I also want to note that
there is a distinct advantage of a joint project: the project would be bound
to the patent policies of both IETF and the other body (here: ITU).

In the specific case of the codec work, a joint project provides an
insurance policy for those companies that may be forced to pick up the
resulting standard, without really interested in taking the risk of using
something without having at least a solid RAND commitment in place.

If I were to summarize the IETF's patent policy in one sentence, it would be
"disclose or do not cotribute".  And the ITU's "if you are a member, it's
RAND".  To be bound by both policies means that the users of a forthcoming
standard could rely on the IETF's timely disclosure policy and working group
reaction for those companies that actively participate (through
individuals), and on a RAND commitment from those companies who don't (and
are ITU members, but the vast majority of the IP players in the codec field
are, IMHO).

Considering that you guys are determined to walk into a minefield, it may be
worth to buy this insurance.

Stephan

---

From: Alexander Chemeris <[email-masked]>
Date: Wed, 13 Jan 2010 13:26:52 +0300

Hello Christian,

> and decoding done at the Internet phones.

This is not entirely right. This codec should be also useful in conference
scenarios, where you have to decode it at conference server and encode
mixed signal again. And if I haven't missed something, this use-case was
explicitly listed in codec requirements.
On the other hand, it was stated in the same requirements, that interoperability
with older codecs is not a goal.

-- 
Regards,
Alexander Chemeris.

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 12 Jan 2010 12:03:41 -0500

Hi Adrian,

Cheers,

	Jean-Marc

---

From: stephen botzko <[email-masked]>
Date: Tue, 12 Jan 2010 15:22:17 -0500

Stephen Botzko
Polycom

---

From: stephen botzko <[email-masked]>
Date: Tue, 12 Jan 2010 15:48:45 -0500

A joint-body first agrees upon its charter and working methods, which allows
for any negotiation on IPR rules and membership, etc.

All of the companies I know who are active in the ITU are also active in the
IETF.  So it seems to me that there should be some willingness to work
together.

In any event, if the joint-body negotiations fail, then the IETF simply
proceeds on its own.  There is not much to lose, and as you seem to agree,
potentially a lot to gain.

Stephen Botzko
Polycom

On Tue, Jan 12, 2010 at 3:39 PM, Monty Montgomery <[email-masked]>wrote:

> On Tue, Jan 12, 2010 at 3:22 PM, stephen botzko
> <[email-masked]> wrote:
> Is there indication that desire exists within the ITU to formalize a
> completely unencumbered codec?  There is no doubt that the ITU has
> vast expertise and resources directly relevant to what we're doing.
>
> We have seen there is that interest in MPEG, but one can understand it
> hasn't happened because the MPEG process is stacked against it.  That
> stacking would appear to exist in the ITU as well.  Is there a
> parallel situation where there's always been strong unencumbered
> baseline interest within the ITU that simply isn't obvious from the
> outside? Such interest would seem to be a requirement for a successful
> joint body.
>
> If that interest exists within the ITU and those Open/Free proponents
> sense an opportunity to ger 'er done by cooperating with the IETF...
> well. That's an entirely different matter and cause for optimism.  Is
> it the case?  I apologize for my lack of knowledge on this matter.
>
> Monty
> Xiph.Org
>

---

From: stephen botzko <[email-masked]>
Date: Wed, 13 Jan 2010 06:22:52 -0500

That is thw way these joint bodies are usually formed (at least the
MPEG/ITU-T ones).  The group(s) form, and begin their work.(independently)
In parallel the chairs and SDO management work out the joint body
organization.  It is easiest if the discussions on joint body organization
begin as soon as possible.

Stephen Botzko
Polycom

On Wed, Jan 13, 2010 at 2:06 AM, Mikael Abrahamsson <[email-masked]>wrote:

> On Tue, 12 Jan 2010, stephen botzko wrote:
>
> Ok, in IETF spirit of "running code" etc, just start the IETF WG and start
> the work, and at the same time inform ITU about what's happening, and invite
> them to participate in the process.
>
> Talking about work is just talking and is not productive. Actually starting
> the work brings urgency to the table and will increase leverage to any
> negotiations that might be taking place.
>
> "Would the people saying it's impossible please get out of the way of the
> people actually doing it"
>
> I see absolutely no good reason not to start the work and do negotiations
> with other SDOs on the side.
>
> --
> Mikael Abrahamsson    email: [email-masked]
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 13 Jan 2010 08:06:40 +0100 (CET)

Ok, in IETF spirit of "running code" etc, just start the IETF WG and start 
the work, and at the same time inform ITU about what's happening, and 
invite them to participate in the process.

Talking about work is just talking and is not productive. Actually 
starting the work brings urgency to the table and will increase leverage 
to any negotiations that might be taking place.

---

From: Monty Montgomery <[email-masked]>
Date: Tue, 12 Jan 2010 13:39:15 -0500

>> quality wideband and full-band codec that would be suitable for the Internet

'Failed' is not quite the right word word.  It is more that [to date]
they have shown little interest and as such have not tried.  However
if they did try, I expect the attempt would indeed fail.

[Actually, I believe there has always been strong minority interest
within MPEG for unencumbered baselines, but the process and
institutions there are such that it hasn't and probably couldn't
happen.  Thus, as an organization, I assert MPEG 'has not attempted'
such a thing even if some members within have advocated for it
strongly or tried to set an unencumbered process in motion.]

> necessary technology has been available for a long time.

Quite incorrect.  The IETF consists of its participants, and several
IETF participants have produced widely distributed good quality
wideband and full-band codecs suitable for the Internet.  The IETF has
not _blessed_ or _standardized_ any of these to date.  But it has
produced several [passively].

> same set of requirements.

That would only happen in the case that one of those codecs were
produced in a closed or encumbered process.  The open codec would and
should appropriate any good idea available to it.  We are listening
(and searching with prying, beady eyes).  I do not, however, want to
enshrine the necessity to wait, indefinitely, on outside interests
whose own goals may be at odds with or at least indifferent to our
own.

Let me be frank: I want the ITU, MPEG and others involved, but I
expect the need for prodding and cajoling to make collaboration work.
Our interests at this moment seem poorly aligned on at least one key
point, as such, I object to the charter granting outside SDOs a 'go
slower' button.  I am not suggesting acting in bad faith or trying to
cut anyone out.

Monty

---

From: Monty Montgomery <[email-masked]>
Date: Tue, 12 Jan 2010 15:39:02 -0500

Monty
Xiph.Org

---

From: <[email-masked]>
Date: Fri, 15 Jan 2010 15:46:16 +0100

Hello

> Obviously, the current requirements document does contain features which are not supported by today's standardized codecs. As an example, take time
> stretching and time compression. Thus, everybody following the discussion must come to the conclusion that (2) has been answered with no.  

The requirements document is part of the deliverables identified in the Charter for May 2010. So it has to be produced by the Group once agreed to be launched : work has still to be done and drawing conclusions now on the basis of this document is not acceptable.

It is also stated in 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"
Why then bother other SDOs with this if the answer is already known and is so obviously "no" ?

Regarding the point related to time stretching and shortening, if it is the only requirement not met, we all now that adaptive jitter management can be considered as an additional function at the decoder side that can be handled outside the codec itself. And if you really still need to increase performance by some modifications at encoder side (on the basis on "non existing yet" performance requirements ) it would be much easier to have an existing standard extended by ITU-T or 3GPP than developping a fully new codec for this !

So I disagree with your conclusion and related arguments : let's establish and agree on real technical requirements first and then analyse existing standards and possible efficient adaptations before starting developping et new codec ! 

Best regards

Stephane

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Christian Hoene
Envoyé : mardi 12 janvier 2010 01:28
À : MARJOU Xavier RD-CORE-LAN
Cc : 'IAB IAB'; [email-masked]; 'IETF Discussion'; 'IESG IESG'
Objet : Re: [codec] WG Review: Internet Wideband Audio Codec (codec)

Dear Xavior Marjou,

> (gateways) and quality degradations.

I have heard similar concerns from German traditional telcos, too. However, the currently envisioned codec is based on a more Internet like scenario: a dumb network and smart end terminal. This means: fewer gateways and less transcoding inside the network but smarter end terminals (=phones). Also, the codec is intended to be used in an end-to-end fashion with the encoding and decoding done at the Internet phones. 

If a phone needs to communicate with a gateway, it can use G.729 or G.711.
Thus, I do not see an immediate need to enhance gateways to support the new codec nor any costs involved with that. Similar, phones must not be updated if the old small or wideband quality is sufficient. 

Every new technology comes with bugs and problems at the beginning. But the new codec will have new features and better quality (e.g. playing music and listening to music, higher reliability because of rate adaptation, etc.), which will attract customers. Thus, one should bear the costs to deploy it; otherwise a provider will lose its market share.

> that was done it would be re-charted for (2) and so on. "

Obviously, the current requirements document does contain features which are not supported by today's standardized codecs. As an example, take time stretching and time compression. Thus, everybody following the discussion must come to the conclusion that (2) has been answered with no. 

> decision to continue in stage 3 to produce a new codec and re-Charter 

Your changes look like an attempt to slow down and hinder the work. As Monty, I have to object your arguments.

With best regards,

 Christian

*********************************
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.
********************************

---

From: "Roni Even" <[email-masked]>
Date: Tue, 19 Jan 2010 12:38:17 +0200

Hi Sjoerd,
I noticed that you mentioned that you ran into these situations, can you be
more specific about what were the requirements, which codec were considered
and why they were not good for your customers.
This may help with selecting a good codec.
Thanks
Roni Even

> Of Sjoerd Simons
> Sent: Tuesday, January 19, 2010 12:37 AM
> To: [email-masked]; [email-masked]; [email-masked]
> On Wed, Dec 23, 2009 at 09:15:01AM -0800, IESG Secretary wrote:
> As part of my job for an open source consultancy specialising in real-
> time
> communications i see both of the issues mentioned above occur from time
> to
> time. As such i'm very exited to see a proposal for an IETF working
> group
> which addresses these very issues. And therefor i fully endorse the
> creation of
> this working group and will be eagerly awaiting it results.
> 
> Sjoerd Simons

---

From: Herve Taddei <[email-masked]>
Date: Tue, 19 Jan 2010 15:47:05 +0100

Actually I also like both ideas, either joint body as written by Jean Marc
or the proposal made by Xavier "Requirements established first in stage 1
shall be sent for stage 2 to other SDOs". 

Herve 

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
stephen botzko
Sent: Tuesday, January 12, 2010 9:22 PM
To: Jean-Marc Valin
Cc: IESG IESG; IAB IAB; [email-masked]; Adrian Farrel; IETF Discussion
Subject: Re: [codec] WG Review: Internet Wideband Audio Codec (codec)

Stephen Botzko
Polycom

On Tue, Jan 12, 2010 at 12:03 PM, Jean-Marc Valin
<[email-masked]> wrote:

Hi Adrian,

Cheers,

       Jean-Marc

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 19 Jan 2010 11:01:30 -0500

Hi,

[email-masked] wrote:
> 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"

While I do think that "there are no standardized, high-quality audio codecs
that meet all of the following three conditions", it don't think it costs
anything to communicate the requirements to other SDOs to keep them
informed. There's also the (IMHO remote) possibility that a new codec in
another SDO gets created that fills the requirements. In any case, I do not
see a reason to stall the process waiting for all other SDOs that produce
codecs to respond. I don't believe the ITU-T/MPEG/3GPP work that way
either. We can't just keep doing liaisons, discussing process and holding
meetings. At some point it's also time to get work done. That being said, I
don't think anyone involved in this effort is there just for the fun of
writing codecs. If there wasn't a real need we wouldn't be here.

Cheers,

	Jean-Marc

---

From: John Kostogiannis <[email-masked]>
Date: Mon, 18 Jan 2010 16:44:20 +1100

Hi
Personally, I am excited about the prospects of such an outcome and of 
the view that we need to let the IETF work proceed and run its full course.

cheers

John Kostogiannis
Voicetronix
Powering Open Telephony
www.voicetronix.com
Tel: +61 2 9231 4800
Fax: +61 2 9231 4811

---

From: Ron <[email-masked]>
Date: Mon, 18 Jan 2010 01:59:10 +1030

Hi,

At the outset of this process, I was quite simply excited by the
prospect of a group of talented codec researchers joining forces to
push the limits of their art, with a shared aim of producing the
next generation of codecs, tailored to suit modern transports, and
to the needs of a broader range of application developers, for whom
wide accessibility and interoperability are of paramount importance.
The work on this is already developing well.  But as has been noted
many times by both the proponents and opponents of forming this group,
we will have a far superior outcome on the whole if the collective
insights of these people are combined into a minimal number of codecs
that meet the identified goals, than we would have if each group were
to simply continue producing their own work separately as we have been
seeing to date.  (ironically, that may be the only thing certain to
occur if this proposed group does not ultimately form somewhere)

Real-time audio communication, today, is still a horribly fragmented
and thoroughly monopolised service.  But the internet routes around
damage so it is said, and I have been rather delighted to observe
that very process in action here already.  There are a lot of people
here now who want that to end.  We've already seen some interesting
(and perhaps to some, unexpected) players ante in to take part in the
first round.  I doubt I'd be going far out on a limb to suggest there
will be others, if this first round looks like fun and achieves some
notable results.  Which so far, I have no reason to doubt it will.

As to the question of whether to form this group under the auspices
of the IETF, we've seen a lot of recurring emphasis put upon which
SDO should have the first claim to hosting it, or some special veto
on what it produces.  To my eyes, that sort of ownership angst seems
off the mark.  The organisation that hosts it and may finally proclaim
it gold, is by far secondary to the set of working processes that the
active participants agree upon to resolve their differences and cement
their agreements.  That is what will ultimately decide whether this
project succeeds or fails at its stated goals.  All of these people
could produce quality codecs on their own.  They've already proven
that point so it's not in question.  The interesting question is what
can they do if given just a few simple rules for working together.

It seems quite clear at this stage, that the people who want this work
to begin in earnest _today_, have self-selected on the IETF process.
And despite the enormous elephant in the room, that seems to already
be a working choice.  I fully endorse the creation of this WG, with a 
charter that gives it sufficient freedom to refine its goals, by the 
consensus of the group, as ever better understanding of the problems 
is gained and shared.  A broad range of talents are already assembled 
and professing their commitment to its success, and I'd certainly like 
to see what they can in fact prove if given the umbrella group of their 
choice.  By choosing the IETF, they're offering me a voice to help 
shape that work, based on Real Things I Know.  And/or have the code to
demonstrate.  On about as reasonable and non-discriminating terms as
I could ever likely hope for.

Offers you can't refuse don't get much better than that.
Let's do this!

 Ron

---

From: Ron <[email-masked]>
Date: Wed, 20 Jan 2010 00:47:53 +1030

On Tue, Jan 19, 2010 at 01:27:26PM +0100, [email-masked] wrote:
> 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

Doesn't the IETF grant a voice to any contributor in the process of building
consensus?  I don't think anyone with a genuine interest in this project would
ignore genuinely useful input from any organisation, would they?

How would your concern be a problem if this process is conducted in the open
and all SDOs have equal access and input to the shaping of it?  The good and
bad ideas from these SDOs should be weighed and assayed like any other, no?

We can't demand they contribute, we can only welcome them by the measure of
how and what they do choose to, should they choose to.  Good Faith is an
addictive thing to reciprocate.  I'm not seeing any particular lack of it
from this group, are you?

  Ron

---

From: Sjoerd Simons <[email-masked]>
Date: Mon, 18 Jan 2010 22:36:41 +0000

> adoptions of such codecs in interactive Internet applications.

As part of my job for an open source consultancy specialising in real-time
communications i see both of the issues mentioned above occur from time to
time. As such i'm very exited to see a proposal for an IETF working group
which addresses these very issues. And therefor i fully endorse the creation of
this working group and will be eagerly awaiting it results.

Sjoerd Simons

---

From: <[email-masked]>
Date: Tue, 19 Jan 2010 13:27:26 +0100

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 : [email-masked] [mailto:[email-masked]] De la part de Xavier Marjou
Envoyé : lundi 11 janvier 2010 21:19
À : Cullen Jennings
Cc : IAB IAB; [email-masked]; 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:
>
> 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 
> 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

> Jul-2010: Requirements sent to other SDOs (including 3GPP, ITU-T, 
> MPEG) _______________________________________________
>

Cheers,

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 <[email-masked]> wrote:
> 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
> 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
>
> > 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.
> > To Subscribe: [email-masked] In Body: subscribe
> > According to reports from developers of Internet audio applications 
> > and operators of Internet audio services, there are no standardized, 
> > 3. Can be widely implemented and easily distributed among 
> > application developers, service operators, and end users.
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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 
> > but are not limited to, point-to-point voice calls, multi-party 
> > voice conferencing, telepresence, teleoperation, in-game voice chat, 
> > and live music performance)
> >
> > 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
> >
> > 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.
> >
> > 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.
> >
> > 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.
> >
> > 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
> >
> > 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
> >

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Wed, 20 Jan 2010 22:09:18 +0100

Hi all

We have in the past raised a number of issues with regards to IETF conducting codec work. One aspect that we value that is contained in the charter is the intent to producing IETF specific requirements that would be of benefit for the community and other SDOs dealing with codecs. 

As proposed by Xavier and his colleagues at Orange these requirements once defined should be giving the opportunity to the community and to other SDOs members to check for codecs potentially fullfilling the requirements. What would be the point of conducting codec development when a standardized codec out there fullfills the requirements ? So our interpretation of such proposed phased approach is that the WG would be explicitely taking a decision to pursue the work if there are no standardized codecs out there fullfilling the requirements. That is fine to us. This would also be accomodated by the following addition to the charter (based on Xavier's proposal):

"Once the first requirement establishment stage is completed, the working group will then communicate detailed description of the requirements and goals to other SDOs including the ITU-T, 3GPP, and MPEG. If an available standardized codec actually fullfills, or codec under current standardization will likely fulfil the requirements, then the working group may decide to terminate the codec development work." 

Regards
Ingemar

Ericsson AB
Multimedia Technologies
Labratoriegränd 11
971 28, Luleå, Sweden
Phone +46-1071 43042
SMS/MMS +46-73 078 3289

---

From: Mans Nilsson <[email-masked]>
Date: Thu, 21 Jan 2010 01:03:03 +0100

Subject: RE: WG Review: Internet Wideband Audio Codec (codec) Date: Wed, Jan 20, 2010 at 10:09:18PM +0100 Quoting Ingemar Johansson S ([email-masked]):

> So our interpretation of such proposed phased approach is that the WG
> would be explicitely taking a decision to pursue the work if there are
> no standardized codecs out there fullfilling the requirements. 

My interpretation of the situation is that this milestone is in most
peoples rear-view mirror. The available codecs that could be
rubberstamped are all missing some of the desirable qualities, ie
internetability, licensing, sound quality, latency.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
I feel partially hydrogenated!

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 21 Jan 2010 10:38:29 +0100

Hi

See inline below

/Ingemar

> From: Mans Nilsson [mailto:[email-masked]] 
> Sent: den 21 januari 2010 01:03
> To: Ingemar Johansson S
> Cc: [email-masked]; [email-masked]; [email-masked]
> Date: Wed, Jan 20, 2010 at 10:09:18PM +0100 Quoting Ingemar 
> Johansson S ([email-masked]):
> 
> 
> My interpretation of the situation is that this milestone is 
> in most peoples rear-view mirror. The available codecs that 
> could be rubberstamped are all missing some of the desirable 
> qualities, ie internetability, licensing, sound quality, latency.
I would say that it is up to other SDOs to determine that once the requirements are set. The big problem is that technical and legal matters are aired in the same sentence and I beleive that even a Codec WG in IETF will in the end realize that the legal matters are the most complicated. But enough said about this.

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 21 Jan 2010 11:06:33 +0100

Hi

Since I started on the IETF journey there have been a few occasions
where the intent of a WG has been discussed, my recollection is that in
all these cases people have looked into the charter for guidance. The
charter is IMHO a very strong document and once it is settled it is not
easily challenged. 

Also, common sense (based on earlier discussion and email) does not
always apply if the WG disussion gets heated and we all know that there
are different opinions around this WG :-). For this reason the charter
must state even what can be regarded as basic common sense (like he one
proposed in my earlier email).

Regards
/Ingemar 

> From: Monty Montgomery [mailto:[email-masked]] 
> Sent: den 21 januari 2010 06:41
> To: Ingemar Johansson S
> > As proposed by Xavier and his colleagues at Orange these 
> requirements once defined should be giving the opportunity to 
> the community and to other SDOs members to check for codecs 
> potentially fullfilling the requirements.
> 
> It is already the case that submissions are welcome from any 
> interested parties, and we hope very much that the SDOs do 
> have technology or even finished codecs to offer.  I don't 
> think that needs to be spelled out in language special to the SDOs.
> 
> > What would be the point of conducting codec development 
> when a standardized codec out there fullfills the requirements ?
> 
> This is another facet of 'our goals do not include rubber-stamping'.
> Should an unremembered codec be found lurking that fufills 
> all requirements, it would serve to raise the bar we set for 
> ourselves.
> The more and better the inputs, the better the potential 
> results. We seek to touch fire.
> 
> > "Once the first requirement establishment stage is 
> completed, the working group will then communicate detailed 
> description of the requirements and goals to other SDOs 
> including the ITU-T, 3GPP, and MPEG. If an available 
> standardized codec actually fullfills, or codec under current 
> standardization will likely fulfil the requirements, then the 
> working group may decide to terminate the codec development work."
> 
> In the event an outside codec is discovered that meets all 
> requirements and cannot be improved upon, the only sensible 
> course of action would be accept it.  I see no reason to 
> exhaustively codify basic common sense for every unlikely 
> scenario.  [It is not that I consider contributions from the 
> SDOs to be unlikely, I consider it unlikely there would be no 
> potential for any improvement given the assembed talent and 
> that such a codec already exists and nobody knows about it.  
> If I'm wrong-- everybody still wins, and I'm happy with 
> losing the bet.]
> 
> Monty
> Xiph.Org
>

---

From: Mans Nilsson <[email-masked]>
Date: Thu, 21 Jan 2010 13:13:52 +0100

> I would say that it is up to other SDOs to determine that once the
> requirements are set. 

Why? 

> The big problem is that technical and legal
> matters are aired in the same sentence and I beleive that even a Codec
> WG in IETF will in the end realize that the legal matters are the most
> complicated. But enough said about this.
 
I do not disagree about legal issues being large blips on the problem
radar. The failure to grasp the business potential in free  (fsvo free
that meets BSD or GPL standards, just to grab some examples) codec
technology among those who have traditionally produced codecs is one of
the cornerstones in why CODEC is needed and why I think IETF should
keep a loose liasion to other SDOen rather than lockstepping.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
I HAVE to buy a new "DODGE MISER" and two dozen JORDACHE JEANS because
my viewscreen is "USER-FRIENDLY"!!

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 21 Jan 2010 13:58:42 +0100

> Sent: den 21 januari 2010 13:14
> To: Ingemar Johansson S
> Date: Thu, Jan 21, 2010 at 10:38:29AM +0100 Quoting Ingemar 
What I try to say is that first the requirements must be set, only then will it be possible for representatives of other SDOs to determine if already standarddized codecs (or codecs under standardization) meet them.

> 
> > The big problem is that technical and legal matters are 
> aired in the 
> > same sentence and I beleive that even a Codec WG in IETF 
> will in the 
> > end realize that the legal matters are the most complicated. But 
> > enough said about this.
>  
> I do not disagree about legal issues being large blips on the 
> problem radar. The failure to grasp the business potential in 
> free  (fsvo free that meets BSD or GPL standards, just to 
> grab some examples) codec technology among those who have 
> traditionally produced codecs is one of the cornerstones in 
> why CODEC is needed and why I think IETF should keep a loose 
> liasion to other SDOen rather than lockstepping.
> 
> -- 
> I HAVE to buy a new "DODGE MISER" and two dozen JORDACHE 
> JEANS because my viewscreen is "USER-FRIENDLY"!!
>

---

From: Adrian Farrel <[email-masked]>
Date: Thu, 21 Jan 2010 13:39:38 +0000

[snip]

>> What I try to say is that first the requirements must be set, only then
>> will it be possible for representatives of other SDOs to determine if
>> already standarddized codecs (or codecs under standardization) meet them.
>
> I agree.  Obviously no one (inside or outside the IETF) can tell exactly
> how existing codecs in other SDOs relate to this work until the detailed
> requirements are locked down.
>
> Also, I think the burden is mostly on CODEC to make this assessment. 
> Other
> SDOs may offer their views in liason statements, and can respond with 
> their
> own work programs.  But in the end it would be up the IETF to decide if
> there is too much overlap.

Right, and this is surely easy to achieve and good project management, 
anyway.

Document the requirements to a reasonable level of detail.
Circulate the requirements explicitly requesting suggestions.
Evaluate the suggestions and give reasons for rejecting existing Codecs.
Go on and develop a new Codec if required.

It does not follow that people cannot start work on a new Codec before 
completion of the third step, but the WG would be premature to adopt a Codec 
solution draft before having formally surveyed the landscape.

The first step has to be done anyway, and I don't see that it can be 
considered as slowing down the development of a solution since it is 
impossible to build a solution without knowing the requirements. The second 
step might add a few weeks to the cycle. The third step, if we are to 
believe the comments in this thread, will not take long.

So why does anyone object to such a process?

As to whether this sequence of steps should be codified in the charter, my 
experience is that if you don't write down a process, it is very hard to get 
interoperable implementations.

Thanks,
Adrian

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 21 Jan 2010 08:58:18 -0500

It's not clear to me why SDOs need to be involved in the process of  
determining whether existing codecs satisfy the requirements.   
Information on standard codecs -- including their technical and legal  
aspects -- is pretty widely available.  And if information about a  
codec isn't generally available (e.g., if standards are being closely  
held), then that codec fails to meet the requirements by definition --  
there's a requirement that it by widely implementable, which requires  
its specification to be widely available.

I've only been following this discussion off and on, but I don't  
really see anyone really challenging the requirements in the current  
draft charter, and I don't really see anyone proposing codecs that  
meet those requirements. Unless one of those two changes, it seems  
evident that the requirements are not being satisfied, so we should  
just move on with forming the WG.

--Richard

On Jan 21, 2010, at 8:39 AM, Adrian Farrel wrote:

>> Also, I think the burden is mostly on CODEC to make this  
>> assessment. Other
>> SDOs may offer their views in liason statements, and can respond  
>> with their
> Right, and this is surely easy to achieve and good project  
> management, anyway.
>
> It does not follow that people cannot start work on a new Codec  
> before completion of the third step, but the WG would be premature  
> to adopt a Codec solution draft before having formally surveyed the  
> landscape.
>
> impossible to build a solution without knowing the requirements. The  
> second step might add a few weeks to the cycle. The third step, if  
> we are to believe the comments in this thread, will not take long.
>
> As to whether this sequence of steps should be codified in the  
> charter, my experience is that if you don't write down a process, it  
> is very hard to get interoperable implementations.
>
> Thanks,
> Adrian
>
>

---

From: Adrian Farrel <[email-masked]>
Date: Thu, 21 Jan 2010 14:28:21 +0000

Richard,

I think I agree...

> determining whether existing codecs satisfy the requirements.

However, no-one can make the determination without requirements to make an 
evaluation against.

And to be sure that all the candidates are in the melting pot, it is at 
worst harmless to poll the other SDOs for their input and suggestions.

I would expect that one of the tasks of this WG is to coordinate and 
document (i.e. make) the evaluation.

Cheers,
Adrian

> aspects -- is pretty widely available.  And if information about a  codec 
> isn't generally available (e.g., if standards are being closely  held), 
> then that codec fails to meet the requirements by definition --  there's a 
> requirement that it by widely implementable, which requires  its 
> specification to be widely available.
>
> I've only been following this discussion off and on, but I don't  really 
> see anyone really challenging the requirements in the current  draft 
> charter, and I don't really see anyone proposing codecs that  meet those 
> requirements. Unless one of those two changes, it seems  evident that the 
> requirements are not being satisfied, so we should  just move on with 
> forming the WG.
>
> --Richard
>
>
>
>> completion of the third step, but the WG would be premature  to adopt a 
>> Codec solution draft before having formally surveyed the  landscape.
>>
>> second step might add a few weeks to the cycle. The third step, if  we 
>> are to believe the comments in this thread, will not take long.
>>
>> As to whether this sequence of steps should be codified in the  charter, 
>> my experience is that if you don't write down a process, it  is very hard 
>> to get interoperable implementations.
>>
>> Thanks,
>> Adrian
>>
>>

---

From: <[email-masked]>
Date: Wed, 20 Jan 2010 22:55:46 +0100

Dear all,

>So I disagree with your conclusion and related arguments : let's establish and agree on real technical >requirements first and then analyse existing standards and possible efficient adaptations before starting >developping et new codec ! 

I also think that we need to know the detailed requirements in order to launch the work. Therefore potential users and experts outside IETF (eg. ITU and 3GPP) should be involved to contribute to the full picture of the codec. There is a large user base eg. in the mobile domain that would benefit from this and who's requirements need to be taken into account. IETF being quite new in the codec field, it would gain from the expertise of more mature codec standardizing bodies. Standardization is more than just rubberstamping.

Best regards,
Jari Hagqvist

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of ext [email-masked] [[email-masked]]
Sent: Friday, January 15, 2010 4:46 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [codec] WG Review: Internet Wideband Audio Codec (codec)

Hello

Best regards

Stephane

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Christian Hoene
Envoyé : mardi 12 janvier 2010 01:28
À : MARJOU Xavier RD-CORE-LAN
Cc : 'IAB IAB'; [email-masked]; 'IETF Discussion'; 'IESG IESG'
Objet : Re: [codec] WG Review: Internet Wideband Audio Codec (codec)

Dear Xavior Marjou,

With best regards,

 Christian

---

From: Jean-Marc Valin <[email-masked]>
Date: Thu, 21 Jan 2010 10:20:17 -0500

Hi,

Actually, maybe we can look at how other SDOs are handling this issue.
Considering that ITU-T, 3GPP/3GPP2 and (to a lesser extent) MPEG all
standardise codecs in the same space, how do these SDOs coordinate? For
example, does the ITU-T SG16 have some text in it's "charter" that says "we
will communicate the requirements to 3GPP and other SDOs to see if they
have codecs that fill these requirements"? Can someone more familiar than I
am with the ITU-T/3GPPx/MPEG/... explain how this issue is being handled?

	Jean-Marc

---

From: Ron <[email-masked]>
Date: Fri, 22 Jan 2010 01:09:40 +1030

On Thu, Jan 21, 2010 at 02:44:36PM +0100, [email-masked] wrote:
> In line as well : The first stage of the work has not been done yet : the
> detailed technical requirements have not been defined and agreed yet, the
> second stage of the work with other SDOs to analyse if already exiting codecs
> meet these requirements is not done and yet the Charter on the basis of which
> this WG could be launched is formulated as if the conclusion resulting from
> this 2 stages was known and obvious : no existing codec is suitable and so a
> new codec is needed
>  
> so, again : only these first 2 steps (requirement definition and standard
> analysis) are, at this stage, relevant to start a WG since the next steps
> depend on the conclusion of this work.
>  
> for instance , there could be some middle way between developping a new codec
> and reusing an existing standard : it could be much more efficient to simply
> extend/adapt an existing standard and, to achieve this, it would be better to
> rely on the SDO that have standardized this codec. 

Potential candidate codecs have been discussed since the very first BoF,
and surely before.  We have plenty of representatives from other SDOs
present in the group, so my question is, if such codecs exist, then surely
they should be put up, if not as contenders, then as baseline measures of
best practice in some matter or another.  Why hasn't that happened?

With the exception of a few "G.711 should be enough for anyone" jokes,
I haven't seen anyone present a "this can already do what you want" codec
that the group hasn't responded with "we can (already) do better than that".

If there are other codecs that we should have to measure up against, then
indeed I'd warmly welcome other SDOs to make their best suggestions soon,
for consideration during the next stage of work.  Anything you think puts
one of the existing candidates to shame in some aspect or another, would
certainly be a valuable and practical measuring stick we can use.

I'm pretty sure a lot of people have already done many of these measurements
for themselves.  We just need to whittle that down to the ones that give us
useful bars to raise.  Which ones are we missing still?

Cheers,
Ron

---

From: <[email-masked]>
Date: Thu, 21 Jan 2010 14:44:36 +0100

In line as well :
The first stage of the work has not been done yet : the detailed technical requirements have not been defined and agreed yet,
the second stage of the work with other SDOs to analyse if already exiting codecs meet these requirements is not done
and yet the Charter on the basis of which this WG could be launched is formulated as if the conclusion resulting from this 2 stages was known and obvious : no existing codec is suitable and so a new codec is needed
 
so, again : only these first 2 steps (requirement definition and standard analysis) are, at this stage, relevant to start a WG since the next steps depend on the conclusion of this work.
 
for instance , there could be some middle way between developping a new codec and reusing an existing standard : it could be much more efficient to simply extend/adapt an existing standard and, to achieve this, it would be better to rely on the SDO that have standardized this codec. 
 
Stéphane Proust

________________________________

De : [email-masked] [mailto:[email-masked]] De la part de stephen botzko
Envoyé : jeudi 21 janvier 2010 14:10
À : Ingemar Johansson S
Cc : Mans Nilsson; [email-masked]; [email-masked]; [email-masked]
Objet : Re: [codec] WG Review: Internet Wideband Audio Codec (codec)

in-line

Stephen Botzko
Polycom

	

I agree.  Obviously no one (inside or outside the IETF) can tell exactly how existing codecs in other SDOs relate to this work until the detailed requirements are locked down.

Also, I think the burden is mostly on CODEC to make this assessment.  Other SDOs may offer their views in liason statements, and can respond with their own work programs.  But in the end it would be up the IETF to decide if there is too much overlap.

---

From: stephen botzko <[email-masked]>
Date: Thu, 21 Jan 2010 07:29:47 -0500

Once again we are getting tied up in the IPR debate...

One reason to check existing codecs against the CODEC requirements is that
too many overlapping codecs in the marketplace works against
interoperability.

A second reason is that developing a new codec is a lot of work, so it makes
sense to make sure of its value first.

I'd also observe that if (for arguments sake) we did find such a codec in
another SDO, the IETF would not rubber-stamp it.  So I am not seeing the
connection to the rubber-stamping question.

Stephen Botzko
Polycom

On Thu, Jan 21, 2010 at 7:13 AM, Mans Nilsson <[email-masked]>wrote:

> Subject: RE: WG Review: Internet Wideband Audio Codec (codec) Date: Thu,
> Jan 21, 2010 at 10:38:29AM +0100 Quoting Ingemar Johansson S (
> [email-masked]):
>

---

From: stephen botzko <[email-masked]>
Date: Thu, 21 Jan 2010 08:09:49 -0500

in-line

Stephen Botzko
Polycom

Also, I think the burden is mostly on CODEC to make this assessment.  Other
SDOs may offer their views in liason statements, and can respond with their
own work programs.  But in the end it would be up the IETF to decide if
there is too much overlap.

---

From: stephen botzko <[email-masked]>
Date: Thu, 21 Jan 2010 09:38:56 -0500

I would add that it is possible that another SDO has work-in-progress that
might overlap, so it is important to ask them.  This is slightly different
from getting information on something already finished.

I agree that this particular issue is not a reason to block the formation of
the WG itself, but that the WG should be required to make the evaluation.

Stephen Botzko
Polycom

On Thu, Jan 21, 2010 at 9:28 AM, Adrian Farrel <[email-masked]>wrote:

>> isn't generally available (e.g., if standards are being closely  held), then
>> that codec fails to meet the requirements by definition --  there's a
>>> my experience is that if you don't write down a process, it  is very hard to
>>> get interoperable implementations.
>>>
>>> Thanks,
>>> Adrian
>>>
>>>

---

From: stephen botzko <[email-masked]>
Date: Thu, 21 Jan 2010 10:02:52 -0500

Hi Ron

I agree there's been discussion about existing codecs, and most of it has
been helpful and constructive.

But until the detailed requirements have been determined, I don't think it
is very fruitful to continue it.

IMHO we'll need those details to be more precisely stated (and agreed to) in
order to take this to the next level.  It'd be most efficient to do the
formal assessment only once.

Stephen Botzko
Polycom

On Thu, Jan 21, 2010 at 9:39 AM, Ron <[email-masked]> wrote:

> On Thu, Jan 21, 2010 at 02:44:36PM +0100,

---

From: stephen botzko <[email-masked]>
Date: Thu, 21 Jan 2010 11:13:42 -0500

Here's what I've seen (maybe some other ITU-T attendees can comment).

The charter of SG16 (and its "questions" - like WGs in the IETF) is handled
somewhat differently than the IETF charter process.  The entire ITU-T
charter and organization is re-approved every study period (3 years), and
the organization and leadership is kept for the entire period.  Each
question has its own focus, specified in the charter.  This does not include
specific work items.  When new work is proposed, first the question agrees
to add them to its work program. Then the work program is approved by the
working party (one layer up), and finally the full study group (in a plenary
session). This happens fairly rapidly (within the same meeting session).

The ITU-T questions that do audio codecs first identify the application need
(reasonably detailed requirements) for the proposed codec, and makes sure it
does not duplicate ITU-T previous work (and other work the members know
about).  If there is agreement to proceed, the codec is added to the ITU-T
work program.  The approved work program is published, and usually sent to
other interested SDOs in liason statements.

Later on, the group works out even more specific requirements (called "terms
of reference") and develops a test plan for candidates. Often there are two
batteries of tests - a "lower bar" for qualifying reasonable candidates, and
a "higher bar" for choosing between the candidates that pass the first test.

Then it calls for proposals, accepts candidates, and starts the selection
process and characterization/testing.

Stephen Botzko
Polycom

On Thu, Jan 21, 2010 at 10:20 AM, Jean-Marc Valin <
[email-masked]> wrote:

>  codec

---

From: Monty Montgomery <[email-masked]>
Date: Thu, 21 Jan 2010 00:41:24 -0500

> As proposed by Xavier and his colleagues at Orange these requirements once defined should be giving the opportunity to the community and to other SDOs members to check for codecs potentially fullfilling the requirements.

It is already the case that submissions are welcome from any
interested parties, and we hope very much that the SDOs do have
technology or even finished codecs to offer.  I don't think that needs
to be spelled out in language special to the SDOs.

> What would be the point of conducting codec development when a standardized codec out there fullfills the requirements ?

This is another facet of 'our goals do not include rubber-stamping'.
Should an unremembered codec be found lurking that fufills all
requirements, it would serve to raise the bar we set for ourselves.
The more and better the inputs, the better the potential results. We
seek to touch fire.

In the event an outside codec is discovered that meets all
requirements and cannot be improved upon, the only sensible course of
action would be accept it.  I see no reason to exhaustively codify
basic common sense for every unlikely scenario.  [It is not that I
consider contributions from the SDOs to be unlikely, I consider it
unlikely there would be no potential for any improvement given the
assembed talent and that such a codec already exists and nobody knows
about it.  If I'm wrong-- everybody still wins, and I'm happy with
losing the bet.]

Monty
Xiph.Org