Subject: [rtcweb] Confirmation of consensus on audio codecs

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 16 Aug 2012 17:15:42 +0000

At the last meeting we took a hum on selecting Opus and G.711 as the mediatory to implement audio codecs. If there is any new opinions please send them to the list by August 30th, after which the chairs will make a determination of consensus.

Thanks,
Cullen

Please note that the following IPR disclosure have been made on these codecs. They can be found at 

http://datatracker.ietf.org/ipr/

2010-11-07	
• ID # 1445
"Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (1)"
2010-11-07	
• ID # 1446
"Xiph.Org Foundation's Statement about IPR related to draft-ietf-codec-opus-00"
2010-11-12	
• ID # 1447
"Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (2)"
2011-03-23	
• ID # 1520
"Qualcomm Incorporated's Statement about IPR related to draft-ietf-codec-opus-05"
2011-03-27	
• ID # 1524
"Xiph.Org Foundation's Statement about IPR related to draft-ietf-codec-opus-05"
2011-03-29	
• ID # 1526
"Broadcom Corporation's Statement about IPR related to draft-ietf-codec-opus-05"
2011-03-29	
• ID # 1525
"Skype Limited's Statement about IPR related to draft-ietf-codec-opus-05"
2011-07-23	
• ID # 1602
"Skype Limited's Statement about IPR related to draft-ietf-codec-opus-07"
2012-01-25	
• ID # 1670
"Microsoft Corporation's Statement about IPR related to draft-ietf-codec-opus-10"
2012-03-12	
• ID # 1712
"Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-codec-opus-11 (1)"
2012-04-02	
• ID # 1741
"Huawei Technologies Co.,Ltd's Statement about IPR related to draft-ietf-codec-opus-11 (2)"

---

From: Roman Shpount <[email-masked]>
Date: Thu, 16 Aug 2012 13:35:01 -0400

As I have mentioned before I would like to see G.722 as a mandatory to
implement codec in addition to G.711 and OPUS. G.722 is license free and is
widely supported. It operates at the same bandwidths as G.711 with
virtually the same CPU requirements, but offers HD audio
quality superior to G.711.

One question I wanted to ask about G.711, do we require any of the
appendixes to be implemented, ie would PLC and DTX be required? I think
that PLC should be at least recommended, since it will significantly
improve resulting communication experience in most of the real deployment
scenarios.
_____________
Roman Shpount

On Thu, Aug 16, 2012 at 1:15 PM, Cullen Jennings (fluffy)
<[email-masked]>wrote:

>
> At the last meeting we took a hum on selecting Opus and G.711 as the
> mediatory to implement audio codecs. If there is any new opinions please
> send them to the list by August 30th, after which the chairs will make a
> determination of consensus.
>
> Thanks,
> Cullen
>
> "Broadcom Corporation's Statement about IPR related to
> draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (1)"
> 2010-11-07
> • ID # 1446
> "Broadcom Corporation's Statement about IPR related to
> draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (2)"
> 2011-03-23
> • ID # 1520
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 16 Aug 2012 19:23:43 -0400

Reading this list is occasionally an act of torture banned by several
conventions ..but since you ask.

I completely support the selection of Opus and G.711 as mandatory to
implement audio codec's ..however I'm very very open minded about supporting
G.722. It has it merits.  It should be totally obvious to most that if you
even think about interconnecting to public E.164 networks the default option
for VoLTE and Enterprise Voice networks is going to be G.722. 

If it is your goal to create globally useful stove pipes fine,  but
interconnection with existing carrier real time networks is IMHO a rational
goal. 

As for Video .. for goodness sakes just get over it people. H.264 is totally
implemented everywhere on the planet Earth. So what about the intellectual
property problems. It's not like VP8 doesn't have problems either. 

I'll save my comments about the SDP offer/answer issue for another day. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Cullen Jennings (fluffy)
Sent: Thursday, August 16, 2012 1:16 PM
To: [email-masked]
Subject: [rtcweb] Confirmation of consensus on audio codecs

Thanks,
Cullen

Please note that the following IPR disclosure have been made on these
codecs. They can be found at 

2010-11-07	
. ID # 1445
"Broadcom Corporation's Statement about IPR related to
draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (1)"
2010-11-07	
. ID # 1446
"Xiph.Org Foundation's Statement about IPR related to
draft-ietf-codec-opus-00"
2010-11-12	
. ID # 1447
"Broadcom Corporation's Statement about IPR related to
draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (2)"
2011-03-23	
. ID # 1520
"Qualcomm Incorporated's Statement about IPR related to
draft-ietf-codec-opus-05"
2011-03-27	
. ID # 1524
"Xiph.Org Foundation's Statement about IPR related to
draft-ietf-codec-opus-05"
2011-03-29	
. ID # 1526
"Broadcom Corporation's Statement about IPR related to
draft-ietf-codec-opus-05"
2011-03-29	
. ID # 1525
"Skype Limited's Statement about IPR related to draft-ietf-codec-opus-05"
2011-07-23	
. ID # 1602
"Skype Limited's Statement about IPR related to draft-ietf-codec-opus-07"
2012-01-25	
. ID # 1670
"Microsoft Corporation's Statement about IPR related to
draft-ietf-codec-opus-10"
2012-03-12	
. ID # 1712
"Huawei Technologies Co.,Ltd's Statement about IPR related to
draft-ietf-codec-opus-11 (1)"
2012-04-02	
. ID # 1741
"Huawei Technologies Co.,Ltd's Statement about IPR related to
draft-ietf-codec-opus-11 (2)"

---

From: Monty Montgomery <[email-masked]>
Date: Thu, 16 Aug 2012 20:11:04 -0400

> It's not like VP8 doesn't have problems either.

Actually, no, it doesn't have problems.

Monty
Xiph.Org

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 16 Aug 2012 17:41:50 -0700

I also support the selection of OPUS and G.711 as MTI. G.722 can be a SHOULD; it is widely supported.

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 16 Aug 2012 21:38:32 -0400

SOOO WRONG .. just do a simple search.  It just hasn't been fully litigated
...yet. 

-----Original Message-----
From: Monty Montgomery [mailto:[email-masked]] 
Sent: Thursday, August 16, 2012 8:11 PM
To: Richard Shockey
Cc: Cullen Jennings (fluffy); [email-masked]
Subject: Re: [rtcweb] Confirmation of consensus on audio codecs

Monty
Xiph.Org

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 16 Aug 2012 21:40:34 -0400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bernard Aboba
Sent: Thursday, August 16, 2012 8:42 PM
To: [email-masked]
Cc: Cullen Jennings (fluffy); [email-masked]
Subject: Re: [rtcweb] Confirmation of consensus on audio codecs

I also support the selection of OPUS and G.711 as MTI. G.722 can be a
SHOULD; it is widely supported.

[RS> ] +1

---

From: Monty Montgomery <[email-masked]>
Date: Thu, 16 Aug 2012 22:38:53 -0400

> SOOO WRONG .. just do a simple search.  It just hasn't been fully litigated

It hasn't been litigated at all. Or even credibly threatened beyond
the same substanceless mouthing off in to press we saw with Vorbis,
Theora, etc...

Monty
Xiph.Org

---

From: Matthew Kaufman <[email-masked]>
Date: Fri, 17 Aug 2012 16:30:46 +0000

I agree. OPUS because it will be the IETF standard for wideband audio on the Internet, G.711 for maximum interoperability. G.722 is a reasonable thing to put on the "SHOULD" list... there's some other good choices for the SHOULD list, but they unfortunately come with additional IPR issues.

Matthew Kaufman

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 17 Aug 2012 13:02:24 -0400

I'll chime in here too - it'll surprise no one that I agree Opus
should be MTI. I agree on G.711 as well, as this has realistically
been the lingua franca for voip since the very beginning. Its easy to
put in, no IPR and will help with the many interop scenarios which the
market will eventually want. Even if intermediaries are needed on the
media path for other things - like ICE interop - at least we won't
need transcode.

