Subject: Re: [codec] Updated Agenda for Codec BOF

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 9 Jul 2009 15:43:49 +0200

WARNING: contains banned part

Subject: Re: [codec] Updated Agenda for Codec BOF
From: "Ingemar Johansson S" <[email-masked]>
To: <[email-masked]>
Date: Thu, 9 Jul 2009 15:43:49 +0200

Hi
 
I looked through the agenda and have some concerns with it:
 
I would like to see bullet 3 renamed to something like "should IETF do this?" with sub-bullets that adresses the issues that have been brought up on this list (IPR/royalty, area of expertice, maintenance, testing, IETFs role...). I believe that this bullet will take the longest time to go through and I expect something like 40 minutes or more for this.
 
As regards to the chairs, I would personally prefer that this was a more balanced pick, why not have one "proponent" and one "opponent" as chairs ?, possibly add a neutral "greybeard" who has the ability to see this from the side ?. This is important as both proponents and opponents want to make sure that the whole discussion is fair and that the discussion does not exclude important subjects. 
Please note that it is not to be interpreted as a negative opinion against Jason or Jean-Marc.
 
Regards
Ingemar

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 9 Jul 2009 07:22:57 -0700

All these efforts to kill the free Internet voice codec before it is even born!

There must be a very big stake to do this...

Henry

On 7/9/09 8:43 AM, "Ingemar Johansson S" <[email-masked]> wrote:

---

From: "Ingemar Johansson S" <[email-masked]>
Date: Thu, 9 Jul 2009 19:16:22 +0200

Hi
 
This is yet another reason why I think it is best to select chairs for this who reflect the different opinions around this subject. If this is not done I fear that this BoF will just end up in a verbal fist-fight and nobody benefits from it, it will only make us all look like morons.
 
Also I am not trying to kill any codec, I just don't see how it fits in the IETF, thats why I wish to have all issues discussed. Selection of codecs is secondary and can be discussed once/if a formation of the WG is decided. 
 
Personally I don't know what this "banned" stuff inserted by the server is about...
 
Regards
Ingemar

________________________________

Från: Henry Sinnreich [mailto:[email-masked]]
Skickat: to 2009-07-09 16:22
Till: Ingemar Johansson S; [email-masked]
Ämne: Re: [codec] Updated Agenda for Codec BOF

Henry

On 7/9/09 8:43 AM, "Ingemar Johansson S" <[email-masked] <https://rvi.se.ericsson.net/dana-cached/help/empty.html> > wrote:

---

From: stephen botzko <[email-masked]>
Date: Thu, 9 Jul 2009 14:45:12 -0400

Given the goal of the BOF, the aim is for a moderated discussion of the
merits (pro and con).  So I agree that it would be prudent to have chairs
who reflect the various views.  It will make it easier to keep the meeting
orderly and moving, since no one will feel that the chairs shut them down
because they didn't agree with their views.  "Success" here is not measured
by whether a WG is created (or not).  "Success" is providing quality input
to the IESG on the merits from a broad range of participants.

Please understand that I am *not* saying that I think Jean-Marc and Jason *
would* be deliberately unfair. I *am* saying that we should anticipate a
lively discussion without clear consensus. So moderating it is likely to be
challenging.  Also, it will not be easy for Jean-Marc and Jason to present
their personal views while they are also acting as chairs.  For these
reasons, I think that if the chairs all hold one view, the BOF is unlikely
to be successful (using my definition above).

As far as codecs go, I think there is some value in having a couple of
sample submissions to look at.  However, time will be valuable in the BOF.
I think we should assume that the IESG will be able to assess the sample
contributions without our needing to spend a lot of time discussing them.

Also, before anything can move forward there needs to be (a) a chartered
working group and (b) an established set of working procedures. The proposed
charter's output is a single codec, not multiple codecs.  There would need
to be a common understanding of whether the working group is *selecting* a
single codec from the candidates, or somehow *developing* a common codec
from more than one candidate.  There would also need to be some consensus on
the basis for codec selection (and/or technology development), and some
consensus on how to measure the codec performance against the various
requirements, and of course at some point there will be more precision
needed on the IPR rules.

It will be very difficult to invent the process while we are simultaneously
talking about codec technology.  I'd think the WG (if it goes forward) would
need to spend some time hammering out a working process before it will be
ready to accept candidates for consideration. Perhaps some more focused
discussion on these points ahead of time would be helpful to the IESG, and
to the WG (when and if)..

IMHO we ought to refrain from accusing people of "killing",  There is
nothing to kill at this point.  Polarizing the debate by labeling the
participants is not a constructive way to proceed.  The genuine areas of
disagreement are hard enough.

Stephen Botzko
Polycom

On Thu, Jul 9, 2009 at 1:16 PM, Ingemar Johansson S <
[email-masked]> wrote:

> Hi
>
> This is yet another reason why I think it is best to select chairs for this
> who reflect the different opinions around this subject. If this is not done
> I fear that this BoF will just end up in a verbal fist-fight and nobody
> benefits from it, it will only make us all look like morons.
>
> Also I am not trying to kill any codec, I just don't see how it fits in the
> IETF, thats why I wish to have all issues discussed. Selection of codecs is
> secondary and can be discussed once/if a formation of the WG is decided.
>
> On 7/9/09 8:43 AM, "Ingemar Johansson S" <[email-masked]<
> https://rvi.se.ericsson.net/dana-cached/help/empty.html> > wrote:
>
>
>
> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec
>

---

From: "Slava Borilin" <[email-masked]>
Date: Thu, 9 Jul 2009 23:13:36 +0400

I agree with Stephen that it would be better to EXCLUDE #4 from agenda - as this may be time consuming.

Instead I would like to get back the item "requirements for codec, as they may look like from IETF perspective" (royalty-free, license-free from legal, + technical (packet loss, MOS, performance)).

I do NOT think we (most of us) do not believe it's feasible - so not much point of discussing if its feasible to select good IP codec. Questions are criteria, and path to go (=process).

Slava Borilin

From: [email-masked] [mailto:[email-masked]] On Behalf Of stephen botzko
Sent: Thursday, July 09, 2009 10:45 PM
To: Ingemar Johansson S
Cc: [email-masked]
Subject: Re: [codec] Updated Agenda for Codec BOF

Given the goal of the BOF, the aim is for a moderated discussion of the merits (pro and con).  So I agree that it would be prudent to have chairs who reflect the various views.  It will make it easier to keep the meeting orderly and moving, since no one will feel that the chairs shut them down because they didn't agree with their views.  "Success" here is not measured by whether a WG is created (or not).  "Success" is providing quality input to the IESG on the merits from a broad range of participants.

Please understand that I am not saying that I think Jean-Marc and Jason would be deliberately unfair. I am saying that we should anticipate a lively discussion without clear consensus. So moderating it is likely to be challenging.  Also, it will not be easy for Jean-Marc and Jason to present their personal views while they are also acting as chairs.  For these reasons, I think that if the chairs all hold one view, the BOF is unlikely to be successful (using my definition above).

As far as codecs go, I think there is some value in having a couple of sample submissions to look at.  However, time will be valuable in the BOF.  I think we should assume that the IESG will be able to assess the sample contributions without our needing to spend a lot of time discussing them.

Also, before anything can move forward there needs to be (a) a chartered working group and (b) an established set of working procedures. The proposed charter's output is a single codec, not multiple codecs.  There would need to be a common understanding of whether the working group is selecting a single codec from the candidates, or somehow developing a common codec from more than one candidate.  There would also need to be some consensus on the basis for codec selection (and/or technology development), and some consensus on how to measure the codec performance against the various requirements, and of course at some point there will be more precision needed on the IPR rules.  

It will be very difficult to invent the process while we are simultaneously talking about codec technology.  I'd think the WG (if it goes forward) would need to spend some time hammering out a working process before it will be ready to accept candidates for consideration. Perhaps some more focused discussion on these points ahead of time would be helpful to the IESG, and to the WG (when and if)..

IMHO we ought to refrain from accusing people of "killing",  There is nothing to kill at this point.  Polarizing the debate by labeling the participants is not a constructive way to proceed.  The genuine areas of disagreement are hard enough.

Stephen Botzko
Polycom

On Thu, Jul 9, 2009 at 1:16 PM, Ingemar Johansson S <[email-masked]> wrote:

Hi

Regards
Ingemar

Henry

---

From: Jean-Marc Valin <[email-masked]>
Date: Thu, 09 Jul 2009 15:47:57 -0400

Slava Borilin wrote:
> I agree with Stephen that it would be better to EXCLUDE #4 from agenda – 
> as this may be time consuming.

Just to clarify. This part of the agenda is intended to address the points 
that were raised about the feasibility of the work. It will also show what 
requirements are achievable in a short time frame. The presentations will 
be short and high level, not technical descriptions of the codecs internals.

> Instead I would like to get back the item “requirements for codec, as 
> they may look like from IETF perspective” (royalty-free, license-free 
> from legal, + technical (packet loss, MOS, performance)).

This should probably belong to the charter discussion, along with 
discussion of the process if (I hope) time permits.

Cheers,

	Jean-Marc

---

From: "Slava Borilin" <[email-masked]>
Date: Thu, 9 Jul 2009 23:53:48 +0400

Jean-Marc (and mainly all others),

Do we really have to prove that it is feasible to create IP codec (while
some of them ALREADY EXISTS, like speex, CELT, IPMR, SILK)?
Or people need to be convinced how much time/efforts it might take to
create IP codec?

I mean that if potential difficulties of creating the codec scares most
of people, we should show that its not that scary. Otherwise- it will be
a waste of time ("high-level only codec overview" parts seems to be the
longest section (25m) in the agenda)

Slava.

-----Original Message-----
From: Jean-Marc Valin [mailto:[email-masked]] 
Sent: Thursday, July 09, 2009 11:48 PM
To: Slava Borilin
Cc: stephen botzko; Ingemar Johansson S; [email-masked]
Subject: Re: [codec] Updated Agenda for Codec BOF

