Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

From: <[email-masked]>
Date: Fri, 11 Jan 2013 13:17:57 +0000

Koen Vos wrote:
> In short: there are IPR issues with the PLC required for using G.722 on the Internet.

NO, PLC solutions for G.722 with no IPR issues are publicly available in ITU-T Software Tool Library

http://www.itu.int/rec/T-REC-G.191-201003-I

8. G.722: The ITU-T 64, 56, and 48 kbit/s wideband speech coding algorithm 73

8.1.3 Functional description of the basic Packet Loss Concealment functionality 80

Stéphane

De : [email-masked] [mailto:[email-masked]] De la part de Koen Vos
Envoyé : jeudi 27 décembre 2012 19:34
À : Steve Sokol; Cullen Jennings (fluffy)
Cc : [email-masked]
Objet : Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs

Steve Sokol wrote:
> G.722 has no known IPR issues.

This is inaccurate.  

While the basic codec has no such issues, the various Packet Loss Concealment methods that were later added to the standard are patented.  This matters because G.722 uses ADPCM and is unusually sensitive to packet loss.  For instance, without PLC the codec will sometimes generate a full-scale oscillating output after a loss.  Since a traditional PLC doesn't work for this kind of behavior, there was a need to invent a PLC specifically for G.722.

In short: there are IPR issues with the PLC required for using G.722 on the Internet.

koen.

________________________________________
From: [email-masked] on behalf of Steve Sokol
Sent: Thursday, December 27, 2012 9:05 AM
To: Cullen Jennings (fluffy)
Cc: [email-masked]
Subject: Re: [rtcweb] Call for Consensus Regarding Selecting Recommended Audio Codecs
Per Cullen's request, here is the very short list of audio codecs that seem to have received some interest and the associated benefit of including them in the standard:

G.722 - The de facto standard for "HD audio", G.722 has the advantage of wide deployment in both hard and soft endpoints. G.722 has no known IPR issues. It consumes a relatively modest 64 Kbps which covers most use cases (though not Edge). Inclusion of G.722 would arguably simplify interoperability with HD-capable legacy endpoints and gateways.

AMR, AMR-WB - The official standards for mobile telephony. Adding support for the AMR codecs would arguably simplify the process of interoperation with mobile endpoints. Licenses would be required as both include patented technology.

None - Several group members have argued that the standard should not include SHOULD or RECOMMENDED codecs for various reasons.

Speaking for myself, I don't see much reason to include any of these. With mandatory encryption, media stream bundling and various other divergences from the way most legacy endpoints operate, I don't see unmediated legacy interoperability as likely to happen -- you will always need something to act as a gateway.  That being the case, why clutter up the standard with "SHOULD" or "RECOMMENDED" directives?

The best thing about WebRTC is that it is (thus far) not an attempt to re-build the PSTN on yet another IP platform. Keep is simple. 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 11 Jan 2013 15:18:24 +0100

> 8.1.3 Functional description of the basic Packet Loss Concealment functionality 80

Not speaking to the suitability of G.722, but on the "are there patents" 
issue:

G.191 (the software tools library) has no IPR statements in the ITU-T 
IPR database:
http://www.itu.int/ipr/IPRSearch.aspx?iprtype=PS

G.722 has 47 such statements against it, the first filed in 1996, the 
last filed in 2012.

Figuring out if any of those patent claims apply to the PLC part, 
whether those claims (if any) also apply to the G.191 implementation, 
and guessing at the reasons why they are filed against G.722 and not 
against G.191, is something I don't want to venture into at all.

I'll leave that to the proponents to sort out.

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Paul Coverdale <[email-masked]>
Date: Fri, 11 Jan 2013 11:46:39 -0500

Just to clarify, of the 47 IPR statements against G.722 in the ITU IPR
database, only 13 refer to "vanilla G.722". The rest relate to other
flavours, such as G.722.1, G.722.2 (essentially AMR-WB anyway), G.722-SWB
and various Appendices. Of these 13, 5 were filed in 1986, 1 in 2006 and 7
in 2012.

As for the accompanying ITU-T PLC algorithms, bear in mind that these are
Appendices, and hence not a normative part of G.722. Implementors are free
to do what they like about PLC.

...Paul

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of Harald Alvestrand
>Sent: Friday, January 11, 2013 9:18 AM
>To: [email-masked]
>> De : [email-masked] [mailto:[email-masked]] De la
>> part de Koen Vos Envoyé : jeudi 27 décembre 2012 19:34 À : Steve
>> Sokol; Cullen Jennings (fluffy) Cc : [email-masked] Objet : Re:
>> [rtcweb] Call for Consensus Regarding Selecting Recommended Audio
>> Codecs
>>
>> Steve Sokol wrote:
>> While the basic codec has no such issues, the various Packet Loss
>Concealment methods that were later added to the standard are patented.
>This matters because G.722 uses ADPCM and is unusually sensitive to
>packet loss.  For instance, without PLC the codec will sometimes
>generate a full-scale oscillating output after a loss.  Since a
>traditional PLC doesn't work for this kind of behavior, there was a need
>to invent a PLC specifically for G.722.
>>