-Jonathan R.

-- 
Jonathan Rosenberg, Ph.D.
GM Product Strategy and Research, Microsoft/Skype
jdrosen@{skype.net,jdrosen.net,microsoft.com}
http://www.jdrosen.net

---

From: Ken Fischer <[email-masked]>
Date: Fri, 17 Aug 2012 11:46:56 -0600

+1 on Matthew's recommendation.  I agree that .722 should be on the
SHOULD list, but honestly I think most people who implement beyond the
MUST will add what ever they like, and what ever they have access to, and
so the ultimate impact of the SHOULDs has always been questionable to me.

Ken

On 8/17/12 10:30 AM, "Matthew Kaufman" <[email-masked]> wrote:

>I agree. OPUS because it will be the IETF standard for wideband audio on
>the Internet, G.711 for maximum interoperability. G.722 is a reasonable
>thing to put on the "SHOULD" list... there's some other good choices for
>the SHOULD list, but they unfortunately come with additional IPR issues.
>
>Matthew Kaufman
>

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Fri, 17 Aug 2012 16:05:13 -0400

+1 to Opus and G.711 being mandatory for audio.

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Fri, 17 Aug 2012 16:08:39 -0400

> SOOO WRONG .. just do a simple search.  It just hasn't been fully litigated
It's impossible for something to be fully litigated.  Even someone
licensing H.264 through MPEG-LA is liable to be sued, as Motorola has
taught us, and the promises from the cartel hold no guarantees for their
future.

The condition you are placing on VP8 is impossible to meet and falsely
assumed to apply to H.264.  What is real is that H.264 has a licensing
situation that excludes implementation in a free software context in
most places of the world that will use it, and VP8 does not.

Now, this is a discussion about the audio codecs, but FUD is FUD and
needs to be nipped in the bud.

---

From: Justin Uberti <[email-masked]>
Date: Fri, 17 Aug 2012 16:22:52 -0700

I agree that Opus and G.711 should be the MTI audio codecs for WebRTC.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 17 Aug 2012 17:43:56 -0600

Agreed (as long as by G.711 we mean both PCMA and PCMU).

On 8/17/12 5:22 PM, Justin Uberti wrote:
> On Thu, Aug 16, 2012 at 5:41 PM, Bernard Aboba 
> <[email-masked] <mailto:[email-masked]>>
> wrote:
> 
> On Aug 16, 2012, at 4:24 PM, "Richard Shockey" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>> Reading this list is occasionally an act of torture banned by
>> several conventions ..but since you ask.
>> 
>> I completely support the selection of Opus and G.711 as mandatory
>> to implement audio codec's ..however I'm very very open minded
>> about
> supporting
>> If it is your goal to create globally useful stove pipes fine,
>> but interconnection with existing carrier real time networks is
>> IMHO a
> rational
>> goal.
>> 
>> As for Video .. for goodness sakes just get over it people.
>> H.264
> is totally
>> I'll save my comments about the SDP offer/answer issue for
>> another
> day.
>> 
>> -----Original Message----- From: [email-masked]
>> <mailto:[email-masked]>
> [mailto:[email-masked] <mailto:[email-masked]>]
> On Behalf Of
>> Cullen Jennings (fluffy) Sent: Thursday, August 16, 2012 1:16 PM 
>> To: [email-masked] <mailto:[email-masked]> Subject: [rtcweb]
>> Confirmation of consensus on audio codecs
>> 
>> 
>> At the last meeting we took a hum on selecting Opus and G.711 as
>> the mediatory to implement audio codecs. If there is any new
>> opinions
> please
>> send them to the list by August 30th, after which the chairs
>> will
> make a
>> Thanks, Cullen
>> 2010-11-07 . ID # 1445 "Broadcom Corporation's Statement about
>> IPR related to draft-ietf-codec-opus-00 and
>> draft-ietf-codec-description-00 (1)" 2010-11-07 . ID # 1446 
>> draft-ietf-codec-opus-00" 2010-11-12 . ID # 1447 "Broadcom
>> Corporation's Statement about IPR related to 
>> draft-ietf-codec-opus-00 and draft-ietf-codec-description-00
>> (2)" 2011-03-23 . ID # 1520 "Qualcomm Incorporated's Statement
>> about IPR related to draft-ietf-codec-opus-05" 2011-03-27 . ID #
>> 1524 "Xiph.Org Foundation's Statement about IPR related to 
>> draft-ietf-codec-opus-05" 2011-03-29 . ID # 1526 "Broadcom
>> Corporation's Statement about IPR related to 
>> draft-ietf-codec-opus-05" 2011-03-29 . ID # 1525 "Skype Limited's
>> Statement about IPR related to
>> 2011-07-23 . ID # 1602 "Skype Limited's Statement about IPR
>> related to
> draft-ietf-codec-opus-07"
>> 2012-01-25 . ID # 1670 "Microsoft Corporation's Statement about
>> IPR related to draft-ietf-codec-opus-10" 2012-03-12 . ID # 1712 
>> draft-ietf-codec-opus-11 (1)" 2012-04-02 . ID # 1741 "Huawei
>> Technologies Co.,Ltd's Statement about IPR related to

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 18 Aug 2012 14:04:26 -0400

Even though 711 quality actually sucks. I only mention 722 ..AMR WB btw
since it's obvious that if you may want to interoperate with the several
billion mobile endpoints that may be deploying VoLTE over the next few
years. It might prove useful, unless this entire exercise is about creating
N squared silos. 

You are still going to have to define a MUST support video codec eventually
so just get on with it ..saying VP8 only is just unrealistic. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Rosenberg
Sent: Friday, August 17, 2012 1:02 PM
To: Matthew Kaufman
Cc: Cullen Jennings (fluffy); [email-masked]
Subject: Re: [rtcweb] Confirmation of consensus on audio codecs

I'll chime in here too - it'll surprise no one that I agree Opus should be
MTI. I agree on G.711 as well, as this has realistically been the lingua
franca for voip since the very beginning. Its easy to put in, no IPR and
will help with the many interop scenarios which the market will eventually
want. Even if intermediaries are needed on the media path for other things -
like ICE interop - at least we won't need transcode.

-Jonathan R.

the Internet, G.711 for maximum interoperability. G.722 is a reasonable
thing to put on the "SHOULD" list... there's some other good choices for the
SHOULD list, but they unfortunately come with additional IPR issues.

---

From: "Richard Shockey" <[email-masked]>
Date: Sat, 18 Aug 2012 14:12:01 -0400

Well nip on this for a while .. a simple search against "VP8 intellectual
property issues" brings up some interesting points.  It only takes one suit.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Basil Mohamed Gohar
Sent: Friday, August 17, 2012 4:09 PM
To: [email-masked]
Subject: Re: [rtcweb] Confirmation of consensus on audio codecs

On 08/16/2012 09:38 PM, Richard Shockey wrote:
> SOOO WRONG .. just do a simple search.  It just hasn't been fully 
> litigated ...yet.
It's impossible for something to be fully litigated.  Even someone licensing
H.264 through MPEG-LA is liable to be sued, as Motorola has taught us, and
the promises from the cartel hold no guarantees for their future.

The condition you are placing on VP8 is impossible to meet and falsely
assumed to apply to H.264.  What is real is that H.264 has a licensing
situation that excludes implementation in a free software context in most
places of the world that will use it, and VP8 does not.

Now, this is a discussion about the audio codecs, but FUD is FUD and needs
to be nipped in the bud.
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Silvia Pfeiffer <[email-masked]>
Date: Sun, 19 Aug 2012 12:20:52 +1000

On that search: did you also notice that it got amazingly quiet since July 2011?
S.

---

From: tom harper <[email-masked]>
Date: Sat, 18 Aug 2012 19:29:20 -0700

I strongly support having 722 as mandatory - interop in the enterprise 
will greatly benefit.

Opus and g.711 are +1

Tom

---