Slava Borilin wrote:
> I agree with Stephen that it would be better to EXCLUDE #4 from agenda
- 
> as this may be time consuming.

Just to clarify. This part of the agenda is intended to address the
points 
that were raised about the feasibility of the work. It will also show
what 
requirements are achievable in a short time frame. The presentations
will 
be short and high level, not technical descriptions of the codecs
internals.

> Instead I would like to get back the item "requirements for codec, as 
> they may look like from IETF perspective" (royalty-free, license-free 

Cheers,

	Jean-Marc

---

From: "Roni Even" <[email-masked]>
Date: Thu, 9 Jul 2009 23:40:44 +0300

Jean-Marc,
I do not think that by describing a codec you address the feasibility of the
work. The feasibility of the work is to see what is the purpose of this
group, what is the procedure for getting the work. The charter discussion
should not be if time permit, this should be the objective of the BOF

Please listen to the requests and take out item 4. This discussion is making
people respond with concerns about the BOF chairs being biased.

Roni Even

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Jean-Marc Valin
> Sent: Thursday, July 09, 2009 10:48 PM
> To: Slava Borilin
> Cc: Ingemar Johansson S; [email-masked]; stephen botzko
> > I agree with Stephen that it would be better to EXCLUDE #4 from
> agenda -

---

From: "Slava Borilin" <[email-masked]>
Date: Fri, 10 Jul 2009 00:48:07 +0400

Its nothing about "being biased", really - but the time pressure to talk
about 
(at least from my perspective, I do not want to waste time to ensure
that its feasible to create IP-codec, no need to make BoF to prove it,
as I know for sure it is feasible already).

So unless others want to get the evidence on this, I vote for removing
the codec presentations for the sake of other discussions.

Slava.

-----Original Message-----
From: Roni Even [mailto:[email-masked]] 
Sent: Friday, July 10, 2009 12:41 AM
To: 'Jean-Marc Valin'; Slava Borilin
Cc: 'Ingemar Johansson S'; [email-masked]; 'stephen botzko'
Subject: RE: [codec] Updated Agenda for Codec BOF

Jean-Marc,
I do not think that by describing a codec you address the feasibility of
the
work. The feasibility of the work is to see what is the purpose of this
group, what is the procedure for getting the work. The charter
discussion
should not be if time permit, this should be the objective of the BOF

Please listen to the requests and take out item 4. This discussion is
making
people respond with concerns about the BOF chairs being biased.

Roni Even

---

From: Gregory Maxwell <[email-masked]>
Date: Thu, 9 Jul 2009 14:16:12 -0700

> Or people need to be convinced how much time/efforts it might take to

Several people have argued that the IETF lacks the expertise required for codec development. 

In fact the standing charter of the AVT working group states specifically "the IETF does not have the ability to effectively review new codecs".

It's been alleged that codec development is extremely difficult and entirely distinct from other kinds of protocol development. I don't believe this is a position many people who know much about codec internals would really agree with, but its easy to accept if you're used to treating codecs as black boxes.

It may be that this issue is now soundly dead, since other arguments have been advance more frequently as of late, but I don't see anything that has changed in terms of expertise since that position has been advanced, so am not certain that there is agreement on this point.

Even if those opposed to the creation of this working group are willing to concede that the available expertise is a non-issue we have participants working on codec development. It would be unreasonable to ask them to stop or to stop cooperating simply because the IETF hasn't decided if it wants to be involved in the effort yet and I think it's useful to people trying to decide if they want to be involved to see what actually is involved.

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 09 Jul 2009 15:46:47 -0600

On 7/9/09 2:48 PM, Slava Borilin wrote:
> Its nothing about "being biased", really - 

Agreed. That kind of talk is unproductive.

> but the time pressure to talk

This is easily solved by having a well-run meeting. The chairs can
*strictly* limit the time devoted to discussion about particular codecs.

> as I know for sure it is feasible already).

It's good that you know it is feasible, but others might not. :)

> the codec presentations for the sake of other discussions.

If we place our trust in rough consensus and running code, then evidence
is good, no?

Some people seem to think that it is beyond the capabilities of the IETF
to produce codecs. But it seems that we already have at least two
existence proofs to the contrary, in the form of I-Ds submitted by
active IETF contributors. Therefore I think it would be very helpful to
discuss those existence proofs, albeit without getting into a long
discussion about the merits of particular codecs (at least during the BoF!).

Furthermore, discussion about particular codecs will help us ground the
conversation in a way that abstract requirements will not.

The longer-term challenge will be to avoid the fate of, say, the IMPP
WG, which produced requirements documents but no protocols. If we can
use the submitted I-Ds as input to the work of a Codec WG then we will
already be quite far down the road to producing truly open codecs for
the Internet.

On a more personal note, I think that this work is extremely important.
In the Jabber/XMPP community we have experienced first-hand the problems
that arise when there is no one open codec that everyone can implement
and deploy. Currently we recommend Speex for Jingle audio applications
<http://xmpp.org/extensions/xep-0266.html> but it would be great to have
more modern, Internet-friendly codecs going forward.

Some say that only the ITU or some other SDO can get the job done. I say
let's prove them wrong.

Peter

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

---

From: "Christian Hoene" <[email-masked]>
Date: Fri, 10 Jul 2009 00:31:35 +0200

Hello Stephen and all,

thank you your very good statements on how to make this WG a success. 

This mailing list has shown enough interest from various sides. The WG will
not die because of lack of interest. Also, beside internet guys also a
sufficient number of “open source” and “traditional” coding experts are
participating in the discussions. I do not see a danger that this WG will
not be started.

But I have to agree that I am missing somebody who plays the role of the
moderator of the discussion. I just remember the talk with the chair of a
ITU Study Group 12 working group. He told me that he has an own proposal but
he cannot bring it into play because of his role as moderator. Hopefully,
some moderator can be found for this WG - with an own codec in his lab or
without it...

I do not believe that a new codec standardization process should be
invented. Having different requirements and excellent new codec designs
should be enough innovations. 

If so, what is the traditional process on codec standardization? Isn’t it
something like this:
1.) Establishment of a set of working procedures 
2.) Definition of requirements, objects (both including priorities), quality
parameters and procedures on how to measure these parameters.
3.) Developing codecs...
4.) Characterization and testing of the codec proposals. 
5.) Selecting one, merging them or jump back to 2.)
6.) Standardization of the codec and definition of conformance tests.

Both the ITU and 3GPP must have well defined procedures, which we should
look at. Of course, they should be adopted only partly and carefully to not
hinder the goals of this WG.

Regards,
 Christian

From: [email-masked] [mailto:[email-masked]] On Behalf Of
stephen botzko
Sent: Thursday, July 09, 2009 8:45 PM
To: Ingemar Johansson S
Cc: [email-masked]
Subject: Re: [codec] Updated Agenda for Codec BOF

Please understand that I am not saying that I think Jean-Marc and Jason
would be deliberately unfair. I am saying that we should anticipate a lively
discussion without clear consensus. So moderating it is likely to be
challenging.  Also, it will not be easy for Jean-Marc and Jason to present
their personal views while they are also acting as chairs.  For these
reasons, I think that if the chairs all hold one view, the BOF is unlikely
to be successful (using my definition above).

Also, before anything can move forward there needs to be (a) a chartered
working group and (b) an established set of working procedures. The proposed
charter's output is a single codec, not multiple codecs.  There would need
to be a common understanding of whether the working group is selecting a
single codec from the candidates, or somehow developing a common codec from
more than one candidate.  There would also need to be some consensus on the
basis for codec selection (and/or technology development), and some
consensus on how to measure the codec performance against the various
requirements, and of course at some point there will be more precision
needed on the IPR rules.  

Stephen Botzko
Polycom
On Thu, Jul 9, 2009 at 1:16 PM, Ingemar Johansson S
<[email-masked]> wrote:
Hi

Personally I don't know what this "banned" stuff inserted by the server is
about...

Regards
Ingemar

All these efforts to kill the free Internet voice codec before it is even
born!

Henry

On 7/9/09 8:43 AM, "Ingemar Johansson S" <[email-masked]
<https://rvi.se.ericsson.net/dana-cached/help/empty.html> > wrote:

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 09 Jul 2009 16:11:08 -0700

Hi,

On 7/9/09 12:13 PM, "Slava Borilin" <[email-masked]> wrote:

> I agree with Stephen that it would be better to EXCLUDE #4 from agenda  as
> this may be time consuming.
> Instead I would like to get back the item ³requirements for codec, as they may
> look like from IETF perspective² (royalty-free, license-free from legal, +
> technical (packet loss, MOS, performance)).
> 
I object in the strongest possible terms to the implied statement that a
codec being ³royalty-free and/or license-free from legal² is a requirement
from the IETF¹s perspective.  A statement like this, if it were correct
(which it isn¹t) may have legal implications that few, if any, of us here
fully understand.  Trust me on this (and/or ask your lawyer).  I¹m serious.

Nowhere in the IETF¹s legal framework there is a requirement for
royalty-free designs, let alone unencumbered designs or designs relying
exclusively on non-assert covenants.  Nowhere in the IETF, except for the
community consensus in certain, small, well-defined areas (such as baseline
security), there is community consensus of such a requirement.  Certainly,
there is no community consensus on this list with respect to the codec
issue.

If you would have been writing something like ³Requirement as viewed by the
proponents of this BOF², I would agree.
If you would write ³Desirable for the continued growth of Internet based
multimedia communication², I would agree.
If you would write ³Desirable from an IETF viewpoint², I would agree.  This
is supported by policy language.
If you would write, ³Required for the future of the Internet² I would
disagree, but not object as noisily as in the statement you made.  It¹s
abstract enough to be safe, as far as I can see.  But please leave the IETF,
as an organization, out of this picture.

In this discussion, we are touching the interface between engineering and
legal.  Let¹s be careful; it¹s easy to mess up things.

