Subject: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July 2009)

From: Cullen Jennings <[email-masked]>
Date: Tue, 14 Jul 2009 09:38:06 -0700

I just received this Liaison from the ITU. I wanted to forward it on  
so people could see it ASAP. If there are problems with attachments,  
let me know and I will get them posted to a site where people can get  
them.

Cullen

Begin forwarded message:

> From: <[email-masked]>
> Date: July 14, 2009 7:51:01 AM PDT
> To: <[email-masked]>, <[email-masked]>, <[email-masked]>
> Cc: <[email-masked]>, <[email-masked]>
> Subject: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July  
> 2009)
>
>
>
> Kindly find attached the Liaison Statement COM16 - LS 71 on  
> "information on ITU-T Speech and audio coding standardisation"  
> addressed to IESG and IETF-RAI agreed at the ITU-T WP2/16 meeting  
> (10 July 2009).
>
> Please take note that we are sending herewith the word version as  
> well as the pdf version of the LS.  In addition, there is an  
> attachment, which is in excel.  Since it is quite complex with  
> different sheets, we preferred to keep the excel file in the  
> original version.
>
>
>
>     <<ls071-16.doc>> <<ls071-16.pdf>> <<ls071_Att.1_Copy of MCSD- 
> Database-V20081003.xls>>
>
>
> Best regards,
> Rosa Angeles-León de Vivero
> Assistant for ITU-T Study Group 16
> ITU - Telecommunication Standardization Bureau (TSB)
> SG 16 e-mail: [email-masked]
> Tel.  41-22 730 5445
> Fax 41-22 730 5853
>
>

---

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

Cullen Jennings wrote:

> I just received
> this Liaison from the ITU. I wanted to forward it on so people could see it ASAP. If
> there are problems with attachments, let me know and I will get them
> posted to a site where people can get them. 

So that MCSD listing is quite interesting indeed; it's comprehensive,
and it appears to support some of the points that were used to initiate
this discussion in the first place; of that entire list of audio coding
standards known by the ITU-T (regardless of SDO), there are only four
that are in common use that are not under RAND licensing terms: G.711,
G.722.1 Annex C, iLBC and Speex. Of those four, only two have RF
licensing terms that are actually compatible with the majority of FLOSS
licenses in common use, G.711 and Speex.

-- 
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: Brian West <[email-masked]>
Date: Tue, 14 Jul 2009 12:57:37 -0500

Anyone ever get info out of Ericsson about G.719 licensing?  I refuse  
to sign the NDA to even get them to tell me the details of the license.

/b

On Jul 14, 2009, at 11:38 AM, Cullen Jennings wrote:

> let me know and I will get them posted to a site where people can  
> get them.
>
> Cullen
>

---

From: Henry Sinnreich <[email-masked]>
Date: Tue, 14 Jul 2009 12:41:58 -0700

>So that MCSD listing is quite interesting indeed; it's comprehensive,

Actually a more comprehensive list and comparison table of audio codecs is on the Wikipedia:

http://en.wikipedia.org/wiki/Comparison_of_audio_codecs

Henry

On 7/14/09 12:06 PM, "Kevin P. Fleming" <[email-masked]> wrote:

--
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
_______________________________________________
codec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/codec

---

From: Koen Vos <[email-masked]>
Date: Wed, 15 Jul 2009 01:33:34 -0700

So ITU won't adopt Royalty Free as a design goal, being equally fine  
with RAND licensing terms.  Regrettable.

Can anyone shine a light on what "misconceptions" were corrected in  
their Statement?

thanks,
koen.

Quoting Cullen Jennings <[email-masked]>:

>  so people could see it ASAP. If there are problems with  
> attachments,  let me know and I will get them posted to a site where  
> people can get  them.
>
> Cullen
>
>
> Begin forwarded message:
>
>> From: <[email-masked]>
>> Subject: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10 July  2009)
>>
>>
>>

---

From: "Christian Hoene" <[email-masked]>
Date: Wed, 15 Jul 2009 11:56:59 +0200

Hello,

I have copied the liaison statement into this email to comment it.
 
> Question(s):	8, 9, 10/16	Geneva, 10 July 2009
> LIAISON STATEMENT
> Source:	ITU-T SG 16 – Q8, 9, 10/16
> Title:	LS to IESG and IETF-RAI on information on ITU-T Speech and audio coding
> standardisation
> LIAISON STATEMENT
> For action to:	-
> For comment to:	-
> For information to:	IESG, IETF-RAI
> Approval:	ITU-T WP 3/16 meeting (Geneva, 10 July 2009)
> Deadline:	N/A
> Contact:	Ms Claude Lamblin
> France Telecom Orange
> France 	Tel: 	+33 2 96 05 13 03
> Fax: 	+33 2 96 05 35 30
> Email:	[email-masked]
> 
> 
> 1.	Introduction
> It has been brought to our attention that within IETF, the creation of a new
> IETF working group to define a wideband audio codec specifically for use with
> the Internet has been recently proposed. We observed that the initial proposal
> was followed by discussions on the IETF email reflector [email-masked] and
> that during these discussions, references to ITU-T speech and audio coding
> work were often made.
> Despite the intervention of some individuals familiar with ITU-T
> standardisation work, we regrettably observe that there are still several
> misconceptions and out-of-date understanding of the current state of the
> speech and audio coding work in ITU-T. 