From: <[email-masked]>
Date: Tue, 21 Aug 2012 07:57:49 +0000

For voice and multimedia communication services as targeted by WebRTC, two codecs, G.711 and G.722, are fully fitting the conditions to get a mandatory to implement status: a fully ensured unencumbered status, a wide implementation in devices and legacy networks and a low complexity that ensures they can be supported on any types of plate-forms and terminals.

So we support both G.711 and G.722 to be specified as "mandatory to implement" codecs since G.722 will guarantee a much higher voice quality at same bit rate and almost no additional cost. At a minimum G.722 should be (strongly) recommended.

With respect to OPUS, it has currently no footprint on the market, its implementation complexity and resulting costs are unknown, including with respect to IPRs issues, and some performance aspects are still to be more deeply assessed, like for instance quality with packet losses and jitter which is a key issue for usage over internet. 

In addition, we believe that two additional requirements are necessary to make WebRTC a future proof technology and suitable for a wide range of applications and environments:
Firstly, the optional support of other widely deployed legacy codecs must be allowed which includes at least the codecs implemented in millions of mobile terminals: AMR and AMR-WB.
Secondly, the technology must be open enough to facilitate the usage of any other codecs supported by the device but external to the browser.

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Cullen Jennings (fluffy)
Envoyé : jeudi 16 août 2012 19:16
À : [email-masked]
Objet : [rtcweb] Confirmation of consensus on audio codecs

Thanks,
Cullen

2010-11-07	
. ID # 1445

_________________________________________________________________________________________________________________________

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: Randell Jesup <[email-masked]>
Date: Tue, 21 Aug 2012 11:02:23 -0400

> So we support both G.711 and G.722 to be specified as "mandatory to implement" codecs since G.722 will guarantee a much higher voice quality at same bit rate and almost no additional cost. At a min…

I agree G.722 should be a "SHOULD".

Note I said "I".  While in reality corporations and organizations that 
IETF contributors are associated with have opinions on IETF activities, 
officially IETF recognizes individuals as contributors.

> With respect to OPUS, it has currently no footprint on the market, its implementation complexity and resulting costs are unknown, including with respect to IPRs issues, and some performance aspects…

Opus was designed within the IETF specifically to handle usage over the 
Internet better than existing codecs.

> Firstly, the optional support of other widely deployed legacy codecs must be allowed which includes at least the codecs implemented in millions of mobile terminals: AMR and AMR-WB.

The spec does not restrict what codecs can be supported beyond the MTI 
codecs.  You can offer any codecs you support.

> Secondly, the technology must be open enough to facilitate the usage of any other codecs supported by the device but external to the browser.

This is an implementation detail for browsers and not part of the spec; 
a browser is free to offer any codecs supported by the platform if it 
wishes.

-- 
Randell Jesup
[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Tue, 21 Aug 2012 08:35:09 -0700

> Secondly, the technology must be open enough to facilitate the usage of any other codecs supported by the device but external to the browser.
 Stephane,

On you first point, the fundamental design of RTCWEB allows for the
negotiation of any codec mutually supported.  The decision to chose a
Mandatory-to-implement was not made to eliminate other choices, but to
eliminate interoperability failures by ensuring that at least one
common codec is always available.

On your second point, the group presumes that codec support does not
come from the downloadable Javascript application, but from the
application environment into which it is downloaded (commonly a
browser or mobile environment using similar technology).  Promoting
support for those environments to have access to codecs supported by
the underlying hardware is the best way to further this goal, at least
in my personal opinion.

best regards,

Ted Hardie

---

From: Lishitao <[email-masked]>
Date: Fri, 24 Aug 2012 04:10:45 +0000

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Randell Jesup
> Sent: Tuesday, August 21, 2012 11:02 PM
> To: [email-masked]
> > With respect to OPUS, it has currently no footprint on the market, its
> implementation complexity and resulting costs are unknown, including with
> respect to IPRs issues, and some performance aspects are still to be more
> deeply assessed, like for instance quality with packet losses and jitter which is a
> key issue for usage over internet.
> 

My understanding for choosing the MTI codec is to find the baseline so that the negotiation can be successful, 
We are not here to find the best one.

If we consider the situation that G.711 has been widely used on the market, mandating G.711 only as the baseline(MTI) is more appropriate

shitao.

---

From: Neil Stratford <[email-masked]>
Date: Fri, 24 Aug 2012 07:52:50 +0100

> If we consider the situation that G.711 has been widely used on the market, mandating G.711 only as the baseline(MTI) is more appropriate

This should not be a question purely of interop with legacy devices,
but primarily one about what is the minimum level of interop that is
acceptable for WebRTC to WebRTC negotiated calls.

If G711 is the only MTI codec then we can easily end up in a situation
where that is all we have available for cross browser WebRTC to WebRTC
calls, which would greatly undermine the effort to replace browser
plugins.

Neil

---

From: Stefan Hakansson LK <[email-masked]>
Date: Tue, 28 Aug 2012 14:36:34 +0200

On 08/16/2012 07:15 PM, Cullen Jennings (fluffy) wrote:
> mediatory to implement audio codecs. If there is any new opinions
> please send them to the list by August 30th, after which the chairs
> will make a determination of consensus.

As much as I would like to say "I agree", I come to the conclusion it is 
not that simple.

I have two things that concern me:

* "Opus" not well enough defined
* Opus not mature and proven enough (this is the more important concern)

Lets talk about both of these.

"Opus" not well enough defined
==============================
Just saying "Opus" is a bit vague for me (who has not been in the codec
WG). Is a certain version meant? Which one? Or is it a moving target
(i.e. always implement the latest version)?

What is included (is jitter management, loss concealment part of Opus or 
something that is up to the implementation)?

And how is it judged what is a compliant implementation? Is there a ref
implementation that you test against? How do you test? Are there
test-vectors that must be conformed to? Or is "Opus" standardized as a
wire format (meaning that any implementation that can produce/decode
that wire format is compliant)? If the latter is true, implementers have 
more wiggle room to e.g. reduce complexity or design around IPRs
(submarine IPRs may surface). Are implementors required to support all
aspects of Opus, or are there sub-sets/profiles that would be sufficient 
(perhaps for certain classes of devices)? [1] suggests that not all 
ptime options need to be supported, but are there others things?

Many of the answers are probably available, but I think they should be
put in front of the WG before making this decision.

Opus not mature and proven enough
=================================
As far as I understand, Opus is a brand new standard. There are
implementations on-going, but yet no deployment, no experience from real 
world use (and definitely not from use in larger scale over a wide range 
of conditions, involving a broad range of end user devices). In
addition, I've been told that so far Opus has gone through less
characterization tests than codecs usually are put through.

I don't think it is fair to mandate the implementation of a codec (which 
is a large and complex piece) under these circumstances. Some real 
deployment (involving many device types) and experience (including
operation in different conditions) should be gained before doing so. It
could also be argued that there is a bigger risk from a licensing
perspective to mandate a codec that has not been in use.

Do I mean we should mandate just G.711?
=======================================
No, not necessarily. Looking ahead, I am convinced that new and improved 
codecs for audio and video will be introduced as they become available. 
There is a logic in adopting technology that reduces the transmitted 
number of bits and enhances the end user experience, and the WG is 
designing a solution that enables new codecs to be introduced and used 
(and I really hope they can be made use of even if the applications is 
untouched) IIUC. However, if G.711 would be the only MTI audio codec, 
services that expect audio BW that goes beyond narrowband could suffer 
since there is no guarantee that there is any other codec than G.711 
supported by both endpoints.

In addition G.711 is not that well suited for for challenging network 
conditions (the most important parts like packet loss concealment and 
jitter management depends on the implementation - or are we going to 
standardize those parts?; what I am after is that it is unable to lower 
the send rate as reaction to congestion - the only method available is 
to use longer frames to make the IP header overhead lower).

I see three possible ways forward:

a) Mandate G.711 only, and let the market decide if there will be a
universally available codec giving higher quality.