Regards,
Stephan

> 
>  
> I do NOT think we (most of us) do not believe it¹s feasible  so not much
> point of discussing if its feasible to select good IP codec. Questions are
> criteria, and path to go (=process).
>  
> Slava Borilin
>  
> 
> 
> Given the goal of the BOF, the aim is for a moderated discussion of the merits
> (pro and con). So I agree that it would be prudent to have chairs who reflect
> the various views.  It will make it easier to keep the meeting orderly and
> moving, since no one will feel that the chairs shut them down because they
> didn't agree with their views.  "Success" here is not measured by whether a WG
> is created (or not).  "Success" is providing quality input to the IESG on the
> merits from a broad range of participants.
> 
> Please understand that I am not saying that I think Jean-Marc and Jason would
> be deliberately unfair. I am saying that we should anticipate a lively
> their personal views while they are also acting as chairs.  For these reasons,
> I think that if the chairs all hold one view, the BOF is unlikely to be
> successful (using my definition above).
> 
> As far as codecs go, I think there is some value in having a couple of sample
> submissions to look at.  However, time will be valuable in the BOF. I think we
> should assume that the IESG will be able to assess the sample contributions
> without our needing to spend a lot of time discussing them.
> 
> charter's output is a single codec, not multiple codecs.  There would need to
> be a common understanding of whether the working group is selecting a single
> codec from the candidates, or somehow developing a common codec from more than
> one candidate.  There would also need to be some consensus on the basis for
> codec selection (and/or technology development), and some consensus on how to
> measure the codec performance against the various requirements, and of course
> at some point there will be more precision needed on the IPR rules.
> 
> discussion on these points ahead of time would be helpful to the IESG, and to
> the WG (when and if)..
> 
> IMHO we ought to refrain from accusing people of "killing", There is nothing
> to kill at this point.  Polarizing the debate by labeling the participants is
> not a constructive way to proceed.  The genuine areas of disagreement are hard
> enough.
> 
> Stephen Botzko
> Polycom
> 
> who reflect the different opinions around this subject. If this is not done I
> fear that this BoF will just end up in a verbal fist-fight and nobody benefits
> from it, it will only make us all look like morons.
>

---

From: "Christian Hoene" <[email-masked]>
Date: Fri, 10 Jul 2009 06:54:52 +0200

Good morning Slava and all,

to my understanding it is commonly understood on this mailing list that
nobody can guaranty a codec to be royalty-free and license-free. But I have
to agree that the wording have to be selected carefully. We shall avoid the
impression, that royalty-free or license-free is a promised feature of the
codec.

BTW: Is someone collecting the arguments on this mailing list?

Maybe the chairs can request a Wiki/ Trac web page, which can be used as a
collaborative platform to collect the results of the discussions and the
numerous contributions regarding the wording of requirements?

Thank you very much

 Christian

--------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of Tübingen
Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532

 <http://www.net.uni-tuebingen.de/> http://www.net.uni-tuebingen.de/

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Stephan Wenger
Sent: Friday, July 10, 2009 1:11 AM
To: Slava Borilin; stephen botzko; Ingemar Johansson S
Cc: [email-masked]
Subject: Re: [codec] Updated Agenda for Codec BOF

Hi,

I agree with Stephen that it would be better to EXCLUDE #4 from agenda – as
this may be time consuming.
Instead I would like to get back the item “requirements for codec, as they
may look like from IETF perspective” (royalty-free, license-free from legal,
+ technical (packet loss, MOS, performance)).

I object in the strongest possible terms to the implied statement that a
codec being “royalty-free and/or license-free from legal” is a requirement
from the IETF’s perspective.  A statement like this, if it were correct
(which it isn’t) may have legal implications that few, if any, of us here
fully understand.  Trust me on this (and/or ask your lawyer).  I’m serious.

Nowhere in the IETF’s legal framework there is a requirement for

If you would have been writing something like “Requirement as viewed by the
proponents of this BOF”, I would agree. 
If you would write “Desirable for the continued growth of Internet based
multimedia communication”, I would agree. 
If you would write “Desirable from an IETF viewpoint”, I would agree.  This
is supported by policy language.
If you would write, “Required for the future of the Internet” I would
disagree, but not object as noisily as in the statement you made.  It’s
abstract enough to be safe, as far as I can see.  But please leave the IETF,
as an organization, out of this picture.

In this discussion, we are touching the interface between engineering and
legal.  Let’s be careful; it’s easy to mess up things.

Regards,
Stephan

I do NOT think we (most of us) do not believe it’s feasible – so not much
point of discussing if its feasible to select good IP codec. Questions are
criteria, and path to go (=process).
 
Slava Borilin

  _____  

Given the goal of the BOF, the aim is for a moderated discussion of the
merits (pro and con). So I agree that it would be prudent to have chairs who
reflect the various views.  It will make it easier to keep the meeting
orderly and moving, since no one will feel that the chairs shut them down
because they didn't agree with their views.  "Success" here is not measured
by whether a WG is created (or not).  "Success" is providing quality input
to the IESG on the merits from a broad range of participants.

As far as codecs go, I think there is some value in having a couple of
sample submissions to look at.  However, time will be valuable in the BOF. I
think we should assume that the IESG will be able to assess the sample
contributions without our needing to spend a lot of time discussing them.

IMHO we ought to refrain from accusing people of "killing", There is nothing
to kill at this point.  Polarizing the debate by labeling the participants
is not a constructive way to proceed.  The genuine areas of disagreement are
hard enough.

Stephen Botzko
Polycom

Regards
Ingemar

Henry

  _____

---

From: "Slava Borilin" <[email-masked]>
Date: Fri, 10 Jul 2009 09:11:26 +0400

Stephan, Christian,

We are in agreement – royalty-free and license-free is seen as not “legally binding requirements”. I put “legal” just to name such group of requirements and separate them from other (performance) requirements.

I am not trying to get any guaranties, specifically in the area of IPR, so definitely “desirable” is proper word, not “required” –as we have no means to verify 100% whether we achieved the goal of being royalty-free, license-free, or not. And at this stage after codec is done, we can only believe more or less that it is royalty-free, patent-free.

Also, when I say “license-free” I do not mean “patent-free”, but “free from the need to sign licensing agreement(s) before use”.

= the ability for any user to get the codec and use it without signing any paperwork – this was discussed before on реу list, and Jean-Marc made a strong point which I share.

Slava Borilin

From: [email-masked] [mailto:[email-masked]] On Behalf Of Christian Hoene
Sent: Friday, July 10, 2009 8:55 AM
To: 'Stephan Wenger'; 'Jean-Marc Valin'; 'Jason Fischl'
Cc: [email-masked]
Subject: Re: [codec] Updated Agenda for Codec BOF

to my understanding it is commonly understood on this mailing list that nobody can guaranty a codec to be royalty-free and license-free. But I have to agree that the wording have to be selected carefully. We shall avoid the impression, that royalty-free or license-free is a promised feature of the codec.

Maybe the chairs can request a Wiki/ Trac web page, which can be used as a collaborative platform to collect the results of the discussions and the numerous contributions regarding the wording of requirements?

Thank you very much

 Christian

http://www.net.uni-tuebingen.de/ <http://www.net.uni-tuebingen.de/> 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephan Wenger
Sent: Friday, July 10, 2009 1:11 AM
To: Slava Borilin; stephen botzko; Ingemar Johansson S
Cc: [email-masked]
Subject: Re: [codec] Updated Agenda for Codec BOF

Hi,

I agree with Stephen that it would be better to EXCLUDE #4 from agenda – as this may be time consuming.
Instead I would like to get back the item “requirements for codec, as they may look like from IETF perspective” (royalty-free, license-free from legal, + technical (packet loss, MOS, performance)).

I object in the strongest possible terms to the implied statement that a codec being “royalty-free and/or license-free from legal” is a requirement from the IETF’s perspective.  A statement like this, if it were correct (which it isn’t) may have legal implications that few, if any, of us here fully understand.  Trust me on this (and/or ask your lawyer).  I’m serious.  

Nowhere in the IETF’s legal framework there is a requirement for royalty-free designs, let alone unencumbered designs or designs relying exclusively on non-assert covenants.  Nowhere in the IETF, except for the community consensus in certain, small, well-defined areas (such as baseline security), there is community consensus of such a requirement.  Certainly, there is no community consensus on this list with respect to the codec issue.

If you would have been writing something like “Requirement as viewed by the proponents of this BOF”, I would agree. 
If you would write “Desirable for the continued growth of Internet based multimedia communication”, I would agree. 
If you would write “Desirable from an IETF viewpoint”, I would agree.  This is supported by policy language.
If you would write, “Required for the future of the Internet” I would disagree, but not object as noisily as in the statement you made.  It’s abstract enough to be safe, as far as I can see.  But please leave the IETF, as an organization, out of this picture.

In this discussion, we are touching the interface between engineering and legal.  Let’s be careful; it’s easy to mess up things.

Regards,
Stephan

I do NOT think we (most of us) do not believe it’s feasible – so not much point of discussing if its feasible to select good IP codec. Questions are criteria, and path to go (=process).
 
Slava Borilin

Stephen Botzko
Polycom

Regards
Ingemar

Henry

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 09 Jul 2009 22:50:05 -0700

Hi Slava,

All you write below is reasonable to me, and understood.

My objection has been the close tie you have made between the terms
“royalty-free /license free ” and “requirement from an IETF’s perspective”.
Neither in the IETF policy documents, nor in IETF practice, there is such a
requirement.  If such a requirement were in existence, the IETF would need
to have a totally different set of policies, rules, and procedures---for
example following the blueprint of the W3C patent policy.  As a result, the
IETF would most likely also be populated by a somewhat different set of
people and companies.

The IETF’s patent policy can be summarized as “obtain and make available as
much information as possible on encumbrances, but don’t act on it as a
body”.  If you wish to change this policy, I would suggest you attempt to do
so in an appropriate forum.  Not in a random technical BOF.  If you want to
act within the policy framework we have, then please don’t attempt to bind
your commercial preferences to a term like “requirement from an IETF’s
perspective”.