I am reactivating my TIES account to get a detailed understanding of the current state of the work. I agree, it is a must. Having read the documents suggested during the discussion on this mailing list, I have to agree that in the last years the ITU-T SG16 and the 3GPP have made substantial progress towards a codec, which is more better suited for the Internet. However, still a number of issues have not been addresses, yet.

> We see as paramount that any decisions
> to be taken in the upcoming IETF meeting be taken on a sound basis, therefore
> ITU-T WP3/16 would like to offer the following information on ITU-T speech and
> audio coders and its standardization process, in order to help allay some of
> the observed misconceptions.
> 2.	Speech and Audio Coding Standards
> The ITU-T audio/speech codecs portfolio (see table below) is quite significant
> covering a wide range of audio bandwidths and bit rates, offering different
> trade-offs to address various applications with different requirements (on
> quality, bit rates, complexity, robustness, delay).

TCP, the main transportation protocol on the Internet, works on any link regardless whether it has a capacity of one 1 packet per second or one million. One reason for the success of TCP is that is can be used on any kind of device. No matter whether it is a 8bit processor or powerful mainframe.
I am wondering, why it is not possible to have a codec, which works on a wide range of different network conditions and on a wide range of devices. Maybe a combination of SILK and CELT can fulfill this dream?

> Audio Bandwidth [kHz]	Sampling frequency [Hz]	Bit rates [kbit/s]	ITU-T
> G.7xx-series
> 300-3400 (narrowband)	8000	5.3  80	G.711, G.726, G.727, G.728,
> G.729, G.723.1, G.729.1, G.711.1, G.718
> 50-7000 (wideband)	16000	6.6  96	G.722, G.722.1, G.722.2, G.729.1,
> G.711.1, G.718
> 50-14000 (superwideband)	32000	24  48	G.722.1C
> 20-20000 (fullband)	48000	32  128	G.719

One important criteria for Internet based transmissions is the packet rate (TCP controls the number of packets per round trip time, not the bit rate of user data). This important parameter is missing in the table.

> Conversational applications are the primary applications 
> and there has been an
> evolution from circuit-switched voice applications (e.g. PSTN and circuit
> multiplication equipment) to packet-based multimedia (notably IP).

To my understanding the goals of the proposed working group are to develop a codec that should be optimized thwarts the Internet. The support of classic PSTN networks is of lower importance.

We need a clear cut between the traditions of a circuit switched codec design and the work which shall be done here. A disruptive technology having different goals has to be developed. The evolution approach followed by the ITU might not allow a clean slate approach.

> ITU-T coders are extensively deployed and their modern applications go beyond
> the constraints for which the codecs were initially targeted. 

I do have the opinion that ITU_T make the most perfect codecs. But can every Internet user afford to license them? 

> Therefore, ITU-T has extended these coders with new features to provide quick responses to
> customer demands and to cope with new constraints of those modern
> applications. 
> For instance, Appendices to G.711 and G.722 – coders initially
> designed for PSTN and ISDN, respectively, provide Packet Loss Concealment
> (PLC) procedures to cope with packet losses that can occur during transmission
> over IP and other packet networks. 

In my opinion, the requirements of an Internet codec, which is not equivalent to a codec for packet networks, are not fulfilled if PLC is added a circuit switched codec. The technical requirements listed in the SILK draft are an example of requirements beyond PLC. 
Or to say it easier: CircuitSwitchedCodec + PacketLossConcealment != InternetCodec

> Other functionalities have been and are
> being developed such as wider audio bandwidth and stereo rendering capability.

CELT supports ultra-low latency audio transmission for distributed ensemble performances. The only standardized codec, which fulfills this requirement is the SBC from Bluetooth SIG. But of course, the current market for ultra-low latency audio transmission does not exist.

> As the collection of speech and audio coding standards – from ITU and other
> standards development organizations (SDOs) – is considerable, before launching
> the standardization of a new codec leading to interoperability problems, ITU-T
> WP3/16 checks whether the desired codec requirements are not met by existing
> standards.  ITU-T WP3/16 regularly updates a Media Coding Summary Data base
> (MCSD) which provides an authoritative summary of media coding standards of
> ITU-T and of other SDOs such as 3GPP, 3GPP2, ISO/IEC MPEG, ETSI, etc.

As soon the CODEC BOF participants write down requirements on the codec of the CODEC group are written down, we shall send them the ITU-T SG 16. It has to be made sure that we did not oversaw any existing codecs, which fulfill the requirements of an internet codec.

> 3.	ITU-T Standardization Process
> If market needs for a new codec are identified, the ITU-T speech and audio

The IETF has developed the Internet long before a market need has been identified. Also, I do not believe that a RF codec for the Internet will create a large market. Telephone calls over the Internet are typically free of charge. Companies have to make money by other means but with VoIP calls. 