b) Postpone the decision for some time. Let Opus (and other new codecs
if such are introduced) get deployed, tested, perhaps improved. The
drawback with this approach is that the selection is delayed. If this
approach is chosen, I would also recommend that the WG spends some time
on selection criteria. In the presentation given in Vancouver ([2]) six
criteria were used (three of them considered more important). I think
they make sense, but can't remember we actually discussed them (or what
other criteria that may make sense).

c) Mandate some other codec (that is already deployed and in use).

Of these approaches, perhaps b) is the most reasonable one.

Stefan

[1] http://datatracker.ietf.org/doc/draft-cbran-rtcweb-codec/?include_text=1
[2] http://www.ietf.org/proceedings/84/slides/slides-84-rtcweb-6.pdf

> 2010-11-07 • ID # 1445 "Broadcom Corporation's Statement about IPR
> related to draft-ietf-codec-opus-00 and
> draft-ietf-codec-description-00 (1)" 2010-11-07 • ID # 1446 "Xiph.Org
> Foundation's Statement about IPR related to
> draft-ietf-codec-opus-00" 2010-11-12 • ID # 1447 "Broadcom
> Corporation's Statement about IPR related to draft-ietf-codec-opus-00
> and draft-ietf-codec-description-00 (2)" 2011-03-23 • ID # 1520
> draft-ietf-codec-opus-05" 2011-03-27 • ID # 1524 "Xiph.Org
> Foundation's Statement about IPR related to
> draft-ietf-codec-opus-05" 2011-03-29 • ID # 1526 "Broadcom
> draft-ietf-codec-opus-05" 2011-03-29 • ID # 1525 "Skype Limited's
> Statement about IPR related to draft-ietf-codec-opus-05" 2011-07-23 •
> ID # 1602 "Skype Limited's Statement about IPR related to
> draft-ietf-codec-opus-07" 2012-01-25 • ID # 1670 "Microsoft
> draft-ietf-codec-opus-10" 2012-03-12 • ID # 1712 "Huawei Technologies
> Co.,Ltd's Statement about IPR related to draft-ietf-codec-opus-11
> (1)" 2012-04-02 • ID # 1741 "Huawei Technologies Co.,Ltd's Statement
> about IPR related to draft-ietf-codec-opus-11 (2)"
>
>
>
> _______________________________________________ rtcweb mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 28 Aug 2012 12:30:28 -0400

On 08/28/2012 08:36 AM, Stefan Hakansson LK wrote:
> "Opus" not well enough defined ============================== Just
> saying "Opus" is a bit vague for me (who has not been in the codec 
> WG). Is a certain version meant? Which one? Or is it a moving
> target (i.e. always implement the latest version)?

The exact implementation (or version of that implementation) does not
matter as long as the implementation is compliant with (upcoming) RFC
6716.

> What is included (is jitter management, loss concealment part of
> Opus or something that is up to the implementation)?

The jitter buffer is not part of Opus, nor is it part of any other
codec I know of. As for loss concealment, the Opus reference
implementation proposes one, but implementers can choose what they
want because there is no interoperability issue with
changing/improving loss concealment.

> And how is it judged what is a compliant implementation? Is there a
> ref implementation that you test against? How do you test? Are
> there test-vectors that must be conformed to? Or is "Opus"
> standardized as a wire format (meaning that any implementation that
> can produce/decode that wire format is compliant)? If the latter is
> true, implementers have more wiggle room to e.g. reduce complexity
> or design around IPRs (submarine IPRs may surface).

The text in the upcoming RFC 6716 is very clear that only the decoder
is standardized. This is similar to how codecs like MP3 and AAC are
defined. We also provide a set of test vectors, along with a program
that evaluates the decoded output to determine whether the decoder
under test is compliant.

> ================================= As far as I understand, Opus is a
> brand new standard. There are implementations on-going, but yet no
> deployment, no experience from real world use (and definitely not
> from use in larger scale over a wide range of conditions, involving
> a broad range of end user devices).

So far, Opus has been deployed in Firefox, GStreamer, FFMpeg,
Foobar2000, and a few other applications. This is far more deployment
than any ITU-T/MPEG codec has had by the time of standardization. Not
only that, but some of the underlying technology has been in use for
years now. The original SILK codec (not compatible with Opus but
having a lot in common) has been in Skype for about 3 years, while
CELT (again, not compatible but sharing a lot of technology) has been
deployed in many applications in the past 3 years, including Mumble,
which has about half a million users worldwide.

> In addition, I've been told that so far Opus has gone through less 

When it comes to testing, I recommend reading
http://tools.ietf.org/html/draft-valin-codec-results-00 which
summarizes the listening tests that were done on Opus. Also, I
recommend reading
https://www.ietf.org/proceedings/82/slides/codec-4.pdf
This describes a whole series of tests we did that other SDOs
generally don't do on their codecs.

> I don't think it is fair to mandate the implementation of a codec
> (which is a large and complex piece) under these circumstances.

Well, compared to the rest of webrtc, I find that Opus is so small,
simple and well-defined :-)

Cheers,

	Jean-Marc

---

From: Paul Coverdale <[email-masked]>
Date: Tue, 28 Aug 2012 14:47:03 -0400

>http://tools.ietf.org/html/draft-valin-codec-results-00 which summarizes
>the listening tests that were done on Opus. Also, I recommend reading
>This describes a whole series of tests we did that other SDOs generally
>don't do on their codecs.
>

I think that Stefan was referring to the lack of formal, controlled,
characterization tests carried out on Opus, which typically ARE carried out
on codecs in other SDOs before approval. 

...Paul

---

From: <[email-masked]>
Date: Tue, 28 Aug 2012 19:11:05 +0000

Hi Stefan,

I very much share your views and would like to support especially this option:

>b) Postpone the decision for some time. Let Opus (and other new codecs if
>such are introduced) get deployed, tested, perhaps improved. The drawback
>with this approach is that the selection is delayed. If this approach is chosen, I
>would also recommend that the WG spends some time on selection criteria.
>In the presentation given in Vancouver ([2]) six criteria were used (three of
>them considered more important). I think they make sense, but can't
>remember we actually discussed them (or what other criteria that may make
>sense).

It is always nice to get decisions done early on. However, I don't think that leaving the mandatory-to-implement codecs (for either WB audio or video) open at this point will yet seriously impact the deployment or interoperability of WebRTC. There are still many other things to tackle. We should revisit the codec issue when all the other critical things are in a good shape. 

I'll post a separate mail on my views shortly.

Markus