Regards,
Stephan

On 7/9/09 10:11 PM, "Slava Borilin" <[email-masked]> wrote:

> Stephan, Christian,
>  
> We are in agreement – royalty-free and license-free is seen as not “legally
> binding requirements”. I put “legal” just to name such group of requirements
> and separate them from other (performance) requirements.
> I am not trying to get any guaranties, specifically in the area of IPR, so
> definitely “desirable” is proper word, not “required” –as we have no means to
> verify 100% whether we achieved the goal of being royalty-free, license-free,
> or not. And at this stage after codec is done, we can only believe more or
> less that it is royalty-free, patent-free.
>  
> Also, when I say “license-free” I do not mean “patent-free”, but “free from
> the need to sign licensing agreement(s) before use”.
> = the ability for any user to get the codec and use it without signing any
> paperwork – this was discussed before on реу list, and Jean-Marc made a strong
> point which I share.
> 
>  
> Slava Borilin
>  
> 
> 
> Christian Hoene
> to my understanding it is commonly understood on this mailing list that nobody
> can guaranty a codec to be royalty-free and license-free. But I have to agree
> that the wording have to be selected carefully. We shall avoid the impression,
> that royalty-free or license-free is a promised feature of the codec.
>  
> Instead I would like to get back the item “requirements for codec, as they may
> look like from IETF perspective” (royalty-free, license-free from legal, +
> I object in the strongest possible terms to the implied statement that a codec
> being “royalty-free and/or license-free from legal” is a requirement from the
> IETF’s perspective.  A statement like this, if it were correct (which it
> isn’t) may have legal implications that few, if any, of us here fully
> understand.  Trust me on this (and/or ask your lawyer).  I’m serious.
> 
> Nowhere in the IETF’s legal framework there is a requirement for royalty-free
> designs, let alone unencumbered designs or designs relying exclusively on
> non-assert covenants.  Nowhere in the IETF, except for the community consensus
> in certain, small, well-defined areas (such as baseline security), there is
> community consensus of such a requirement.  Certainly, there is no community
> consensus on this list with respect to the codec issue.
>

---

From: Monty Montgomery <[email-masked]>
Date: Fri, 10 Jul 2009 01:55:51 -0400

> If you wish to change this policy, I would suggest you attempt to do
> so in an appropriate forum.  Not in a random technical BOF.

This BOF is neither random nor is its stated aim purely technical.

It is a royalty-free codecs BOF.  I understand you wish to be very
careful here.  At the point that 'royalty free' is stricken, however,
we've tossed the baby out with the bathwater.

Monty

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 09 Jul 2009 23:37:02 -0700

Hi Monty,

I understand you guys don't want to remove the 'royalty-free' aspect.
That's your choice.  I will concede that such a choice could probably be
formulated into a charter of a WG---if one were formed, which I continue to
hope will not (for the numerous reasons that have already been discussed at
length, not primarily for this IPR stuff).  However, that formulation would
need to be worded carefully.  In a different environment (in JVT, which
operated under the ITU's and ISO/IEC's patent policy) we actually did
exactly that.  

In my opinion, the word "requirement" in relation to licensing terms needs
to be avoided.  The IETF does not have such requirements; not even a
requirement for a promise for RAND licensing.  There are historic and
structural reasons in the IETF's legal and policy framework that have led to
this situation.  Neither this mailing list, nor the BOF, are the right forum
to discuss the legal reasons that make me so nervous about the term
"requirement" and/or any automatic sanctions to an IETF document that would
kick in if an incompatible IPR disclosure were received.  (I'm not even
going into the business of interpretation of those disclosures, which
require a certain amount of expertise in their own right.)

Set a "goal" or a "desire" for certain commercial terms, if you wish.  That
has worked well enough elsewhere.

Regards,
Stephan

P.s.: actually, I don't think you really want "royalty-free".  What you
really want is open-source compatibility, right?  Most RAND-Z license
promises is not compatible with some of the more widely used open source
licenses (those that allow derivative works).  What you need for open-source
compatibility is commonly known as a patent non-assert covenant.

---

From: Monty Montgomery <[email-masked]>
Date: Fri, 10 Jul 2009 03:56:04 -0400

> really want is open-source compatibility, right?

This is a more accurate label, yes.

I'm not trying to dismiss your argument that a warranty is something
the IETF could never offer.  I was trying to push back against using
that assertion to state something much stronger ('...so we should not
even be trying to operate outside of a RAND system').

The patent situation today has put all of us in a bind where we can be
sued as individuals or organizations at any time and for nearly any
reason.  And yet, day to day, we still manage to muddle through in a
practically satisfactory way.  Just because an exact solution is NP
hard doesn't mean that a working solution isn't acheivable.

Monty

---

From: stephen botzko <[email-masked]>
Date: Fri, 10 Jul 2009 06:59:00 -0400

Comments in-line

Stephen Botzko
Polycom

> some moderator can be found for this WG - with an own codec in his lab or

Yes, I still have this concern.  I am not so worried about the working group
(when and if).  I am concerned about the BOF discussion.  It's difficult to
moderate a discussion like this when you are a stakeholder, and still be
perceived as fair.

> hinder the goals of this WG.

I agree that it would be most efficient to start with existing procedures,
and see how they fit. I would also include the process used by JVT for video
as another possible model.

---

From: stephen botzko <[email-masked]>
Date: Fri, 10 Jul 2009 07:26:28 -0400

Sorry to disagree on this.

- A 25 minute presentation is not "short" in a 2 hour meeting.  5 minutes
would be short.
- SILK and CELT are well known, and can be studied/reviewed by anyone
interested off-line.

The net effect of a 25 minute codec presentation by WG proponents is to
remove 25 minutes of discussoin time.  A second effect is that it biases the
time allotment in favor of proponents, which acts to skew the input to IESG
in that direction. Arguments against are just as important as arguments for
at this point in the process.

Perhaps a compromise is possible?  Move item 4 to the *end* of the agenda,
and make it the "time permits" activity?

Or (IMHO better still) create a *separate* informal session (perhaps during
the lunch break) where you present SILK and CELT to anyone interested in
more information about them?  Then you can go into more detail.

Regards
Stephen Botzko
Polycom

On Thu, Jul 9, 2009 at 3:47 PM, Jean-Marc Valin <[email-masked]
> wrote:

> requirements are achievable in a short time frame. The presentations will be
> short and high level, not technical descriptions of the codecs internals.
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 10 Jul 2009 08:46:08 -0600

On 7/10/09 5:26 AM, stephen botzko wrote:
> - A 25 minute presentation is not "short" in a 2 hour meeting.  5
> minutes would be short.
> remove 25 minutes of discussoin time.  A second effect is that it biases
> the time allotment in favor of proponents, which acts to skew the input
> to IESG in that direction. Arguments against are just as important as
> arguments for at this point in the process.
> 
> Perhaps a compromise is possible?  Move item 4 to the _end_ of the
> agenda, and make it the "time permits" activity? 

How about 5 minutes to discuss each of the codec I-Ds at a high level?
Allotting 10 minutes out of 2 hours to existence proofs and what they
imply for the work of the Codec WG (if approved) seems helpful to me.
Clearly anyone can read the I-Ds ahead of time, but IMHO the BoF can
productively talk about how these codecs could be used as input to a
working group.

Peter

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

---

From: "Roni Even" <[email-masked]>
Date: Fri, 10 Jul 2009 19:43:37 +0300

Hi,
I still fail to see what is the value in presenting one, two or three
codecs. I saw that there was a request to present a third one. 
I can agree that there are people who can present codecs as a suggested
solution including existing ones. Since there is no charter yet under which
the codecs are to be specified it may serve as a tutorial on codecs. So if
we open to codec presentation in the BOF let allow everyone to present their
codecs including ITU and MPEG ones and spend the whole BOF of the different
codecs technologies. 
If the idea behind this presentation is to show specific functionality than
instead it will be more fruitful to present requirements, since I could see
from the list discussion that there is no consensus even between the current
proponents what the requirements are.

Roni Even 

> Of Peter Saint-Andre
> Sent: Friday, July 10, 2009 5:46 PM
> To: stephen botzko
> Cc: Ingemar Johansson S; Slava Borilin; [email-masked]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.8 (Darwin)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkpXVDAACgkQNL8k5A2w/vxzFACgxpRsJZyUEcGzhmcpx8MARPE2
> TEUAoMwK2EjNJvBpmRfi3xCZuN1x/WLV
> =bx98
> -----END PGP SIGNATURE-----
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 10 Jul 2009 11:18:19 -0600

On 7/10/09 10:43 AM, Roni Even wrote:
> codecs. 

Present them as existence proofs (yes, we can!) and provide lessons
learned as input to the kind of work that a Codec WG would pursue. We
need to know that it is within the realm of possibility for a Codec WG
to be successful.

> I saw that there was a request to present a third one. 

Which?

> solution including existing ones. 

No. As far as I can see these are *not* suggested solutions. The point
is show that we have the expertise within the IETF to pursue this work,
to learn how those codecs were developed, and to judge whether we think
even better codecs could be developed by a Codec WG.

> Since there is no charter yet under which
> the codecs are to be specified it may serve as a tutorial on codecs. 

Given that the IETF has not traditionally been home to codec work, I
think that a very brief tutorial on what's involved in such work would
be quite beneficial.

> So if

Don't be ridiculous. Two or three proof points should be plenty.

> If the idea behind this presentation is to show specific functionality 

I don't think that's the idea.

> than

Discussion of existence proofs and lessons learned from previous codec
work is not at odds with discussion of requirements.

Peter

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

---

From: Jason Fischl <[email-masked]>
Date: Fri, 10 Jul 2009 10:37:37 -0700

The point of briefly presenting a few codecs is to show the type of  
work that would be done in the working group and to address the  
feasibility of the goal. It is not to present the issues with the  
particular codecs or even the details of the codecs. There have been  
assertions on the list that the IETF lacks the expertise to do this  
work. This agenda item attempts to address that concern.

I'd also like to encourage other people to post to the list with their  
opinions on whether or not agenda item 4 (codecs) should be included.

As Stephen suggests, Jean-Marc and I will arrange for a lunch codec  
tutorial session prior to the BOF on Wednesday or Thursday.

Jason

---

From: "Roni Even" <[email-masked]>
Date: Fri, 10 Jul 2009 23:56:10 +0300

Jason,
If you want to describe the type of work that will be done in the working
group it will be better to have a presentation on how you will define
requirements, test the quality and select a codec, how it is done in other
bodies and why should the IETF do it.
My current view based on the lack of any agreed requirements is that every
wide band codec is a good candidate including ones that were done by other
standard bodies. So to present just two do not have any value and may have
some bias, mostly since it is the ones suggested by the BOF chairs. If you
want to present codecs, I can probably present the list of all existing
codecs based on a list that is kept by the ITU.

As for showing that there are people capable of evaluating codecs in the
IETF, note that I did not say design but evaluate the process by which a
codec will be selected and evaluate the maturity of the proposal, I am not
sure that except for the proponent there are any others who have enough
experience in codec design and quality testing. I think that this is one of
the topics to be discussed since one of the conclusion of the iLBC work that
there is not enough such expertise.  

Roni Even

> From: Jason Fischl [mailto:[email-masked]]
> Sent: Friday, July 10, 2009 8:38 PM
> To: Roni Even
> Cc: 'Peter Saint-Andre'; 'stephen botzko'; 'Ingemar Johansson S';
> 'Slava Borilin'; [email-masked]
> >>> The net effect of a 25 minute codec presentation by WG proponents
> is
> >> to

---

From: "Roni Even" <[email-masked]>
Date: Sat, 11 Jul 2009 00:03:03 +0300

Peter,
Presenting the codecs does not supply proof. Presenting quality tests done by independent labs is a proof on the quality of the work suggested here. I do not except to see this at this stage of the work so presenting the codec will not give any proof except that there are proponent who want to approve their codecs. Many of the people coming to the IETF and attending the BOF see a codec as a black box and evaluate it based on the quality results

Roni Even

> From: Peter Saint-Andre [mailto:[email-masked]]
> Sent: Friday, July 10, 2009 8:18 PM
> To: Roni Even
> Cc: 'stephen botzko'; 'Ingemar Johansson S'; 'Slava Borilin';
> [email-masked]
> iEYEARECAAYFAkpXd9sACgkQNL8k5A2w/vzbdwCgxU2s6pjxTWp67WE30oJd/s1F
> L6AAn3s7EmSR3aDYrX0Pz79Rnjc36oVm
> =8ctr

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 10 Jul 2009 15:13:50 -0600

On 7/10/09 3:03 PM, Roni Even wrote:
> Peter, Presenting the codecs does not supply proof. Presenting
> quality tests done by independent labs is a proof on the quality of
> the work suggested here. 

I said that having presentations about SILK and CELT would provide an
existence proof that at least some people at the BoF have the ability to
develop codecs, not a proof of the quality of the future codec that
those people and others might produce within a possible Codec WG.

> I do not except to see this at this stage of
> the work so presenting the codec will not give any proof except that
> there are proponent who want to approve their codecs. 

On on what basis do you assert that people want to use a Codec WG as a
rubber stamp for existing codecs that they designed before the BoF was
even proposed? As I understand it, the focus of a Codec WG would be to
design a new codec, not give its blessing to any existing codec.

Peter

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

---

From: stephen botzko <[email-masked]>
Date: Fri, 10 Jul 2009 17:15:21 -0400

I think this presentation concept is better than a codec description.  It
would naturally form a framework for the following discussion.  Though I
still think it needs to be short (no more than 10 minutes), and it should be
clear to all that it represents just one view of how it might be done.

As far as codec developers goes, it is hopefully obvious to everyone (pro
and con) that there are quite a few individuals and organizations
participating in the IETF that have considerable expertise in codec
development.  I'm sure several also have experience with the codec
characterization/quality testing Roni mentions.  Though I think getting this
kind of testing in place will require quite a bit of work - my assessment is
that it is probably more work than standardizing the first codec.  Getting
agreement on the methodologies, the speech samples to use, etc. will take
time and effort.

Regards,
Stephen Botzko
Polycom

---

From: "Roni Even" <[email-masked]>
Date: Sat, 11 Jul 2009 00:43:59 +0300

Peter,
The purpose of the BOF is to find if there is a need for such work. Existing codecs is important input
Roni

> Sent: Saturday, July 11, 2009 12:14 AM
> To: Roni Even
> iEYEARECAAYFAkpXrw0ACgkQNL8k5A2w/vyq4gCfVxO32c/fPCVV/nMXTuHzOaZo
> L2cAnjZV/lc2DPKTGE/5f0DyaxCAqWA5
> =AO55

---

From: Koen Vos <[email-masked]>
Date: Fri, 10 Jul 2009 17:11:22 -0700

Quoting Roni Even:

> standard bodies.

Right, some of us with (associations to) employers that earn royalties  
on codecs don't agree with the goal of a royalty-free codec.  But  
isn't the ITU the better place to standardize royalty-bearing codecs?   
Why develop a codec with ITU-style licensing terms here at IETF?

Besides that I haven't seen any controversy.  The charter states basic  
requirements. We agreed on some technical details (like time scale  
modification), and test scenarios (clean speech, noisy speech,  
hands-free speech, a diversity of languages, and music - especially at  
higher rates).  A next step is to settle on the test specs.

So *my* current view based on the stated goals and requirements is  
that very few codecs fulfill them. For example, as we've discussed  
before, ITU codecs are expensive and/or perform so poorly that they  
are unsuitable for limited bandwidth applications (such as with mobile  
networks).

> If you want to present codecs, I can probably present the list of  
> all existing codecs based on a list that is kept by the ITU.

Great idea Roni, that will keep us busy for some time...

koen.

---

From: "Christian Hoene" <[email-masked]>
Date: Sat, 11 Jul 2009 08:56:46 +0200

Hello,

Recent comments suggested that there is a lack of experience in testing and
characterizing a codec proposal. I just like to comment that the process of
testing and selecting a codec in an IETF working group might be quite
different as compared to the ITU/3GPP because of the open source and royalty
free nature of the codec proposals.
First of all, the codec proposals can be made public at a very early stage.
Nobody has to wait that the algorithms of the codecs need to be filled as
patents. 
Second, many users can download the codecs and test them. In fact, CELT was
open source from the beginning and is part of the Debian Linux distribution
since April 2008. As a consequence, it is tested and used by many Linux uses
on a day to day basis. For example, I introduced Alexander Carot, a musician
and scientist, to Jean-Marc Valin. Alex tested CELT on stage using it for
distributed ensemble performances. In fact, he figured out some weaknesses
in CELT, which have been corrected then.
Third, the process of selecting one out of multiple codec proposal is much
easier because no one has to lose earnings from patent fees. The codec
developers might only lose or win reputation. Thus, the process of selecting
the best codec does not have to as perfect as in the ITU. The decision can
be made by rough consensus and must not be correct beyond any reasonable
doubts.
Overall, the process of codec assessment and selecting becomes easier and
less expensive. Instead of a few real (and expensive) experts on codec
testing, the coding tests can be done over larger period of time by many
(thousands) of users. Also, how cares which codec will make it if they
perform nearly identical. Nobody has to lose a lot in the end.

With best regards,

 Christian

PS:
It is out of question that Jean-Marc, Jason and many other on this mailing
list are experts on coding design. They have my full support as chairs of
this BOF (but of course not as chairs of a future WG codec).

--------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of Tübingen
Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen.de/

---

From: Herve Marcel Taddei 00900001 <[email-masked]>
Date: Sat, 11 Jul 2009 11:10:17 +0200

Hello,

> Recent comments suggested that there is a lack of experience in 
I dont think it is recent comments but based an AVT charter:"The group
continues to be precluded from work on codecs themselves because of
overlap with the other standards bodies, and because the IETF does not
have the ability to effectively review new codecs."

So it would be nice that in the agenda the following topics are added:
- overlap with other standard bodies
- capacity to effectively review new codecs.
- why do we need to change decisions taken a few years? What is new? What has changed?

> Nobody has to wait that the algorithms of the codecs need to be 
> filled as patents. 
Do you think that in 3GPP/ITU-T people first make a patent free baseline and then add their own IPRs? A bit strange view on how the work is done. BTW, in ITU-T and 3GPP, we first study the need of having the new codec (applications targeted) and it should be supported by many companies. So far I have understood that the application is RF codec. As pointed out many times, there are already many RF codecs. If they dont fit your needs, please explain what your special needs are? I have not seen that so far. That is why some people are concerned that this activity just consists in rubberstamping some codecs.

> open source from the beginning and is part of the Debian Linux 
> distributionsince April 2008. As a consequence, it is tested and 
> used by many Linux uses
> on a day to day basis. 
How do you keep interoperability if you keep changing the codec. I could understand that the encoder is changed, but the decoder must be stable otherwise the interoperability with previous version is gone. Standards are supposed to help interoperability and should be stable.

> For example, I introduced Alexander Carot, 
> a musician
> distributed ensemble performances. In fact, he figured out some 
> weaknessesin CELT, which have been corrected then.
If as soon as one person tries to work on a codec and finds weaknesses, it is not a very good sign for the stability of the codec...

> easier because no one has to lose earnings from patent fees. The codec
The selection of a codec should be made on the basis of the quality and more important on the need of having this new codec (applications, requirements, targetted bitrates, complexity, ...). 

> developers might only lose or win reputation. Thus, the process of 
> selectingthe best codec does not have to as perfect as in the ITU. 
If you enter a competition process, the selection has to be perfect otherwise the process would be unfair and that would create many problems. Who are the quality experts in IETF who would be able to say if a codec is good enough to be a standard and that it addressed all requirements?

> The decision can
> be made by rough consensus and must not be correct beyond any 
> reasonabledoubts.
The selection should be made on consensus and must be perfect.

> less expensive. 
Easier and cheaper are obviously good if it leads to the best decision achievable, I dont feel it will be the case.
So to the agenda we should have a section on the selection process.

> PS:
> It is out of question that Jean-Marc, Jason and many other on this 
> mailinglist are experts on coding design. They have my full 
> support as chairs of
On my side, I would support the comments made by some persons that we should have more neutral chairs for the BOF.

Best regards

Herve

---

From: "Christian Hoene" <[email-masked]>
Date: Sat, 11 Jul 2009 11:36:02 +0200

Hi Herve Marcel Taddei,

I found it difficult to follow your arguments because you were mixing the
different stages of the codec standardization. In my email I was discussing
the period in which the codecs are developed, implemented, tested and
selected. This period of time is after the requirements definition and
before standardization.

> If you enter a competition process, the selection has to be perfect
otherwise
> the process would be unfair and that would create many problems. 

I would really like to understand this argument. Could you please be more
precise on what kind of problems would occur if the selection process is not
done "beyond any doubts"?

Of course, all codec developers have invested a lot of time into their
codec. But most of this development times are lost anyhow, because only one
proposal could win. But then again, after one proposal has won, their
developer will not ear money with it... (at least not from the IPRs)

> The selection should be made on consensus and must be perfect.

Again, why? Please, please give me more arguments. Are they all still valid?
I don't believe that. Does the ITU-T have some documents on why the
selection process should be 100% perfect?

Thank you
 Christian

---

From: Herve Taddei <[email-masked]>
Date: Sat, 11 Jul 2009 12:59:07 +0200

Hi Christian Hoene,

> You don't select the best one, which should be in the end the goal of a
technical
> group. You run the risk to select a solution not based on their technical
merit and
> you could enter in very subjective decision. To be very basic, you could
have a
> decision on whether or not you like the proposal or the people it comes
from. That is
> why your selection process needs to be crystal clear.
> 
> We have selection process, requirements and objectives. You select the one
that
> achieve those requirements and standardize it.
> 
> BTW, I think it has been mentioned many times that we should not have
codec
> presentations in the agenda as long we have not understood what are the
> requirements and as long as the decision to start this activity has not
really been
> taken.

---

From: stephen botzko <[email-masked]>
Date: Sat, 11 Jul 2009 07:06:29 -0400

Obviously informal feedback on codec issues is useful, and I think most
codec developers would use it to correct flaws in the design.

However, I was not referring to that, I was referring to scientific
listening tests which provide reliable assessments on codec performance.
Other SDOs use those tests both to validate that the codec candidates meet
the requirements as well as in codec selection.  They may also use other
objective tests to certify that the floating point version of the algorithm
sounds identical to the fixed point version, or to validate that a small
change in design does not substantially change the codec performance.
Designing and administering such tests is a skill in its own right, the
folks who do that generally are not codec developers.

Also, how cares which codec will make it if they perform nearly identical.
Nobody has to lose a lot in the end.
I think the assessment process is multidimensional, not one dimensional.  I
don't think you're likely to have two codecs that  "perform nearly
identical" under all conditions (clean speech, noisy speech, reverberant
speech, various languages, various network conditions). The final tradeoff
will be more complicated - you'd want clear assurance that all candidates to
meet or exceed all requirements, and you'd also find each candidate (though
perhaps meeting the requirements) has its own weaknesses.  Some might
perform bettern on reverberant speech, others might perform better with
packet loss. The WG would then need to decide which requirements are most
important in making the final selection.   Using anecdotal evidence from
uncontrolled experiments to determine how candidate codecs perform in a
multidimensional space does not seem very likely to bring a good result to
me.