> coding standardisation process has several well-defined stages from the
> specification of the Terms of Reference until the approval of the
> Recommendation. We have found over the years that this phased approach is
> necessary to ensure a transparent process and the best possible choice of
> technology for a particular purpose. The Terms of Reference contain the
> targeted applications, their associated design constraints and required
> performance (delay, complexity, audio bandwidth, bit rate, quality, etc). The
> approval of the Recommendation is based on the review of a list of
> deliverables: text of the proposed recommendation and C-code, performance in
> terms of quality, complexity, delay, and IPR policy (RAND or RF, see below).

As said before, ITU-T SG 16 processes are the best. We have to look at them...

> In the meantime, there are several stages to thoroughly assess the performance
> of the candidates, 

The Internet CODEC shall be available RF, which reduces the potential income for its developers. It would be nice to have the same assessment for an Internet CODEC. I doubt whether the participants and codec developers can afford them. 

> the quality performance being performed in close
> collaboration with SG 12, which selects the best suitable testing
> methodologies, designs the test plan and analyses the results from the
> international labs appointed by SG 12 to run the quality tests.  Currently,
> the experts in SG12 consider that subjective quality assessment based upon
> formal listening tests in at least two languages remains the most appropriate
> manner in which to evaluate codec performance and to guarantee suitability of
> codecs to international use.  Objective quality assessment methodologies are
> only considered appropriate to compare alternative implementations of the same
> codec.

Yes, I agree. Objective quality assessment methodologies cannot replace subjective tests. I have done some but I think it is a common understanding that the objective results are not precise and are only an indication of quality. They cannot replace formal tests following ITU-T P.800 or ITU BS.1534-1 procedures.

> Besides rigorous testing, since the standardization of G.729 and G.723.1, ITU-
> T speech and audio codec Recommendation specifications use C-source code in
> fixed point arithmetic as the normative algorithm description method
> (alternative floating point implementations are also provided). For older
> standards, reference C-source code can be found in the ITU-T Software tool
> library (G.191 Annex A).  This specification applies not only to the encoder
> and decoder but also to example solutions (e.g. Appendices describing packet
> loss concealment procedures).
> Once published, ITU-T speech and audio coding Recommendations with integrated
> C-source code are freely downloadable.

Is the ITU open source license compatible with BSD, LGPL, GPL? Maybe, somebody who understands this license can added it to Wikipedia? http://en.wikipedia.org/wiki/Open_source_license

> 4.	IPR Aspects
> With regard to the presence of intellectual property rights in our standards,
> the IPR policy adopted is consistent with those of other SDOs, where one must
> ensure that the standards can be implemented under either royalty free (RF) or
> reasonable and non-discriminatory terms (RAND). Extensively deployed ITU-T
> codecs encompass both RF and RAND policies. When the preference is RF there
> are ITU-T codecs to address this some of which are already used in Internet.

Yes, but they do not fulfill the technical requirements of an internet CODEC.

> 5.	Participation in ITU-T Work
> As a final observation, we would like to inform you that 191 countries (Member
> States) and over 700 companies of all sizes are members of ITU. There are many
> means to enable participation of non-ITU members in our standardization work.
> One tool is the participation sponsored by existing members, such as a Member
> State; we could cite the example of a university and later its spin-off
> company in North-America that for many years used that mechanism before
> becoming a member, and was able to successfully contribute to the development
> of various existing Recommendations. 

Yes, I agree. At least in Germany it is easy for an university employee to join the German ITU delegation. I have done this a couple of times joining SG12.

> Another possibility commonly used is
> participation at meetings as invited experts. The secretariat at
> [email-masked] is available to provide details to interested parties.
> 6.	Proposal
> In conclusion, we would be very happy to work with you, we will be glad to
> review any requirements you might develop for an “Internet wideband codec” and
> discuss possible ways to meet them.

Yes, I agree. We shall consider the offer to review the requirements - as soon as they have been written done. I think it would be very useful.

Thank you
 Christian Hoene

> 
> --------------------------------------------------------
> 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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Cullen Jennings
> Sent: Tuesday, July 14, 2009 6:38 PM
> To: [email-masked]
> Cc: Gregory Lebovitz
> Subject: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3 meeting (10
> July 2009)
> 
> 
> I just received this Liaison from the ITU. I wanted to forward it on so people
> could see it ASAP. If there are problems with attachments, let me know and I
> will get them posted to a site where people can get them.
> 
> Cullen
> 
> 
> Begin forwarded message:
> 
> 
> From: <[email-masked]>
> Kindly find attached the Liaison Statement COM16 - LS 71 on "information on
> ITU-T Speech and audio coding standardisation" addressed to IESG and IETF-RAI
> agreed at the ITU-T WP2/16 meeting (10 July 2009).
> Please take note that we are sending herewith the word version as well as the
> pdf version of the LS.  In addition, there is an attachment, which is in
> excel.  Since it is quite complex with different sheets, we preferred to keep
> the excel file in the original version.
> 
>     <<ls071-16.doc>> <<ls071-16.pdf>> <<ls071_Att.1_Copy of MCSD-Database-
> V20081003.xls>>
> 
> Best regards,

---

From: stephen botzko <[email-masked]>
Date: Wed, 15 Jul 2009 07:42:42 -0400