>Of ext Stefan Hakansson LK
>Sent: 28 August, 2012 15:37
>To: [email-masked]
>As much as I would like to say "I agree", I come to the conclusion it is not that
>simple.
>
>Just saying "Opus" is a bit vague for me (who has not been in the codec WG).
>Is a certain version meant? Which one? Or is it a moving target (i.e. always
>implement the latest version)?
>
>implementation that you test against? How do you test? Are there test-
>vectors that must be conformed to? Or is "Opus" standardized as a wire
>format (meaning that any implementation that can produce/decode that wire
>format is compliant)? If the latter is true, implementers have more wiggle
>room to e.g. reduce complexity or design around IPRs (submarine IPRs may
>surface). Are implementors required to support all aspects of Opus, or are
>there sub-sets/profiles that would be sufficient (perhaps for certain classes of
>devices)? [1] suggests that not all ptime options need to be supported, but
>are there others things?
>
>Many of the answers are probably available, but I think they should be put in
>front of the WG before making this decision.
>
>world use (and definitely not from use in larger scale over a wide range of
>conditions, involving a broad range of end user devices). In addition, I've been
>told that so far Opus has gone through less characterization tests than codecs
>usually are put through.
>
>I don't think it is fair to mandate the implementation of a codec (which is a
>large and complex piece) under these circumstances. Some real deployment
>(involving many device types) and experience (including operation in different
>conditions) should be gained before doing so. It could also be argued that
>there is a bigger risk from a licensing perspective to mandate a codec that has
>not been in use.
>
>
>There is a logic in adopting technology that reduces the transmitted number
>of bits and enhances the end user experience, and the WG is designing a
>solution that enables new codecs to be introduced and used (and I really hope
>they can be made use of even if the applications is
>In addition G.711 is not that well suited for for challenging network conditions
>(the most important parts like packet loss concealment and jitter
>management depends on the implementation - or are we going to
>standardize those parts?; what I am after is that it is unable to lower the send
>rate as reaction to congestion - the only method available is to use longer
>frames to make the IP header overhead lower).
>
>a) Mandate G.711 only, and let the market decide if there will be a universally
>available codec giving higher quality.
>
>b) Postpone the decision for some time. Let Opus (and other new codecs if
>such are introduced) get deployed, tested, perhaps improved. The drawback
>with this approach is that the selection is delayed. If this approach is chosen, I
>would also recommend that the WG spends some time on selection criteria.
>In the presentation given in Vancouver ([2]) six criteria were used (three of
>them considered more important). I think they make sense, but can't
>remember we actually discussed them (or what other criteria that may make
>sense).
>
>> 2010-11-07 * ID # 1445 "Broadcom Corporation's Statement about IPR
>> draft-ietf-codec-description-00 (1)" 2010-11-07 * ID # 1446 "Xiph.Org
>> Foundation's Statement about IPR related to draft-ietf-codec-opus-00"
>> 2010-11-12 * ID # 1447 "Broadcom Corporation's Statement about IPR
>> draft-ietf-codec-description-00 (2)" 2011-03-23 * ID # 1520 "Qualcomm
>> Incorporated's Statement about IPR related to
>> draft-ietf-codec-opus-05" 2011-03-27 * ID # 1524 "Xiph.Org
>> Foundation's Statement about IPR related to draft-ietf-codec-opus-05"
>> 2011-03-29 * ID # 1526 "Broadcom Corporation's Statement about IPR
>> related to draft-ietf-codec-opus-05" 2011-03-29 * ID # 1525 "Skype
>> Limited's Statement about IPR related to draft-ietf-codec-opus-05"
>> 2011-07-23 * ID # 1602 "Skype Limited's Statement about IPR related to
>> draft-ietf-codec-opus-07" 2012-01-25 * ID # 1670 "Microsoft
>> Corporation's Statement about IPR related to draft-ietf-codec-opus-10"
>> 2012-03-12 * ID # 1712 "Huawei Technologies Co.,Ltd's Statement about
>> IPR related to draft-ietf-codec-opus-11 (1)" 2012-04-02 * ID # 1741

---

From: <[email-masked]>
Date: Tue, 28 Aug 2012 19:26:24 +0000

Hi,

I'm having here both my individual thoughs and I'm also conveying the views of Nokia in more general. 

(as individual)

First of all, my feeling is that we may be trying to make the codec decisions pre-maturely. Codecs are after all a negotiable and well understood component in RTCWeb. There are more critical things to get right to ensure interoperability and success of RTCWeb. By my judgement it will take at least one more year to deliver them in IETF or W3C. So I believe we still have time to make the final call about codecs even for the "1.0" version. With new codecs such as Opus one more year may bring more information about its quality, IPR status and so on.

Many people in the WG seem to consider unencumberment of codecs as essential. Opus does have several non-RF declarations on it, and there are many players who have not taken part in the IETF Codec WG and thus have no disclosure obligation on their potential IPR. So if the WG wants to mandate a wideband codec at this point, it seems to me that G.722 is the logical choice. (Opus is more efficient and if it indeed will enjoy RF status, I'm sure it will become the "de facto" RTCWeb codec in many environments.)

So, in summary, I think the WG should either not fix the mandatory codecs yet, or if that for some reason needs to be done right now, the MTI audio codecs should be G.711 and G.722.  

(speaking for Nokia)

Nokia thinks that there are complexity issues with the Opus codec. There are also possible IPR risks associated with the "royalty-free" nature of Opus. We do not recommend Opus to be taken as a mandatory codec for RTCWeb at this point. From high quality low bit rate and mobile applications point of view the 3GPP AMR-WB codec (also known as ITU-T G.722.2) is the most preferable for us. For interoperability with implementations restricted to unencumbered codecs, we prefer G.711 and G.722. 

Regards,
	Markus

>Of ext Cullen Jennings (fluffy)
>Sent: 16 August, 2012 20:16
>To: [email-masked]
>* ID # 1445
>"Broadcom Corporation's Statement about IPR related to draft-ietf-codec-
>opus-00 and draft-ietf-codec-description-00 (1)"
>2010-11-07
>* ID # 1446
>* ID # 1447
>"Broadcom Corporation's Statement about IPR related to draft-ietf-codec-
>opus-00 and draft-ietf-codec-description-00 (2)"
>2011-03-23
>* ID # 1520
>* ID # 1524
>* ID # 1526
>* ID # 1525
>* ID # 1602
>* ID # 1670
>* ID # 1712
>* ID # 1741

---

From: Stefan Hakansson LK <[email-masked]>
Date: Tue, 28 Aug 2012 23:41:46 +0200

On 08/28/2012 09:26 PM, [email-masked] wrote:

> So, in summary, I think the WG should either not fix the mandatory
> codecs yet, or if that for some reason needs to be done right now,
> the MTI audio codecs should be G.711 and G.722.
I agree, there seem to be no reason why this must be decided right now, 
but if it must be G.711 and .722 are logical choices.

---

From: Lishitao <[email-masked]>
Date: Wed, 29 Aug 2012 01:24:33 +0000

Hi all

Both as individual and HUAWEI's point of view,

We support this option, G.711 and G.722 (or G.711 only) are the best choices to be MTI at this moment.

shitao

> Of Stefan Hakansson LK
> Sent: Wednesday, August 29, 2012 5:42 AM
> To: [email-masked]

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 29 Aug 2012 08:33:30 +0200

> Both as individual and HUAWEI's point of view,
PLEASE. In the IETF we're all individuals. A company's point of view does not matter here. 
I don't see the point of any more companies adding their "point of view".

Thanks.

/O

And that's Edvina's point of view too ;-)

---

From: Stefan Hakansson LK <[email-masked]>
Date: Wed, 29 Aug 2012 11:51:09 +0200

On 08/28/2012 06:30 PM, Jean-Marc Valin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
Jean-Marc,

the info above goes a long way in answering my questions, thanks. I 
don't know the exact rules for IPR statements so I would like to double 
check: the fact that the RFC only defines the decoder, does that mean 
that there can be IPRs known by people in the codec WG that are not 
declared since they would apply to the encoder only (then there is the 
risk of IPRs held by those who have not participated in codec WG)?

Another question I had was if Opus is atomic, or if you can implement 
different profiles, and if so what parts should be MTI for rtcweb (and 
should the profile that is MTI be the same regardless of the device type 
- there has been issues raised regarding complexity?).

> than any ITU-T/MPEG codec has had by the time of standardization.

That is great, but sort of underlines that there would be no harm in 
delaying the decision until there are experiences made from real world 
use - 'cause it would not be that long till that experience has been 
made (Markus also brought up the IPR status as a reason for waiting - I 
have no idea how long it would take to know more about that).

> Not

As Paul suggested, I was referring to the lack of formal, controlled,
characterization tests. That is how other SDOs do it. I don't think that 
is the only way to do it, but I think we should at least have either 
such tests conducted or experience from deployment and use (in a wide 
range of conditions and device types) before making it MTI.

> simple and well-defined :-)

Especially if you draw a diagram with all the signaling paths, all 
components involved, and then make a small box for "codec" (or Opus) :-)