I agree the IETF might use a different test methods from other SDOs.  Since
I happen to think that reliable, reproducible codec assessment is needed for
the IETF to authoritatively review/recommend/standardize codecs, that makes
the IETF WG task more difficult, not less - there needs to be both agreement
on and development of suitable test methodolgy.

Regards,
Stephen Botzko
Polycom

On Sat, Jul 11, 2009 at 2:56 AM, Christian Hoene <[email-masked]>wrote:

> selecting

---

From: "Christian Hoene" <[email-masked]>
Date: Sat, 11 Jul 2009 13:37:33 +0200

Just to clarify my argument. I meant that the listening-only tests must not
be perfectly precise in a sense that the confidence interval of the results
of different codecs must not overlap. The larger the number of tests, the
smaller the confidence interval. If we allow for overlapping confidence
intervals (meaning that we cannot distinguish the audio quality of two
codecs in a particular situation), then fewer tests must be conduct. If we
have fewer tests, we have less costs.

But again, I would not underestimate the usefulness of a large group of
users to find bugs and weaknesses in a codec. CELT has its users and I bet
that different versions of SILK were tested in different versions of the
Skype softphone. (Sometimes after a call the Skype Softphone ask users for
their quality impression.)

With best regards,

 Christian

From: stephen botzko [mailto:[email-masked]] 
Sent: Saturday, July 11, 2009 1:06 PM
To: Christian Hoene
Cc: [email-masked]
Subject: Re: [codec] Updated Agenda for Codec BOF