I share your view that the ITU-T testing processes are first rate, and that
we do need to take an objective look at their current approach.

I am curious as to why you are focused on TCP as the transport.  I'd think
that anything the working group does would be carried on RTP, which can use
either TCP or UDP, but generally uses UDP for most speech applications.

As far as packet rate, that is usually specified in the RTP packetization
RFC, not in the codec spec itself.   At present, the ITU-T is deferring to
the IETF, and not specifying the RTP packetization in their
recommendations.  Though generally they do amend the recommendation to
include a reference to the appropriate RFC after it is published.

I'd think that there would still need to be 2 specs - the RFC for the codec
itself, and a separate RFC for RTP/SIP, done through AVT.

Some more dicussion on specific requirements that are not in the ITU-T
codecs but which are desired in the "internet codec" would be fruitful, as I
agree that this proposed group (when and it) should have different goals
from other SDOs.  Ideally these goals would be broader than the attributes
of SILK or CELT, since it is reasonable to assume that this group would go
on to standardize more codecs (being re-chartered as necessary).  IPR terms
alone are not enough (in my view). to justify yet another codec
standardization group.

BTW, I don't think the ITU-T folks would agree that their codecs are
"circuit switched", I think they would argue strongly that they are already
standardizing codecs that are suitable for the internet.  If there are
requirements that they are missing, that would be a strong enough "market"
statement for the ITU-T.  They want to be sure there is an application for
the codec that current codecs don't satisfy.  They aren't particularly
concerned with how large that market is, they just want assurance that there
is one.

Regards,
Stephen Botzko
Polycom

On Wed, Jul 15, 2009 at 5:56 AM, Christian Hoene <[email-masked]>wrote:

> > was followed by discussions on the IETF email reflector [email-masked]
> I am reactivating my TIES account to get a detailed understanding of the
> current state of the work. I agree, it is a must. Having read the documents
> suggested during the discussion on this mailing list, I have to agree that
> in the last years the ITU-T SG16 and the 3GPP have made substantial progress
> towards a codec, which is more better suited for the Internet. However,
> still a number of issues have not been addresses, yet.
>
> TCP, the main transportation protocol on the Internet, works on any link
> regardless whether it has a capacity of one 1 packet per second or one
> million. One reason for the success of TCP is that is can be used on any
> kind of device. No matter whether it is a 8bit processor or powerful
> mainframe.
> I am wondering, why it is not possible to have a codec, which works on a
> wide range of different network conditions and on a wide range of devices.
> Maybe a combination of SILK and CELT can fulfill this dream?
>
> One important criteria for Internet based transmissions is the packet rate
> (TCP controls the number of packets per round trip time, not the bit rate of
> user data). This important parameter is missing in the table.
>
> To my understanding the goals of the proposed working group are to develop
> a codec that should be optimized thwarts the Internet. The support of
> classic PSTN networks is of lower importance.
>
> We need a clear cut between the traditions of a circuit switched codec
> design and the work which shall be done here. A disruptive technology having
> different goals has to be developed. The evolution approach followed by the
> ITU might not allow a clean slate approach.
>
> I do have the opinion that ITU_T make the most perfect codecs. But can
> every Internet user afford to license them?
>
> In my opinion, the requirements of an Internet codec, which is not
> equivalent to a codec for packet networks, are not fulfilled if PLC is added
> a circuit switched codec. The technical requirements listed in the SILK
> draft are an example of requirements beyond PLC.
> CELT supports ultra-low latency audio transmission for distributed ensemble
> performances. The only standardized codec, which fulfills this requirement
> is the SBC from Bluetooth SIG. But of course, the current market for
> ultra-low latency audio transmission does not exist.
>
> As soon the CODEC BOF participants write down requirements on the codec of
> the CODEC group are written down, we shall send them the ITU-T SG 16. It has
> to be made sure that we did not oversaw any existing codecs, which fulfill
> the requirements of an internet codec.
>
> The IETF has developed the Internet long before a market need has been
> identified. Also, I do not believe that a RF codec for the Internet will
> create a large market. Telephone calls over the Internet are typically free
> of charge. Companies have to make money by other means but with VoIP calls.
>
> The Internet CODEC shall be available RF, which reduces the potential
> income for its developers. It would be nice to have the same assessment for
> an Internet CODEC. I doubt whether the participants and codec developers can
> afford them.
>
> Yes, I agree. Objective quality assessment methodologies cannot replace
> subjective tests. I have done some but I think it is a common understanding
> that the objective results are not precise and are only an indication of
> quality. They cannot replace formal tests following ITU-T P.800 or ITU
> BS.1534-1 procedures.
>
> Is the ITU open source license compatible with BSD, LGPL, GPL? Maybe,
> somebody who understands this license can added it to Wikipedia?
> http://en.wikipedia.org/wiki/Open_source_license
>
> > 4.    IPR Aspects
> Yes, I agree. At least in Germany it is easy for an university employee to
> join the German ITU delegation. I have done this a couple of times joining
> SG12.
>
> Yes, I agree. We shall consider the offer to review the requirements - as
> soon as they have been written done. I think it would be very useful.
>
> Thank you
>  Christian Hoene
>
> >

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 15 Jul 2009 09:54:48 -0400