>
> Cheers,
>
> 	Jean-Marc
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJQPPIhAAoJEJ6/8sItn9q93vYH/1Q6/dW3ZTkIsMu8y9GOLLNK
> Agyp8cyfmAREgjP5w5LZw0rmAMGfiPiWKuv7lvTgpivR3HOQbuhnMw9vdQEUJEPw
> xLHpj5SmZMggA8LFNPcWcmztkUcTnEfKCxPcdFPhA2i3b2cBR/L1b4oLRkUY706c
> p/EaBVIvOe7Uk54o13V0S671LaaJlX7qGY5Asf3BWLZlGB5xspwtOJvpQ+C6NiTD
> 94vPId9xKv1BlGIXPbWnUOb3sIAuegGbjkuM36m7DxqVH+zEiXBs8BIDDFdDVSV3
> iatsJSeRb1E11/RSEoPjQQE2oiP3R+K2jZhEZeLSfdY75mpAjE11qqfDQMUUCo0=
> =Otiw
> -----END PGP SIGNATURE-----
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 29 Aug 2012 12:21:53 +0200

Since the number of people stating their opinion has been large, I'll 
just reiterate the opinion I had (and hummed for) in Vancouver:

Opus and G.711 should be mandatory to implement for RTCWEB.

Since the question of whether there's any value to making the decision 
now has been raised:

The first interoperable products implementing RTCWEB are shipping within 
a very short timeframe. Those first implementations will shape the 
market for what's actually used in practice.
In order to allow applications requiring high quality sound to be among 
the first ones developed, those first products need to include a common 
choice of a high quality codec.

Having the RTCWEB WG state as a decision that this codec should be Opus 
helps in making sure these products ship with Opus.

The time to decide is now.

                   Harald

[Note - the same logic applies to video codecs, but I've accepted that 
it's impossible to make a consensus decision at this time on that issue. 
We'll just live with the consequences of that.]

---

From: <[email-masked]>
Date: Wed, 29 Aug 2012 10:23:07 +0000

Hi,

>I don't see the point of any more companies adding their "point of view".

I think it's useful to know if companies do have opinions in certain topics. Many browsers, codecs and other RTCWeb related implementations are going to happen or not happen based on company decisions. IMHO, more information is better than less. The main point continues to be that all opinions should be backed by solid technical arguments before they become relevant.

Markus

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 29 Aug 2012 08:15:31 -0400

> (speaking for Nokia)
> 
> Nokia thinks that there are complexity issues with the Opus codec.
> There are also possible IPR risks associated with the "royalty-free"
> nature of Opus. We do not recommend Opus to be taken as a mandatory
> codec for RTCWeb at this point. From high quality low bit rate and
> mobile applications point of view the 3GPP AMR-WB codec (also known
> as ITU-T G.722.2) is the most preferable for us. For interoperability
> with implementations restricted to unencumbered codecs, we prefer
> G.711 and G.722.

Sorry, but I think G.722 (or AMR-WB) is just not enough. Speech-only, AM
radio quality is not what we need here. Skype has been shipping a
super-wideband codec for about 3 years now, so going back to wideband as
the highest guaranteed interoperability would make webrtc irrelevant.
Let's look at the options here. On one side we have Opus, that can
easily handle all possible rtcweb applications because it does
narrowband, wideband, super-wideband and fullband, can handle both
speech and music, and scales to high-quality stereo (for music
applications). On the other side, if you want the same functionality,
you would need at least the following codecs: AMR-NB, AMR-WB, G.722.1C,
AAC-LD, HE-AAC, and AAC-LC. And on top of the insane IPR cost of
shipping these 6 codecs, you end up with an inflexible solution (hard to
switch between 6 codecs in real-time based on the network bandwidth),
with slightly lower quality, and that in practice nobody would fully
implement.

	Jean-Marc

---

From: Jean-Marc Valin <[email-masked]>
Date: Wed, 29 Aug 2012 09:10:57 -0400

On 08/29/2012 05:51 AM, Stefan Hakansson LK wrote:
> the info above goes a long way in answering my questions, thanks.
> I don't know the exact rules for IPR statements so I would like to
> double check: the fact that the RFC only defines the decoder, does
> that mean that there can be IPRs known by people in the codec WG
> that are not declared since they would apply to the encoder only
> (then there is the risk of IPRs held by those who have not
> participated in codec WG)?

The RFC includes and describes both the encoder and the decoder. What
I was saying is that only the decoder was described normatively, while
the encoder was allowed to change. So the IPR rules apply to both the
encoder and the decoder.

> Another question I had was if Opus is atomic, or if you can
> implement different profiles, and if so what parts should be MTI
> for rtcweb (and should the profile that is MTI be the same
> regardless of the device type - there has been issues raised
> regarding complexity?).

Opus does not have profiles. That's what ensures that any Opus
bitstream can be decoded by any compliant decoder. And that can happen
*before* the decoder has even seen the SDP.

> That is great, but sort of underlines that there would be no harm
> in delaying the decision until there are experiences made from real
> world use - 'cause it would not be that long till that experience
> has been made (Markus also brought up the IPR status as a reason
> for waiting - I have no idea how long it would take to know more
> about that).

As Harald is pointing out, rtcweb implementations are going to ship
pretty soon. I don't see a reason to postpone decisions that can be
made now. Are you expecting *another* single, standardized,
royalty-free codec that operates over vast ranges of bitrates and
operating conditions, from narrowband speech to stereo music, all with
low delay, coming out in the next year? If not, what are you really
waiting for?

> As Paul suggested, I was referring to the lack of formal,
> controlled, characterization tests. That is how other SDOs do it. I
> don't think that is the only way to do it, but I think we should at
> least have either such tests conducted or experience from
> deployment and use (in a wide range of conditions and device types)
> before making it MTI.

Opus has had "ITU-style" testing on English (
http://www.opus-codec.org/comparison/GoogleTest1.pdf ) and Mandarin (
http://www.opus-codec.org/comparison/GoogleTest2.pdf ). And if you
don't trust Google on the tests I linked to, it's also been tested by
Nokia:
http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_Quality_Characterization_of_IETF_Opus_Codec.pdf

Now, unlike other SDOs, the testing did not stop there. ITU-T codecs
generally end up being testing with something in the order of tens of
minutes worth of audio. In *addition* to that kind of testing, Opus
also had automated testing with hundreds of years worth of audio. If
anything, I think other SDOs should learn something here.

	Jean-Marc

---

From: <[email-masked]>
Date: Wed, 29 Aug 2012 16:01:10 +0200

The mandatory-to implement (MTI) codec for rtcweb should ensure interoperability and good quality. 
It should be possible to implement the codec without hurdles.

The G.722 provides wideband quality at 64 kbit/s. It is easy to implement and causes no additional costs.
Hence G.722 should be a MTI codec for rtcweb. 
It provides also interoperability to other voice communication services.

For interoperability reasons to other voice communication services G.711 should be a MTI codec for rtcweb. 
It provides only narrow-band quality. But it is easy to implement and causes no additional costs.
 
For interoperability reasons to other voice communication services  AMR and AMR-WB should be supported.
As these codecs are not that easy to implement and may cause additional costs, they should not be MTI codecs for rtcweb.
If rtcweb is used for calls to mobile phones, it is likely that these codecs will be supported as this guarantees the best quality. 
  
Other  low bitrate codec may be supported , but should not be MTI codec for rtcweb. The codecs cause additional hurdles. Interoperability is already guaranteed by the MTI codecs. The implementer can decide on its own to support the codec.  

Best regards,
Bernhard

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cullen Jennings (fluffy)
Sent: Donnerstag, 16. August 2012 19:16
To: [email-masked]
Subject: [rtcweb] Confirmation of consensus on audio codecs

Thanks,
Cullen

2010-11-07	
* ID # 1445

---

From: "Mandyam, Giridhar" <[email-masked]>
Date: Wed, 29 Aug 2012 14:30:53 +0000

I support a) below.  This will allow us to gain operational experience with various codecs, and an update to the RTCWeb specifications can later mandate additional codecs as needed.

-Giri Mandyam

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Hakansson LK
Sent: Tuesday, August 28, 2012 5:37 AM
To: [email-masked]
Subject: Re: [rtcweb] Confirmation of consensus on audio codecs

> will make a determination of consensus.

As much as I would like to say "I agree", I come to the conclusion it is not that simple.

"Opus" not well enough defined
==============================
Just saying "Opus" is a bit vague for me (who has not been in the codec WG). Is a certain version meant? Which one? Or is it a moving target (i.e. always implement the latest version)?

What is included (is jitter management, loss concealment part of Opus or something that is up to the implementation)?

And how is it judged what is a compliant implementation? Is there a ref implementation that you test against? How do you test? Are there test-vectors that must be conformed to? Or is "Opus" standardized as a wire format (meaning that any implementation that can produce/decode that wire format is compliant)? If the latter is true, implementers have more wiggle room to e.g. reduce complexity or design around IPRs (submarine IPRs may surface). Are implementors required to support all aspects of Opus, or are there sub-sets/profiles that would be sufficient (perhaps for certain classes of devices)? [1] suggests that not all ptime options need to be supported, but are there others things?

Many of the answers are probably available, but I think they should be put in front of the WG before making this decision.

Opus not mature and proven enough
=================================
As far as I understand, Opus is a brand new standard. There are implementations on-going, but yet no deployment, no experience from real world use (and definitely not from use in larger scale over a wide range of conditions, involving a broad range of end user devices). In addition, I've been told that so far Opus has gone through less characterization tests than codecs usually are put through.

I don't think it is fair to mandate the implementation of a codec (which is a large and complex piece) under these circumstances. Some real deployment (involving many device types) and experience (including operation in different conditions) should be gained before doing so. It could also be argued that there is a bigger risk from a licensing perspective to mandate a codec that has not been in use.

Do I mean we should mandate just G.711?
=======================================
No, not necessarily. Looking ahead, I am convinced that new and improved codecs for audio and video will be introduced as they become available. 
There is a logic in adopting technology that reduces the transmitted number of bits and enhances the end user experience, and the WG is designing a solution that enables new codecs to be introduced and used (and I really hope they can be made use of even if the applications is
untouched) IIUC. However, if G.711 would be the only MTI audio codec, services that expect audio BW that goes beyond narrowband could suffer since there is no guarantee that there is any other codec than G.711 supported by both endpoints.

In addition G.711 is not that well suited for for challenging network conditions (the most important parts like packet loss concealment and jitter management depends on the implementation - or are we going to standardize those parts?; what I am after is that it is unable to lower the send rate as reaction to congestion - the only method available is to use longer frames to make the IP header overhead lower).

a) Mandate G.711 only, and let the market decide if there will be a universally available codec giving higher quality.

