Subject: [codec] Customer demand for royalty-free internet codec

From: Dean Bogdanovic <[email-masked]>
Date: Fri, 10 Jul 2009 00:20:14 -0400

After reading discussions on this topic, thought to add customer view  
on this one.

In the last 12 month, I've participated in several customer projects  
in Asia, Africa and Europe. All of them were trying to add voip over  
their 3G data networks as service and were looking for low-latency  
royalty free codec. Two of the projects were interesting, as different  
carriers connected their voip networks and allowed traffic between  
voip UAs directly (no PSTN interconnect). The biggest problem ended up  
being codec, as the results of testing with different royalty free  
codecs weren't satisfying.
In general, carrier groups are looking to use IP as primary  
communication mechanism among their group members and for them royalty  
free, adaptive/low latency is really important, as (Asia, Africa and  
part of Europe) their subs have low ARPU and many of them are  
traveling for work outside of their home countries. So you have  
carrier groups covering all those countries, but they don't have an  
(cheap) option to provide affordable service to their customers.

this is commercial view why work of this BOF (and creation of WG) is  
valuable. It would be nice some positive results coming from this

Dean

---

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

Dean,
These carrier worry about their revenues, so they are looking for free
codecs. That is understandable from their perspective but are they going to
offer me as an enduser a free service as a result. 
I can understand a request for RF codec from non profit solution providers
but I can not feel any obligation to support ones that care for their
revenue stream by getting free product. They can also ask for free routers
to connect their networks.

As for the IETF work, I did not see that they are looking for standard
codecs, they still could use celp or other free codecs if the quality is
right
Roni Even 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Dean Bogdanovic
> Sent: Friday, July 10, 2009 7:20 AM
> To: [email-masked]
> Subject: [codec] Customer demand for royalty-free internet codec
> 
> _______________________________________________
> codec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/codec

---

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

> to connect their networks.

How is this relevant to conversation?  What do free codecs have to do
with free hardware?

You seem to be arguing that commodity codecs are a patent absurdity
(no pun intended or implied) and yet here we have three offered within
the scope of the WG.

For the record, I care very much about for-profit ventures using my
free work to enhance their bottom lines-- I want very much for them to
do so.  If they want my direct personal development support time, then
we can discuss a reasonable fee.

Monty

---

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

Monty,
I was responding to the customer demand. They can go and ask you for a RF
codec but to go to a standard body and ask for RF codec so that they can
make more profit is not a relevant input.
Roni

> From: Monty Montgomery [mailto:[email-masked]]
> Sent: Friday, July 10, 2009 11:15 AM
> To: Roni Even
> Cc: Dean Bogdanovic; [email-masked]
> Subject: Re: [codec] Customer demand for royalty-free internet codec
>

---

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

> make more profit is not a relevant input.

Sure they can.  Forgive the flippant tone below.  I'm quite serious.

How dare a for-profit company send packets using free TCP/IP over the
public network!  People worked long and hard on that.  Taxpayer
dollars went into it.  It's just wrong.

How dare a company make a profit offering client interoperable email
services based on free standards!  The IETF obviously erred badly with
RFC 822..2822/etc.  There could have been a ton of money in email.

How dare a company make money off of the web where all the standards
are free?  Especially a company using the web to increase profits.
The W3C are a bunch of suckers.

...so how is audio (and for that matter, video) fundamentally
[conceptually/morally] different?  It is not rare and precious science
despite occasional claims to the contrary.

Or, we could just agree this was a completely irrelevant tanget and
not get distracted by spurious moral outrage at upstart companies
attempting to [gasp] compete more effectively.  "Does this WG belong
in the IETF" is a valid debate.  "No, because companies just want to
undercut the current stakeholders" is not a compelling argument even
if it's a rather breathtaking one.

Monty
[too much?]

---

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

... Or, we could just agree this was a completely irrelevant tanget and
not get distracted...

That would be my vote.

Regards,
Stephen Botzko
Polycom

---

From: Randell Jesup <[email-masked]>
Date: Fri, 10 Jul 2009 11:41:53 -0400

Dean Bogdanovic <[email-masked]> writes:
>After reading discussions on this topic, thought to add customer view  on
>this one.
>
>In the last 12 month, I've participated in several customer projects  in
>Asia, Africa and Europe. All of them were trying to add voip over  their 3G
>data networks as service and were looking for low-latency  royalty free
>codec. Two of the projects were interesting, as different  carriers
>connected their voip networks and allowed traffic between  voip UAs
>directly (no PSTN interconnect). The biggest problem ended up  being codec,
>as the results of testing with different royalty free  codecs weren't
>satisfying.

What was the result of testing with iLBC?  Did they test that?  Was the
issue the lack of adaptive capability, or was wideband required?

>In general, carrier groups are looking to use IP as primary  communication
>mechanism among their group members and for them royalty  free,
>adaptive/low latency is really important, as (Asia, Africa and  part of
>Europe) their subs have low ARPU and many of them are  traveling for work
>outside of their home countries. So you have  carrier groups covering all
>those countries, but they don't have an  (cheap) option to provide
>affordable service to their customers.

The cheaper they can obtain the codecs (especially when they can avoid
the PSTN network), the cheaper they can provide service, and the more
people who can afford their service.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Dean Bogdanovic <[email-masked]>
Date: Fri, 10 Jul 2009 16:30:19 -0400

yes, they tested iLBC. In tonal languages they need wide band codec,  
as it gives them better quality and iLBC didn't do a good job on that  
one. Regarding the adaptiveness, it ended up being pretty good, but  
again the problem was with tonal languages, as the quality degraded  
with packetloss.

Dean
On Jul 10, 2009, at 11:41 AM, Randell Jesup wrote:

>> communication

---

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