Hi Stephen,

stephen botzko wrote:
> I'd think that there would still need to be 2 specs - the RFC for the 
> codec itself, and a separate RFC for RTP/SIP, done through AVT.

I totally agree on this. Codecs and transport are two different things. 
That's why both SILK and CELT have separate drafts for the codec and the 
RTP profile. Of course, the codecs can (and should) be designed in parallel 
with the RTP profile to make sure they work well with the RTP/SIP/SDP stack.

> codecs but which are desired in the "internet codec" would be fruitful, 
> as I agree that this proposed group (when and it) should have different 
> goals from other SDOs.Â  Ideally these goals would be broader than the 
> attributes of SILK or CELT, since it is reasonable to assume that this 
> group would go on to standardize more codecs (being re-chartered as 
> necessary).Â  IPR terms alone are not enough (in my view). to justify 
> yet another codec standardization group.Â 

In my opinion, IPR alone would be sufficient. But at the same time I agree 
that if we're going to standardise codecs, they might as well be targeted 
specifically for the Internet. The goals of MPEG and ITU-T are very 
different and I would expect this WG to have goals that are different from 
both.

Cheers,

	Jean-Marc

---

From: Herve Taddei <[email-masked]>
Date: Wed, 15 Jul 2009 17:04:25 +0200

Dear Jean-Marc,

> specifically for the Internet. The goals of MPEG and ITU-T are very
different

> and I would expect this WG to have goals that are different from both.

It would be good that you clarify what you call a codec specifically
designed for Internet. In ITU-T and 3GPP they have codecs that seem to be
adequate for VoIP, see G.711, G.729. Speex Narrowband for example was not
very different to G.729/AMR in the principle, it is some kind of CELP codec
as you well know. Is that what you call a codec for Internet? BTW, is Speex
WB a codec for Internet?

It is something I am trying to understand from the different emails, but so
far I have not succeeded. The only thing I could assume is that what you
call an Internet codec is a RF codec. In that case G.711, G.722, G.722.1 and
G.722.1C (and soon SBC if I understood well the previous emails) and
certainly some other codecs will be “Internet” codecs according to my
understanding of your definition. Is my understanding correct? Is the only
requirement? Are there technical requirements? I would appreciate if you
could clarify.

Best regards

Hervé

---

From: Steve Underwood <[email-masked]>
Date: Wed, 15 Jul 2009 23:28:56 +0800

Jean-Marc Valin wrote:
> I totally agree on this. Codecs and transport are two different 
> things. That's why both SILK and CELT have separate drafts for the 
> codec and the RTP profile. Of course, the codecs can (and should) be 
> designed in parallel with the RTP profile to make sure they work well 
> with the RTP/SIP/SDP stack.
>
>> Some more dicussion on specific requirements that are not in the 
>> ITU-T codecs but which are desired in the "internet codec" would be 
>> fruitful, as I agree that this proposed group (when and it) should 
>> have different goals from other SDOs.Â  Ideally these goals would be 
>> broader than the attributes of SILK or CELT, since it is reasonable 
>> to assume that this group would go on to standardize more codecs 
>> (being re-chartered as necessary).Â  IPR terms alone are not enough 
>> (in my view). to justify yet another codec standardization group.Â 
>
> In my opinion, IPR alone would be sufficient. But at the same time I 
> agree that if we're going to standardise codecs, they might as well be 
> targeted specifically for the Internet. The goals of MPEG and ITU-T 
> are very different and I would expect this WG to have goals that are 
> different from both.
Opinion is nice, but its better when backed up with need.

I used to have a digital telephone answering machine, and it used a 
codec with a stack of patents on it (I know the one, as I worked on it 
:-) ). Did I care? No. The $1-$2 those patents cost to licence was a bit 
skewed compared with the $1 RAM chip the voice was stored in, but it all 
came bundled in the cost of the machine. It was transparent. It created 
no obstacles.

Now I get voice mail from a web browser. People make calls from VoIP 
phones using G.729, and the G.729 ends up in a voice mail box. I use 
Firefox to access that mailbox. Can the voice be delivered to me as 
G.729? Nope. G.729 can't be distributed with a product like Firefox, for 
patent reasons. Even a 0.1 cent royalty for G.729 would stop it being a 
straightforward download. Popping up a box telling me to go buy and 
install some codec just ain't gonna cut it these days. So, we have to 
use something else. We typically end up using something at a much higher 
bit rate, in most cases, as transcoding from one low bit rate codec to 
another sounds pretty bad.

The separation of software from hardware, and much of the software we 
use for key internet activities being free downloads, has been a game 
changer. Come up with a new codec that can't be freely distributed, and 
its an irrelevance that will eventually have to be bypassed. We will 
still be left to work on a solution that can be freely distributed.

It comes down to the important and subtle difference between $0.00001 
and $0.

Steve

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 15 Jul 2009 11:44:04 -0400

Given that the odds of achieving the stated IPR goals are extremely 
small, it would seem very strange to undertake the effort with the 
primary purpose of meeting those goals.