b) Postpone the decision for some time. Let Opus (and other new codecs if such are introduced) get deployed, tested, perhaps improved. The drawback with this approach is that the selection is delayed. If this approach is chosen, I would also recommend that the WG spends some time on selection criteria. In the presentation given in Vancouver ([2]) six criteria were used (three of them considered more important). I think they make sense, but can't remember we actually discussed them (or what other criteria that may make sense).

Stefan

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Wed, 29 Aug 2012 07:48:34 -0700

I support the selection of Opus and G.711 as mandatory.

On 08/16/2012 10:15 AM, Cullen Jennings (fluffy) wrote:
> 2010-11-07 • ID # 1445 "Broadcom Corporation's Statement about IPR related
> to draft-ietf-codec-opus-00 and draft-ietf-codec-description-00 (1)"
> 2010-11-07 • ID # 1446 "Xiph.Org Foundation's Statement about IPR related
> to draft-ietf-codec-opus-00" 2010-11-12 • ID # 1447 "Broadcom
> Corporation's Statement about IPR related to draft-ietf-codec-opus-00 and 
> draft-ietf-codec-description-00 (2)" 2011-03-23 • ID # 1520 "Qualcomm 
> Incorporated's Statement about IPR related to draft-ietf-codec-opus-05" 
> 2011-03-27 • ID # 1524 "Xiph.Org Foundation's Statement about IPR related
> to draft-ietf-codec-opus-05" 2011-03-29 • ID # 1526 "Broadcom
> Corporation's Statement about IPR related to draft-ietf-codec-opus-05"
> 2011-03-29 • ID # 1525 "Skype Limited's Statement about IPR related to 
> draft-ietf-codec-opus-05" 2011-07-23 • ID # 1602 "Skype Limited's
> Statement about IPR related to draft-ietf-codec-opus-07" 2012-01-25 • ID #
> 1670 "Microsoft Corporation's Statement about IPR related to 
> Co.,Ltd's Statement about IPR related to draft-ietf-codec-opus-11 (1)" 
> 2012-04-02 • ID # 1741 "Huawei Technologies Co.,Ltd's Statement about IPR 
> related to draft-ietf-codec-opus-11 (2)"
> 

- -- 
Marc Petit-Huguenin
Email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org
Profile: http://www.linkedin.com/in/petithug

---

From: Randell Jesup <[email-masked]>
Date: Wed, 29 Aug 2012 11:24:18 -0400

I support the selection of Opus and G.711 and MTI codecs (as I did in 
the room, even though I officially proposed Opus only as an option to 
vote on).

I suggest anyone considering suggesting G.711 to examine the slides from 
Tim's presentation, and if possible watch that section of the video or 
listen to the audio (which I assume are online).  It wasn't an accident 
that the vote in-room (and there were a LOT of people) was basically 
"Opus only: ~5 votes; G.711 only: 0 or 1 votes; rest of the room: Opus 
and G.711"

-- 
Randell Jesup
[email-masked]

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 29 Aug 2012 09:39:47 -0600

On 8/29/12 9:24 AM, Randell Jesup wrote:
> I support the selection of Opus and G.711 and MTI codecs (as I did
> in the room, even though I officially proposed Opus only as an
> option to vote on).

Yes, that seems like the most reasonable approach. I plan to push for
an update to XEP-0266 ("Codecs for Jingle Audio") to align XMPP/Jingle
here (we were waiting for draft-ietf-codec-opus to be approved by the
IESG).

Peter

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

---

From: Basil Mohamed Gohar <[email-masked]>
Date: Wed, 29 Aug 2012 12:40:34 -0400

On 08/29/2012 11:24 AM, Randell Jesup wrote:
> I suggest anyone considering suggesting G.711 to examine the slides
> from Tim's presentation, and if possible watch that section of the
> video or listen to the audio (which I assume are online).  It wasn't
> an accident that the vote in-room (and there were a LOT of people) was
> basically "Opus only: ~5 votes; G.711 only: 0 or 1 votes; rest of the
> room: Opus and G.711"
>
In light of the fact that the proposal is actually rtc*web*, I'm
surprised that this discussion has gone on for so long.  It's a standard
for the web first, and specifically for realtime communication on the
web.  Interop is important, but it shouldn't be a factor that has such a
strong bearing on it that it blocks adoption of a superior standard for
one that is less so.

I appreciate the sentiment of Opus only as MTI, and the only reason I
would give any bearing to G.711 is for including a bear-minimum degree
of interop with already existing standards that are *not* web-specific.

Again, I reiterate, I fully support Opus as MTI for openness,
performance, efficiency, and latency reasons and G.711 as MTI for legacy
interop reasons.

And I also plainly state that amorphous IPR issues with Opus should be
made concrete before they be taken seriously, since the same claims have
held-up the wider adoption of other free codecs in a similar vein for
years (e.g., Vorbis and Theora, to cite examples) and *nothing*
materialized for them despite very juicy targets implementing them.  "It
hasn't been enough time" should not hold up the standardization
process.  There will never be enough time for the conditions that have
been brought-up again-and-again.

If I can go so far as to say that even the Web itself has faced IPR
issues, what with the alleged patents on hyperlinking, methods of
clicking on a button, and so on.  If we waited for the patent landscape
on such issues to clear before settling on a standard, there'd *be* no
web so to speak.  Opus has IPR in it already that has been licensed in
an RF manner.  This alone is a strong protection, and it's been made
widely aware to all interested parties, so factors such as estoppal and
what not are in effect that will mitigate any claims at this time.  But,
and I reiterate, to say it needs to be *clear* of IPR concerns is an
impossble condition.