Regards,
Stephen Botzko
Polycom

On Sat, Jul 11, 2009 at 2:56 AM, Christian Hoene <[email-masked]>
wrote:

Hello,

With best regards,

 Christian

PS:

---

From: Koen Vos <[email-masked]>
Date: Sat, 11 Jul 2009 06:05:38 -0700

Stephen,

The two elements that worry you seem to be:

1. It's hard to validate an individual codec - how good is good enough?

Good codecs have been developed without an expensive process involving third
parties to design and administer rigorous tests. In fact, we have several
people here at IETF who have done this with previous codecs.

Incidentally, both the CELT and SILK proposals are already being used in the
real-world today (tens of billions of minutes of calls have been made
through SILK for example). This exposes these codecs to a rigorous testing
in its own right.

2. It's hard to compare two candidates.

Well, so far the number of candidates is so small that the differences
between candidates may well be clear even without rigorous testing. If we
do end up with candidates that are close calls, we can always design more
rigorous test plans to determine which is the preferred one. Let's be
pragmatic about it.

So I agree with Christian that the IETF WG can succeed in standardizing an
ultra-useful codec even if the validation and selection process is different
from, and in some aspects less rigorous than that of e.g. the ITU.

We do need, of course, a list of test specifications and requirements. You
have already made great suggestions in this area, and I don't see much
controversy around it.

koen

---

From: stephen botzko <[email-masked]>
Date: Sat, 11 Jul 2009 12:53:05 -0400

We've also deployed non-standardized codecs reasonably successfully without
such testing.  Though when we did test Siren rigorously (as part of the ITU
process for G.722./ G.722.1C) we did uncover some issues that we didn't know
about before.  Ten years ago or so, I might have agreed with the view that
this testing is not particularly useful.  Now I have a different
perspective.

I think an SDO standardizing a new codec is in a different place from a
company or consortium that is "just" rolling out a codec, and that the IETF
(or any SDO really) does need to provide accurate information that
characterizes any codec that they standardize.  We really don't want
companies interested in deployment to have to do their own listening tests
in order to make sure that an IETF codec works with tonal languages.

I wasn't meaning to be controversial, or to state that the IETF processes
would need to be identical with other SDOs. I think that we do need to take
startup costs (like developing and agreeing to test methods) into account as
we consider this proposed working group.  And even in the charter
discussions we probably would need to address what level of "recommendation"
if any the IETF is making when it standardizes a codec.  Other SDOs are
making fairly strong statements when they standardize a codec, and do quite
a bit of testing to ensure that a new codec meets its stated performance
goasl. In fact, arguably such certification is one of the main benefits of
their standardization work.

BTW, I suspect that most comments about what the IETF can/can't do today are
*not* grounded in the skill sets of the participating members and the
organizations they represent.  Rather, they are references to this kind of
question - what would it take to put the participants expertise to work in
creating standards, and whether enough people who have the relevent
expertise are interesting in participanting.

Regards,
Stephen Botzko
Polycom

On Sat, Jul 11, 2009 at 9:05 AM, Koen Vos <[email-masked]> wrote:

>> On Sat, Jul 11, 2009 at 2:56 AM, Christian Hoene <[email-masked]
>> >wrote:
>>
>>  Hello,
>>>
>>> distribution
>>> mailing

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 11 Jul 2009 15:22:18 -0400

It should be noted that the IETF has frequently had bad luck deciding 
between two close competitors as solutions.  Sometimes, our process 
works very well for developing compromises and workable single 
interoperable solutions.  However, in cases where the comparisons are 
complex, the evaluation criteria unclear, and the possibilities close 
enough for argument, we frequently have trouble.

So, unless you really want to see multiple, non-interoperable, codecs 
from this (in which case why bother?) do not count on the IETF to be 
particularly better at resolving the disputes.  An unbiased forum we can 
provide.  resolving a widely split WG is much harder.

(I could cite multiple very unpleasant working groups where getting to a 
decision was extremely painful, and sometimes did not happen.  I don 't 
think the history lesson would actually add more than my summary.)

I would also re-iterate one other point.  One of the aspects of the IETF 
process is the community and IESG review.  This works well when at least 
a noticeable portion of the community outside of the WG understands the 
space well enough to tell whether a good job has been done.  And it 
helps if some IESG members understand the details of the space.  If the 
work can be evaluated well, then the IETF probably is not the place to 
do the work.  (This is a judgment call, and something on which 
reasonable people have been known to disagree.  What I have written is 
how I understand things.)

Yours,
Joel

Koen Vos wrote:
>>> filled as

---

From: Stephan Wenger <[email-masked]>
Date: Sat, 11 Jul 2009 13:41:34 -0700