Yours,
Joel

> Hi Stephen,
...
> targeted specifically for the Internet. The goals of MPEG and ITU-T are 
> very different and I would expect this WG to have goals that are 
> different from both.
> 
> Cheers,
> 
>     Jean-Marc

---

From: stephen botzko <[email-masked]>
Date: Wed, 15 Jul 2009 11:46:43 -0400

We agree that royalty-free is very important for some distribution models.
However, royalty-free speech codecs can and have been standardized in other
SDOs, which is why I am saying our goals need to be broader.

The observation that most speech codecs do have royalties is on point,
however (as I've said before) this is not inherent to the process used by
the other SDOs.  Rather, it is because the most of the contributors have
chosen to set those terms.

BTW, if you read the proposed charter for this working group, it says "as
much as possible choose technology that does not require paying patent
royalties", which is somewhat softer than what many posters here seem to be
assuming.

http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt

Regards,
Stephen Botzko
Polycom

On Wed, Jul 15, 2009 at 11:28 AM, Steve Underwood <[email-masked]>wrote:

>> That's why both SILK and CELT have separate drafts for the codec and the RTP
>> profile. Of course, the codecs can (and should) be designed in parallel with
>> the RTP profile to make sure they work well with the RTP/SIP/SDP stack.
>>
>>> from other SDOs.Â  Ideally these goals would be broader than the attributes
>>> on to standardize more codecs (being re-chartered as necessary).Â  IPR terms
>>> standardization group.Â
> I used to have a digital telephone answering machine, and it used a codec
> with a stack of patents on it (I know the one, as I worked on it :-) ). Did
> I care? No. The $1-$2 those patents cost to licence was a bit skewed
> compared with the $1 RAM chip the voice was stored in, but it all came
> bundled in the cost of the machine. It was transparent. It created no
> obstacles.
>
> Now I get voice mail from a web browser. People make calls from VoIP phones
> using G.729, and the G.729 ends up in a voice mail box. I use Firefox to
> access that mailbox. Can the voice be delivered to me as G.729? Nope. G.729
> can't be distributed with a product like Firefox, for patent reasons. Even a
> 0.1 cent royalty for G.729 would stop it being a straightforward download.
> Popping up a box telling me to go buy and install some codec just ain't
> gonna cut it these days. So, we have to use something else. We typically end
> up using something at a much higher bit rate, in most cases, as transcoding
> from one low bit rate codec to another sounds pretty bad.
>
> The separation of software from hardware, and much of the software we use
> for key internet activities being free downloads, has been a game changer.
> Come up with a new codec that can't be freely distributed, and its an
> irrelevance that will eventually have to be bypassed. We will still be left
> to work on a solution that can be freely distributed.
>
> It comes down to the important and subtle difference between $0.00001 and
> $0.
>
> Steve
>
>

---

From: Steve Underwood <[email-masked]>
Date: Thu, 16 Jul 2009 00:13:54 +0800

> primary purpose of meeting those goals.
What is this based on? People tried to attack Vorbis, and the only 
successful tactic they tried was FUD. Speex hasn't attracted any 
vultures so far. Nobody can guarantee patent issues have been properly 
handled - an extra licencee was recently added to the patent pool for 
G.729. Patent holders can always crawl out of the woodwork. However, 
saying the chances of success are extremely small is ****EXTREMELY**** 
defeatist. Why not just give up on life and end it all? :-)

Steve
>> agree that if we're going to standardise codecs, they might as well 
>> be targeted specifically for the Internet. The goals of MPEG and 
>> ITU-T are very different and I would expect this WG to have goals 
>> that are different from both.
>>
>> Cheers,
>>
>>     Jean-Marc

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 15 Jul 2009 11:07:39 -0700

Hi,

On 7/15/09 9:13 AM, "Steve Underwood" <[email-masked]> wrote:

> vultures so far. 

Sorry, but this is nonsense.  Patent assertions and lawsuits are like bugs.
You can sometimes observe their presence, but you can never show their
absence.  (Well, my old CS theory professor would argue against that for
bugs, but I don't think anyone can reasonably argue against it for patent
assertions).  Just because you, and, presumably, your company has not been
approached for licensing revenues does not mean that no one else has.

I would also be careful to name anyone who is exercising one's legal right
to enforce a patent a "vulture".  People have been sued for even using the
much more frequently used word "troll".

> Nobody can guarantee patent issues have been properly
> G.729. 

Depending on how "properly handling of patent issues" is defined, it can
sometimes be guarantied.  To the best of my knowledge, there have been no
violations of the ITU patent policy in the G.729 case, to which (I believe)
you are referring to.

There is no requirement set by the ITU (or any other SDO I'm aware of,
outside China at least) to join a patent pool, and, to the best of my
understanding of antitrust law, there cannot be such a requirement.

> Patent holders can always crawl out of the woodwork.

That is true.

> However, 
> defeatist. 

I agree with Joel, and disagree with you, that the chances are "extremely"
small, based on my own experience (which, quite obviously is not the same as
yours.)

> Why not just give up on life and end it all? :-)