I know these are not issues that Randell brought up, but I think this
discussion is no longer productive, and the consensus is clear, both to
people that attended in Vancouver and those outside.  The issues that
have been raised are simply not serious and are merely stalling tactics
at this point holding-up the rtcweb process.  Need I be more explicit
than that, considering a former player has already proposed a competing
standard to rtcweb about the real factors in play here?

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 29 Aug 2012 18:16:27 -0400

Fine works for me but please 722 WB for SHOULD. Of course none of this will
be of any significance if you can't agree on a reasonable offer/answer model
that interoperates with public SIP networks ( previously called the PSTN ) 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Harald Alvestrand
Sent: Wednesday, August 29, 2012 6:22 AM
To: [email-masked]
Subject: Re: [rtcweb] Confirmation of consensus on audio codecs

Since the number of people stating their opinion has been large, I'll just
reiterate the opinion I had (and hummed for) in Vancouver:

Since the question of whether there's any value to making the decision now
has been raised:

The first interoperable products implementing RTCWEB are shipping within a
very short timeframe. Those first implementations will shape the market for
what's actually used in practice.
In order to allow applications requiring high quality sound to be among the
first ones developed, those first products need to include a common choice
of a high quality codec.

                   Harald

[Note - the same logic applies to video codecs, but I've accepted that it's
impossible to make a consensus decision at this time on that issue. 
We'll just live with the consequences of that.]

---

From: Randall Gellens <[email-masked]>
Date: Wed, 29 Aug 2012 17:43:39 -0700

>  standard to rtcweb about the real factors in play here?

I find the assertion that those who disagree with you are merely 
attempting to delay things to be false, unfair, and insulting.  There 
have been several viewpoints expressed, all backed by solid technical 
grounds.  Some of these views support Opus plus G.711, some support 
G.711 only, some support G.711 plus G.722, some support no MTI audio 
codec at this time.  None of these would prevent rtcweb from 
advancing.  Any of these views would allow implementations to support 
Opus as well as G.722, AMR and AMR-WB.  The nice thing about using 
SDP to negotiate a codec is that it allows any codec to be used.  The 
fact that a codec is not MTI doesn't mean it won't or shouldn't be 
supported (far from it).

It's a normal part of the IETF process that different views are 
expressed, each with technical reasoning.  Different participants are 
free to assign different weights to each reason, and this is also 
expected.  What's not a normal part of the process is to accuse other 
participants of bad intent.  That poisons the dialog and creates 
mistrust, especially of you.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
A long-forgotten loved one will appear soon.  Buy the negatives
at any price.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 30 Aug 2012 07:48:58 +0200

> that interoperates with public SIP networks ( previously called the PSTN )
We've already got people writing Javascript that interworks with 
Asterisk, so I don't think this is going to be a problem (unless someone 
decides to start over again).

---

From: Stefan Hakansson LK <[email-masked]>
Date: Thu, 30 Aug 2012 13:58:13 +0200

> On 08/29/2012 05:51 AM, Stefan Hakansson LK wrote:
...
> pretty soon.

If that is the case (and I think and hope so), why would we need to make 
it MTI before seeing it in action?

[...]

> Are you expecting *another* single, standardized,

No, I'm not expecting that. I would just prefer us to see that Opus does 
indeed deliver as promised before making it MTI. If it does, fine. If 
not, we'd have to discuss what to do then.

To me it is like if you're going to place a bet, for an upcoming big 
race, on a horse that has never been in an actual race, but shows great 
promise. If you know that the horse is going to participate in a few 
practice races soon, would you not prefer to wait and see how it fares 
in those before placing the bet (given that the odds would not change)?

Anyway, that's my view. Let's see what the chairs say.
> http://research.nokia.com/files/public/%5B16%5D_InterSpeech2011_Voice_Quality_Characterization_of_IETF_Opus_Codec.pdf
Come on, those tests are very limited compared to a formal 
characterization test. (Example: 
www.itu.int/dms_pub/itu-t/opb/tut/T-TUT-ASC-2010-MSW-E.docx). There is 
very little info on the material used, the environment, processing and 
scripts and so on. And there seems to be no tests whatsoever (at least 
not involving humans) with actual channels introducing jitter and losses.

Note: I am in no way proposing that a formal characterization test is 
needed, or even the right thing to do. It is a costly and time consuming 
process, and alternative approaches could prove to be more efficient. 
What I am saying is that I think we should not mandate a codec that has 
neither gone through that kind of formal characterization testing nor 
has any field experience from actual use on a reasonable scale (covering 
different conditions and device types). It just seems wrong, especially 
given that we will soon have field experience.

> anything, I think other SDOs should learn something here.

This may very well be true. I guess this comes down to how much you 
trust that the quality assessment models (e.g. PEAQ, POLQA) give the 
same result as human test subjects would. But I think this sounds like a 
really good thing.

> iQEcBAEBAgAGBQJQPhThAAoJEJ6/8sItn9q9nAcH/0BsXl/FBgMhbYWVALpNmIYi
> Yj1ezyW8JVSv4io1YIozucl6KiDVi3LwYFteYgl78PlQ7o2muv/lJP9VswRHooH5
> Gax+aJUZkz7SlKxn+25wUlLgKQw6GAcUID5sJ0ewWdGOrwZu+SlZgYF3egYmmwyL
> pEl8BFj7wu3uakRm/BE9LsUDPFdCoZS6uXqXRJOy9P1dZ25edvgaymQvOwhEcXu9
> xMq82YPNU2CZpfb88ew/l+U9FjW8c4iGkZYiu+VzmBL8wYOFP5pBhBhWc/bEb0WX
> 8IUC5PJ0MMp49kb7/kfQj65/Py7u6ytYaO4PA0rjMHJ2V1PzH4EuqtNweYXVzNI=
> =nwlD

---

From: Neil Stratford <[email-masked]>
Date: Thu, 30 Aug 2012 13:46:21 +0100

> At the last meeting we took a hum on selecting Opus and G.711 as the mediatory to implement audio codecs. If there is any new opinions please send them to the list by August 30th, after which the c…

I support both G.711 and Opus as mandatory to implement.

G.711 alone does not meet the rtcweb goal of producing a viable
alternative to browser plugins as it will be impossible for an
application developer to guarantee an acceptable audio quality
(defined as at least as good as when using plugins) for browser to
browser calls.

Neil

---

From: Randall Gellens <[email-masked]>
Date: Thu, 30 Aug 2012 10:26:38 -0700

At 1:58 PM +0200 8/30/12, Stefan Hakansson LK wrote:

>  If that is the case (and I think and hope so), why would we need to 
> make it MTI before seeing it in action?

Good point.  We can hold off on mandating codecs until we see some 
initial implementations.  We might not need to mandate anything.

-------------- Randomly selected tag: ---------------
Why was I born with such contemporaries?
                           --Oscar Wilde

---

From: Ted Hardie <[email-masked]>
Date: Thu, 30 Aug 2012 10:47:20 -0700

On Thu, Aug 30, 2012 at 10:26 AM, Randall Gellens <[email-masked]> wrote:

> Good point.  We can hold off on mandating codecs until we see some initial
> implementations.  We might not need to mandate anything.

As chair:  The decision to mandate codecs as a way of avoiding
interoperability failures in negotiation has already been taken by the
working group.

regards,

Ted Hardie

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Thu, 30 Aug 2012 12:32:08 -0700

> (defined as at least as good as when using plugins) for browser to

And, for those who do not know, this is what plugins are capable of 
today: https://plus.google.com/u/0/117107600391040942348/posts/ZYw4j21RjUL

---

From: Ron <[email-masked]>
Date: Sat, 1 Sep 2012 13:13:09 +0930

> (defined as at least as good as when using plugins) for browser to

Indeed.  +1 for Opus and G.711 as MTI.

 Ron