Hi Christian,

I have two remarks to your post.

The first is that it is IMHO unrealistic to assume that there is any
difference in the timing of a proposal publication due to patent issues.
You (and, believe it or not, me as well) may not like that speech coding is
a heavily encumbered area.  But it is.  In such an environment, it would be
outright stupid for any entity with the resources and knowledge to file for
patents not to do so when the opportunity arises, if only to build up an
defensive portfolio.  That's completely independent from the future
licensing terms or revenues.  We have evidence that such filings did happen,
see https://datatracker.ietf.org/ipr/1164/ (related to silk) or
https://datatracker.ietf.org/ipr/319/ (related to iLBC and its payload
format).  Once you have decided that you need a portfolio, defensive or
otherwise, you are down to the timing requirements as imposed by patent law.
The secrecy around the internal design of speech codecs in other bodies, as
far as I understand, is not so much related to patent issues, but more to
avoid the analysis of your work by others in order to identify weaknesses in
that design, with the intention to argue towards selection criteria that
would make your codec look bad.  (Arguably, we have already seen some of
this discussion happening on this very list---which would actually speak in
favor of keeping designs closed...)

The second remark is that there can very well be serious commercial
competition between codecs, even assuming that the main proponents have
promised to license them for free (or making their relevant patents
available under an open-source friendly non-assert).  There have been small
companies in the codec business that built there whole business model on the
success of a certain codec technology, and, as part of their corporate
strategy, decided to forego the licensing revenue opportunity in favor of
growing the market and making their product offerings indispensible.  (My
own career included a tenure in one of those companies.)  That's only one
example why there's much more than reputation at stake here, even if you
folks were able to establish a royalty free ecosystem for a certain class of
speech codecs.  Which I don't think you are, based on my limited knowledge
of the patent landscape in this area, but that's another issue, and one
where there will hardly be a lot of discussion due to the legal environment.

Both aspects suggests to me that there is value in a reasonably well
developed process to select (or integrate, as the case may be) technologies
from the various proponents, which may very well include characterization
and testing in multiple languages.  I agree with you that this process does
not necessarily need to be as formalized as it is in some other SDOs.
However, that agreement does not stem from a major difference in the
commercial environment, but results mostly from my personal opinion that
those folks over-formalize their processes.  However, I also think that the
IETF's rather informal processes---while absolutely appropriate for
collaborative work on protocols, as shown by several hundreds of successful
examples---are suboptimal in this case.  Something new is needed if this WG
would be established, perhaps less formal and expensive as in the ITU or
3GPP, but very different from what we have elsewhere in the IETF.

Regards,
Stephan

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 11 Jul 2009 16:44:49 -0400

Dear Stephan;

Would you regard ISMA as a possible template for this work ?

Regards
Marshall

On Jul 11, 2009, at 4:41 PM, Stephan Wenger wrote:

>> reasonable

Regards
Marshall Eubanks
email   : [email-masked]
twitter : @TMEubanks
Cut the Cord with AmericaFree.TV

---

From: Stephan Wenger <[email-masked]>
Date: Sat, 11 Jul 2009 13:53:53 -0700

Hi Marshall,
I'm not so familiar with ISMA.  However, my vague recollection is that they
are as committed to MPEG codecs as they are to IETF protocol technologies
(plus/minus ultravox, which they are doing on their own AFAIK).  That
suggests, that the hard codecc selection work has already been done once the
integration work hits ISMA.  I may be wrong.
Regards,
Stephan

---

From: Marshall Eubanks <[email-masked]>
Date: Sat, 11 Jul 2009 16:57:11 -0400

> integration work hits ISMA.  I may be wrong.

Yes, they picked certain specific codec profiles from the already  
published set for solidification.

In my recollection they were

- pretty light weight and
- focused on interoperation

I mentioned them because they were a little more formal than the IETF,  
but not that much.

Regards
Marshall

Regards
Marshall Eubanks

---

From: Stephan Wenger <[email-masked]>
Date: Sat, 11 Jul 2009 15:28:58 -0700

Hi Marshall,

all of the committees I'm aware of that handle international speech
standardization from scratch (that is, without starting from an already
standardized approach) operate under essentially similar rules and
procedures.  Those include the ITU-T, MPEG (not a great example with their
rather unsuccessful speech codec work in MPEG-4, but there is also their
rather successful audio codec work), 3GPP, and 3GPP2 (and their respective
parent organizations as well as their predecessors, GSM, TIA, you name it).
Of course, all of those are also RAND-type SDOs.  Whether the procedures
used are a direct result of their RAND-type licensing requirements, or a
logical result of a procedure development process independent from the
licensing requirements, is subject to debate here.  However, one argument I
have made just recently is that, licensing revenue or not, there is quite a
bit at stake here, which may suggest that, at the end of a rules development
process, we may end up with comparable results.

There are a number of organizations that handled speech codec design (and
arguably, standardization, though the application of this term is disputed
by many) on a national level.  In the US, that would include the DoD stuff
like FS-1015 (LPC-10e), CELP, MELP, and STANAG.  Similar efforts have been
ongoing at least in Japan and in Korea, and perhaps elsewhere as well.  My
understanding is that their approach was/is roughly equivalent to the one of
the international bodies, just with less commercial competition and more
control by the "customer" (which also ran the standardization efforts).

Whether that necessarily speaks in favor of the procedures of these bodies
is another question.  However, there's certainly quite a bit of "running
code" out there, in the sense of experience.

(I do not want to ignore the speech codec work by the open source people
completely in this email.  However, what they have done, so far, hardly
qualifies as an international standardization effort for a number of reasons
I could name---which, I assume, is the reason we have this discussion in the
first place.)

Regards,
Stephan

---

From: Koen Vos <[email-masked]>
Date: Sat, 11 Jul 2009 17:26:30 -0700

Herve,

I would argue that the ITU-style testing process is expensive and
ineffective. The ITU model stems from a time when codecs were part of
firmware that was rolled out on a large scale. Since firmware is not
easily updated by end-users, it had to work for every user from day one.
Any bugs or weaknesses had serious consequences.

Today, speech and audio codecs have moved from the firmware space to the
software space. In contrast to firmware, software brings flexibility in
the form of gradual roll-out and simple upgrade mechanisms. This has
brought about a new testing method: beta testing. Products are being used
in the real-world while still under development. Beta testing has become
the norm in virtually all software development (except ITU codecs..), and
it's widely recognized as being more likely to find weaknesses and bugs,
at a fraction of the cost.

To be clear: software development also involves a lot of in-house testing.

Quoting Herve Marcel:
> If as soon as one person tries to work on a codec and finds  
> weaknesses, it is not a very good sign for the stability of the  
> codec...

1. CELT is still under development. No official (1.0) release has been
made. The first thing the web page tells you is that it's in an
experimental phase.

2. When ITU's "rigorous testing" finds a weakness in a codec, is that
a better sign for the stability?

3. ITU codecs frequently get amended after becoming standardized. How
do you feel about that?

4. I personally trust a codec with millions of hours of real-world usage
more than a codec with a few hours of lab testing.

koen.

---

From: Koen Vos <[email-masked]>
Date: Sat, 11 Jul 2009 20:03:26 -0700

Herve,

In particular I would like to point out that G.718, an ITU codec for which
your employer receives royalties, has already been corrected twice AFTER
being standardized less than a year ago:
http://www.itu.int/rec/T-REC-G.718/en

Perhaps a beta program could have prevented this..?

koen.

---

From: Koen Vos <[email-masked]>
Date: Sat, 11 Jul 2009 20:18:37 -0700

Let me take that back - G.718 is still in pre-published phase, only a  
recommendation so far. And clearly not very stable given all the  
corrections being made.

koen.

---

From: stephen botzko <[email-masked]>
Date: Sun, 12 Jul 2009 06:58:25 -0400

Perhaps the ITU process could be streamlined and made more efficient. I
didn't see anyone arguing that the IETF group would use another SDO's
process as-is anyway.

With all due respect, I think your arguments really apply to Skype, not to
an IETF WG.  There is no assurance that the best candidate for the internet
codec will be submitted by a group that already has an application with
millions of users to test it.  Or that the WG itself can guarantee that all
viable candidates (or the final candidate) will have that advantage, unless
it makes that a requirement for selection.  Hopefully you are not arguing
for that.

Certainly there are lots of internet-connected devices that run firmware,
and which are inconvenient  to (and not automatic to) upgrade.
Infrastructure devices (gateways, conference servers, etc) are one obvious
example.

And surely the publication of the RFC means that the project is finished, so
we are not talking about a never-ending continuous improvement development
effort.

BTW, I do not see how changes to G.718 software really matter much to this
discussion.  The fact that the ITU has folks who review/fix the code seems
to be a good thing.  I don't think those changes had any interoperability
impact when used with the initial source version.  Even if they did, in your
view the IETF WG codec source would be similarly revised.

Regards
Stephen Botzko
Polycom

On Sat, Jul 11, 2009 at 8:26 PM, Koen Vos <[email-masked]> wrote:

>> If as soon as one person tries to work on a codec and finds weaknesses, it
>> is not a very good sign for the stability of the codec...
>>
>

---

From: Koen Vos <[email-masked]>
Date: Sun, 12 Jul 2009 15:10:25 -0700

A beta testing phase is perhaps not simple to incorporate in the IETF  
process, but it's worth considering in my mind.  It has worked for  
both CELT and SILK.  Agree that it should not be a requirement for  
proposals.

Even when a codec ends up as firmware, my argument about the benefit  
of beta testing holds if that codec started its life as software.

koen

---

From: stephen botzko <[email-masked]>
Date: Mon, 13 Jul 2009 09:39:56 -0400

Hi Koen

I see some merit to a beta testing phase, as long as it does not replace
codec characterization testing and is not used to evaluate proposals.  It
could certainly expose problems that were not caught in previous phases, and
provides some assurance that the codec works as intended "in the wild".