Because at least my life is not dependent on an IETF project towards a
open-source friendly codec RFC.  If yours is, I would be ****EXTRENELY****
sorry for you.  :-)

Regards,
Stephan

---

From: "Slava Borilin" <[email-masked]>
Date: Wed, 15 Jul 2009 22:39:43 +0400

>> sometimes be guarantied.  

Just remember 2007's scandal and legal case on MP3 patent and Microsoft
;-)

best regards,
Slava Borilin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stephan Wenger
Sent: Wednesday, July 15, 2009 10:08 PM
To: Steve Underwood; Joel M. Halpern
Cc: [email-masked]
Subject: Re: [codec] Fwd: COM 16-LS 71 - Outgoing LS from ITU-T WP3
meeting (10 July 2009)

Hi,

> successful tactic they tried was FUD. Speex hasn't attracted any

Sorry, but this is nonsense.  Patent assertions and lawsuits are like
bugs.
You can sometimes observe their presence, but you can never show their
absence.  (Well, my old CS theory professor would argue against that for
bugs, but I don't think anyone can reasonably argue against it for
patent
assertions).  Just because you, and, presumably, your company has not
been
approached for licensing revenues does not mean that no one else has.

I would also be careful to name anyone who is exercising one's legal
right
to enforce a patent a "vulture".  People have been sued for even using
the
much more frequently used word "troll".

Depending on how "properly handling of patent issues" is defined, it can
sometimes be guarantied.  To the best of my knowledge, there have been
no
violations of the ITU patent policy in the G.729 case, to which (I
believe)
you are referring to.

That is true.

> saying the chances of success are extremely small is ****EXTREMELY****

I agree with Joel, and disagree with you, that the chances are
"extremely"
small, based on my own experience (which, quite obviously is not the
same as
yours.)

Because at least my life is not dependent on an IETF project towards a
open-source friendly codec RFC.  If yours is, I would be
****EXTRENELY****
sorry for you.  :-)

Regards,
Stephan

---

From: stephen botzko <[email-masked]>
Date: Wed, 15 Jul 2009 13:54:23 -0400

Well, Vorbis is not a speech codec, it's not a "must have" codec for music
in any player (PC or otherwise), and most of the folks deploying it haven't
had any money anyway.  I'd suggest that there's not a lot of incentive for
anyone to go after it.

Speex is more on point for this proposed group I think.  As it gains in
popularity, it could very well draw more attention.  As would an IETF
standard, which is likely to be a "must have" codec in at least one market
segment.  Joel is not the only poster to say that they think the odds are
slight.

At this point, I'm more concerned about the details on how the IPR goal
would be implemented.  The group should not need to be legal experts, and I
really don't want to end up with the group attempting to publicly construe
patent claims.

I would also like to see procedures that allow contributors to delay full
disclosure of algorithms/source code.  Publishing one's current proprietary
methods could also invite legal problems for the publisher, and allow your
methods to be analyzed (or copied) by your competition. Obviously you need
to disclose in order to standardize.  But if your contribution doesn't make
the cut (for whatever reason), you'd have disclosed it to no purpose.

So some pre-qualification phase, where full disclosure isn't required, might
be a useful middle ground.  The goal would be to get more contributions, not
to permit folks to sneak encumbrances into the standard.

Stephen Botzko
Polycom

On Wed, Jul 15, 2009 at 12:13 PM, Steve Underwood <[email-masked]>wrote:

> Joel M. Halpern wrote:
>
>> Given that the odds of achieving the stated IPR goals are extremely small,
>> it would seem very strange to undertake the effort with the primary purpose
>> of meeting those goals.
>>
>> Yours,
>> Joel
>>
> successful tactic they tried was FUD. Speex hasn't attracted any vultures so
> far. Nobody can guarantee patent issues have been properly handled - an
> extra licencee was recently added to the patent pool for G.729. Patent
> holders can always crawl out of the woodwork. However, saying the chances of
> success are extremely small is ****EXTREMELY**** defeatist. Why not just
> give up on life and end it all? :-)
>
> Steve
>
>
>> Jean-Marc Valin wrote:
>>
>>> Hi Stephen,
>>>
>> ...
>>
>>> targeted specifically for the Internet. The goals of MPEG and ITU-T are very

---

From: Stephan Wenger <[email-masked]>
Date: Wed, 15 Jul 2009 12:01:36 -0700

Oh, I'm aware of this.  Perhaps more than I like it.  But even in this case
I fail to see how there was a violation of MPEG's processes or the ISO/IEC's
patent policy.  Avoiding such violations is the best we can possibly shoot
for, I guess.
Regards,
Stephan

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 15 Jul 2009 15:04:11 -0400

Hi Herve,

> designed for Internet. In ITU-T and 3GPP they have codecs that seem to 
> be adequate for VoIP, see G.711, G.729. Speex Narrowband for example was 
> not very different to G.729/AMR in the principle, it is some kind of 
> CELP codec as you well know. Is that what you call a codec for Internet? 
> BTW, is Speex WB a codec for Internet?