Hi,
This is relevant to the testing requirements.
BTW: the ITU-T testing is done in more than one language and I mentioned it
in previous message to the list

Roni Even

> Sent: Friday, July 10, 2009 11:30 PM
> To: Randell Jesup
> Cc: [email-masked]; Dean Bogdanovic
> Subject: Re: [codec] [SPAM?] Re: Customer demand for royalty-free
> internet codec
> Importance: Low
>

---

From: "Raymond (Juin-Hwey) Chen" <[email-masked]>
Date: Wed, 29 Jul 2009 14:12:01 -0700

All,

If the IETF codec WG is formed, Broadcom Corporation would like to submit its family of BroadVoice®16 (BV16) and BroadVoice32 (BV32) standard codecs to the IETF codec WG for consideration as a candidate codec or a candidate building block for the proposed Internet Wideband Audio Codec (IWAC) standard.  Currently Broadcom is already offering its patent rights, floating-point C source codes, and fixed-point C source codes of BV16/BV32 on a royalty-free basis, and Broadcom is even willing to make BV16/BV32 open source.

A little background on BV16/BV32.

BV16 and BV32 have been standardized by multiple standard organizations for VoIP applications in cable telephony.  BV16 is a 16 kb/s codec for 8 kHz narrowband signals; it is a standard codec in the following standards: PacketCableT 1.5, PacketCable 2.0, ANSI/SCTE 24-21 2006, and ITU-T Recommendation J.161.   Similarly, BV32 is a 32 kb/s codec for 16 kHz wideband signals, and it is a standard codec in PacketCable 2.0, ANSI/SCTE 24-23 2007, and ITU-T Recommendation J.361.  The RTP payload formats for BV16 and BV32 are specified in RFC4298.  BV16 and BV32 belong to the same family of codecs.  They have very similar codec structures and share most of the algorithm modules, so if the two are implemented together, substantial code sharing and memory reduction can be achieved.

Broadcom developed BV16 and BV32 from the ground up with a goal of avoiding known third-party intellectual property rights (IPR).  Although it was correctly pointed out earlier in the IETF codec WG email discussion that no one can be absolutely sure that a given codec is completely free of third-party IPR, we took two steps to help increase our confidence.  First, to help avoid the codec IPR minefield, we purposely avoided the popular and heavily-patented CELP coding paradigm, and instead took an "ancient art" (circa. 1954) technique of noise feedback coding (NFC) that nobody seemed to be interested in (i.e., it was the subject of very few recent publications) and improved it to get BV16/BV32.  Any patent on the fundamental NFC presumably expired long ago.  Second, several extensive patent searches were performed during the development of BV16/BV32 to help avoid third-party IPR.  To the best of our knowledge, BV16 and BV32 do not infringe on any valid unexpired third-party patent claim.  

BV16 and BV32 were also designed from the ground up to be optimized for voice transmission over IP networks, with high speech quality, low latency, low complexity, and high robustness to packet loss as primary design goals.  Thus, BV16 and BV32 are ideally suited for low-latency, high-quality voice transmission over the Internet.  The following summarizes the attributes of BV16 and BV32:

.	Low Delay (Latency): algorithmic buffering delay of merely 5 ms (compared with 15 to 40 ms of competing codecs)
.	Low Complexity: much lower MIPS requirements than most competing codecs (typically ½ to 1/3 of comparable ITU-T G.72x codecs), also lower memory requirement than most other competing codecs
.	High Quality: equivalent or better speech quality than competing codecs in extensive formal subjective MOS listening tests conducted by AT&T Labs, COMSAT Labs, and Dynastat, Inc.
.	Availability: Broadcom is offering its patent rights, floating-point and fixed-point C source codes of BV16/BV32 on a royalty-free basis; BV16/BV32 to become open source soon.

For comprehensive comparisons between BV16/BV32 and other codecs, please see the codec comparison tables in Annexes C and D (pages 73 - 81) of the PacketCable 2.0 Codec and Media Specification, available at:

http://www.packetcable.com/downloads/specs/PKT-SP-CODEC-MEDIA-I02-061013.pdf

Broadcom believes that as compared to the other nearly two dozen dominant codecs listed there, BV16 and BV32 offer the most compelling combinations of low delay, low complexity, high quality, moderate bit-rate, and royalty-free patent rights and C source codes.  The algorithm descriptions of BV16 and BV32 can be found in the two ANSI/SCTE standard documents below:
http://www.scte.org/documents/pdf/Standards/ANSISCTE24212006.pdf
http://www.scte.org/documents/pdf/Standards/ANSI_SCTE24-232007.pdf

It seems clear from the previous email discussion in the IETF codec WG reflector that voice transmission over the Internet is the primary application of the proposed IWAC, although transmitting general audio (music, etc.) at high fidelity is also desirable/necessary. It is also clear from the emails that royalty-free, low latency, and high quality are all highly desirable.  Given what was described above about BV16/BV32, it would seem that BV16/BV32 is an ideal candidate and is sufficient to cover the narrowband (8 kHz) and wideband (16 kHz) voice transmission aspects of the applications of IWAC.  To get higher sampling rates and higher audio bandwidths, it is possible to use BV16 and BV32 as the base layers and add additional bits on top of the BV16/BV32 bit-streams to encode an appropriately formulated difference signal to get a scalable, embedded codec that goes from 8 kHz sampling at 16 kb/s all the way to 48 kHz sampling at a much higher bit-rate.  One advantage of doing so is that the resulting IWAC will be interoperable with the BV16/BV32 in the PacketCable, ANSI/SCTE, and ITU-T J.161/J.361 standards. This is similar to the relationship between ITU-T G.729.1 and G.729.

Juin-Hwey (Raymond) Chen
Broadcom Corporation