Perhaps I don't understand where you were trying to go with your
software/firmware comments.  I suspect it doesn't really matter, though feel
free to clarify it (on or off the list) if you think there is something
important at stake that I'm not getting.

Stephen Botzko
Polycom

On Sun, Jul 12, 2009 at 6:10 PM, Koen Vos <[email-masked]> wrote:

> process, but it's worth considering in my mind.  It has worked for both CELT
> and SILK.  Agree that it should not be a requirement for proposals.Hi
>
> Even when a codec ends up as firmware, my argument about the benefit of
> beta testing holds if that codec started its life as software.
>
> koen
>
>

---

From: "Slava Borilin" <[email-masked]>
Date: Tue, 14 Jul 2009 22:49:07 +0400

Dear Jason, Jean-Marc,

Have you decided on the date and time for the lunch codec tutorial
session (for trip planning purposes) please?

best regards,
Slava Borilin

-----Original Message-----
From: Jason Fischl [mailto:[email-masked]] 
Sent: Friday, July 10, 2009 9:38 PM
To: Roni Even
Cc: 'Peter Saint-Andre'; 'stephen botzko'; 'Ingemar Johansson S'; Slava
Borilin; [email-masked]

Jason

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 14 Jul 2009 14:51:49 -0500

Switching tracks just a bit... I joined this group at the request of
Jean-Marc (although unfortunately I won't be able to attend the BOF in
person, but will be attending remotely via whatever means are made
available). As one of the major open source telephony platforms in the
world, the Asterisk project and community would *strongly* benefit a
from a high quality, efficient and reliable audio codec that can provide
a range of bandwidth and bit rate options and is *also* licensed in a
way that makes it compatible with even the most restrictive of common
open source licenses (GPLv2 and similar licenses).

Digium currently expends a great deal of effort making G.729 available
to the Asterisk community at a reasonable cost, which entails producing
binary distributions and dealing with patent licensing (and all the
requirements that brings along). We will do the same for G.722.1 and
G.722.1 Annex C, because those codecs are starting to appear on
endpoints and they provide real benefits over the other options that are
available. We also currently support iLBC (although we don't distribute
the source code for it due to the somewhat unusual license terms) and
Speex, which are the only other open source license compatible audio
codecs available today beyond G.711. We cannot see any practical way to
offer the Asterisk community support for any other ITU or 3GPP codecs,
because their "RAND" licensing precludes inclusion in an open source
project, and even if we are willing to charge/pay for licensing, the
terms are so skewed towards carrier deployments that we cannot
reasonably become involved with pass-through licensing unless we can
demonstrate up front that there is a large enough demand to warrant the
initial licensing costs. This is in spite of the fact that Asterisk is
being deployed heavily to interconnect to mobile networks, where support
of AMR, AMR-WB and EVRC would be most welcome indeed (and some users add
support for these codecs themselves, in spite of the patent infringement
risk).

While I cannot speak to the ability (or lack thereof) of an IETF WG to
formulate, publish and follow a codec development, testing and selection
process in the way that the ITU-T or other SDOs do, I can absolutely say
that we support *any* process that has a stated goal of producing a
world-class audio codec for speech and music, designed for Internet
applications, with a FLOSS-compatible license.

I look forward to seeing what this BOF can achieve; it is important that
codecs become available that can compete with RAND (or even more
restrictively licensed) codecs and have the backing of an established,
respected SDO, so that endpoint manufacturers will see the value of
including them in their products.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: "Roni Even" <[email-masked]>
Date: Wed, 15 Jul 2009 00:05:54 +0300

Kevin,
I see that you are using Speex and iLBC who are not standardize by any of
the SDOs so why not just add Silk or Celt support to you platform. I do not
think that the discussion is about the benefit of LF and simple licensing.
At least G.722.1 and G.722.1C were used also in their proprietary form
(SIREN) in the industry even though they were not standards because they
offered benfits. 
The discussion is if the IETF process can mandate and guarantee such outcome
(LF and Open source licensing). You have to take into account that a
standard process should have clear rules about the requirements and quality
of the outcome. It should give a fair chance for everyone to participate.
This also requires that there will be independent reviewers capable of
reviewing codec work.
On the other hand using Celt or Silk based on their current developers and
leaving it for their change control will be easier (like doing beta tests as
was suggested)  and their usage  in the market will be based on the quality
and benefits.
Like you mention you want to support all codecs being used in shipping
products and in my view the more codecs you add complicates the
interoperability. The IETF does not define system solution and your solution
will get better results if such codecs were defined in 3GPP or ETSI who
define the codecs you currently have problem with.

Roni Even.

> Of Kevin P. Fleming
> Sent: Tuesday, July 14, 2009 10:52 PM
> Cc: [email-masked]

---

From: Brian West <[email-masked]>
Date: Tue, 14 Jul 2009 16:36:34 -0500

Roni,
	I have been one of the cheer leaders behind wide/super/full band  
codecs in FreeSWITCH.  We have implemented G722.1, G722.1C and CELT in  
FreeSWITCH,  The uptake of wideband isn't as fast as it should be  
because most people don't realize how good it sounds till they hear  
it.  Once you have someone hear the clarity and quality of a voice  
call from halfway around the world they are usually sold on the idea.

/b

---

From: Brian West <[email-masked]>
Date: Tue, 14 Jul 2009 16:22:54 -0500

Kevin,
	So Digium is going to sell G722.1/1C like G.729 on Asterisk?

/b

On Jul 14, 2009, at 2:51 PM, Kevin P. Fleming wrote:

>  We will do the same for G.722.1 and
> available.

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 14 Jul 2009 15:47:45 -0600

>     So Digium is going to sell G722.1/1C like G.729 on Asterisk?

Brian:

Isn't such a question quite off topic for this list?

Peter

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

---

From: Brian West <[email-masked]>
Date: Tue, 14 Jul 2009 16:49:38 -0500

True, Didn't mean to replay all!  :)

/b

On Jul 14, 2009, at 4:47 PM, Peter Saint-Andre wrote:

> iEYEARECAAYFAkpc/QEACgkQNL8k5A2w/vyt/wCgjXdkCCUeKMviB8ONo1jQYnfq
> mMIAoNPfEdhUtOYpAkjgzc6oesBaQOeL
> =LIBf

---

From: "Andrew Sviridenko" <[email-masked]>
Date: Mon, 27 Jul 2009 00:40:05 +0400

Dear all-

SPIRIT DSP is interested to contribute to the IETF codec WG / BOF, and
present our IPMR wideband codec on July 30, along with SILK.

During the last 17 years (since 1992) SPIRIT DSP speech experts designed
and developed several proprietary codecs actually deployed by many
global leading telecom OEMs and semiconductor vendors-
http://www.spiritdsp.com/customers/

SPIRIT IPMR is multi-rate, scalable, adaptive, wideband codec
specifically designed for IP-based communications several years ago-
WGLC on draft-ietf-avt-rtp-ipmr-04

SPIRIT IPMR is-
- multi-rate, scalable, adaptive, wideband codec,
- low latency,
- delivers generally better voice quality than Speex,
- robust to packet loss,
- we have both PC and mobile (low MIPS) implementations,
- licensed and deployed by many leading companies, including Adobe and
Oracle, as well as multiple Asia-based telecom operators and telecom
OEMs,
- patent-free,
- payload already submitted to IETF.

SPIRIT would like to contribute to the codec WG / BOF of IETF, and help
create wideband codec standard for IP-communications and global voice
interoperability.

We can open-source SPIRIT IPMR if needed to make it part of the
standard.
We are also open to partner with bigger companies in this group if
needed to make IPMR codec part of the standard.

Please let us present our SPIRIT IPMR wideband codec on July 30, along
with SILK. Slava Borilin from SPIRIT DSP will join the WG / BOF.

Thank you,
Andrew Sviridenko
SPIRIT DSP, www.spiritDSP.com, Voice & Video Engine Experts

-----Original Message-----
From: Peter Saint-Andre [mailto:[email-masked]] 
Sent: Friday, July 10, 2009 9:18 PM
To: Roni Even
Cc: 'stephen botzko'; 'Ingemar Johansson S'; Slava Borilin;
[email-masked]

Which?

Peter

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

---

From: "Christian Hoene" <[email-masked]>
Date: Mon, 27 Jul 2009 17:55:47 +0200

To make the list complete, some weeks ago I requested to present the
Bluetooth SBC codec, which is good for similar usage scenarios as CELT and
is available as open source.

However, instead of codecs I think it is more important to discuss the
processes on how a Internet audio codec WG should develop, assess, and
select codecs. Obviously, we have already four candidates.

Another important point is on how other parties (e.g., the IESG) can
evaluate whether the WG does a good job. For example, there have been
requests on a proper codec classification and comparison.

None of these issues are addressed in the charter nor the agenda.

With best regards,
  Christian Hoene

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Andrew
> Sviridenko
> Sent: Sunday, July 26, 2009 10:40 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [AVT] [codec] Updated Agenda for Codec BOF
> 
> 
> Dear all-
> 
> Audio/Video Transport Working Group
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 28 Jul 2009 20:36:48 +0200

Hi,

We would like to include a slide describing IPMR and SBC in the codec
section of the BoF. Could you please provide us with a list of codec
features and characteristics for IPMR?

It is typical in the IETF to submit an Internet Draft in order to
receive agenda time on a specific proposal.

Cheers,

	Jean-Marc

---

From: "Slava Borilin" <[email-masked]>
Date: Tue, 28 Jul 2009 22:58:16 +0400

Jean-Marc, Jason,

Yes I will share the slides tomorrow (Wed).
We know we are late with the draft, but it will follow.

best regards,
Slava Borilin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Jean-Marc Valin
Sent: Tuesday, July 28, 2009 8:37 PM
To: Andrew Sviridenko
Cc: [email-masked]
Subject: Re: [codec] Updated Agenda for Codec BOF

Hi,

Cheers,

	Jean-Marc