Speex is a codec that addresses what *I* (and a handful of early adopters) 
perceived to be the needs of the Internet back in 2002 and is by no means 
perfect. It has a few features that -- while not unheard of -- where still 
uncommon at the time, such as embedded wideband, multi-rate capability and 
source-controlled VBR. There was also the licensing, which is not just 
about money, but about enabling new Internet applications that were simply 
not possible with the typical ITU licensing. Note that at the time, Speex 
was not even meant to compete with G.729 and AMR-NB. All it had to do to be 
useful is be better than G.711, GSM-FR and LPC10 -- which is what people 
who couldn't afford per-channel royalties were using.

So we are now in 2009 and both the Internet and the codec technology have 
evolved since 2002. It would be a good thing to look at how we can address 
the current needs of the Internet with current technology. The idea is that 
doing that within the IETF based on a consensus is preferable to the way 
that Speex was designed. I'll go as far as to say that, had Speex been 
through IETF standardisation, some of its "sub-optimal" design decisions 
would likely have been avoided/corrected (non-integer number of bytes per 
compressed frame comes to mind).

> It is something I am trying to understand from the different emails, but 
> so far I have not succeeded. The only thing I could assume is that what 
> you call an Internet codec is a RF codec. In that case G.711, G.722, 
> G.722.1 and G.722.1C (and soon SBC if I understood well the previous 
> emails) and certainly some other codecs will be “Internet” codecs 
> according to my understanding of your definition. Is my understanding 
> correct? Is the only requirement? Are there technical requirements? I 
> would appreciate if you could clarify.

I think the final requirements will have to be established with the IETF 
community, so what follows is only my personal opinion (and I expect that 
many issues are missing). I see differences between the Internet and what 
the ITU currently targets that go much beyond the IP transport part, which 
I agree that the ITU *is* addressing (though I think the ITU -- rightly -- 
puts more emphasis on bit error robustness than is needed for the 
Internet). As I said earlier, licensing is one of these aspects. Codecs on 
the Internet should be a commodity and not a barrier to entry. There are 
many applications or business models (open source or not) on the Internet 
for which per-channel royalties are simply not an option, no matter what.

There are also more technical aspects. One difference between the Internet 
and the cell phone market that many recent codecs focus on is the cost of 
bandwidth. While not free, Internet bandwidth is a lot cheaper than 
cellular wireless bandwidth, so it makes sense to target higher quality. Of 
the ITU codecs you list, I consider that G.722.1C is the only one that can 
really be said to have good quality, but even then it's limited in sampling 
rate (32 kHz), bit-rate (48 kbit/s music sounds bad) and latency (40 ms is 
a lot of delay in my opinion).

Another issue is "legacy support". I understand how important it is for the 
ITU to release codecs that are backward-compatible with "legacy 
infrastructure", which explains the recent batch of codecs like G.729.1, 
G.711.1, G.718 and others. I'm not sure we need that complexity for an 
Internet codec where codecs are generally easier to deploy and negotiate 
(SIP/SDP). These are just a few examples I see that go beyond "works on 
packet networks".

Cheers,

  	Jean-Marc

---

From: Steve Underwood <[email-masked]>
Date: Thu, 16 Jul 2009 03:08:43 +0800

Hi Stephan,

> approached for licensing revenues does not mean that no one else has.
Why did you separate my sentance that said essentially the same thing?
> much more frequently used word "troll".
I think you need to accuse a specific person or entity of being a 
vulture before having any concerns of that type.
> understanding of antitrust law, there cannot be such a requirement.
Well, on the subject of G.729, Toshiba was not represented in the patent 
pool until July 2008. Before that people licensing the relevant patents 
were going, in good faith, to the licence pool, to Nokia, and to NEC. It 
seems they should have been going to Toshiba as well. From what was 
published it doesn't seem too clear whether prior licensees of the pool 
get backdated indemnification for the Toshiba patents or not. Clearly it 
could have gone either way.

If there is a path of doing your best to skirt around other people's 
patents, and a path of blundering into them and hoping for a patent 
pool, why would anyone suggest the later (unless they are part of the 
pool, of course)?

Without a patent pool its a nightmare to licence patents, unless you are 
very big. G.723.1, for example, is something that has far less users 
than there might have been with a working patent pool. Its a huge pain 
to licence. However, as you said, antitrust laws create problems for 
pools. The MPEG pool was actually nurtured into existence with a helping 
hand from the government, because the licencing issues were such a 
nightmare things were not taking off. Patent holders were afraid of an 
antitrust backlash against a pool, before the government showed a pool 
had its blessing. So, the path of choosing an overtly patented option is 
hardly a smooth path.
> small, based on my own experience (which, quite obviously is not the same as
Codecs are a patent minefield. No question there. You only need to fall 
foul of a single obscure patent somewhere or other to have trouble. In 
that regard almost all engineering is a minefield, but the codec mines 
are more closely spaced than most. Nonetheless, there are codecs around 
offering good quality, which people have not been able to challenge 
after trying really hard. They really really tried with Vorbis, and they 
failed. When they couldn't attack it legally, there was a smear 
campaign. It survived, though. Its not an easy path, but its not impossible,
> open-source friendly codec RFC.  If yours is, I would be ****EXTRENELY****
What's life without interesting challenges? :-)
Steve