Subject: [rtcweb] Codec Draft

From: "Bran, Cary" <[email-masked]>
Date: Mon, 31 Oct 2011 22:25:48 +0000

Hello WebRTC chairs,

I have updated and submitted a 02 version of the WebRTC Codec draft: http://tools.ietf.org/id/draft-cbran-rtcweb-codec-01.txt

I believe that this draft is representative of areas where the working group has achieved consensus and at this time I would like to ask that the 01 draft be adopted as a working group document.

I look forward to your feedback.

Regards,

Cary Bran
Senior Director Advanced Software Technology and Architecture
Office:  +1 831-458-7737     Cell: +1 206-661-2398
Plantronics  Simply Smarter Communications(tm)
345 Encinal St., Santa Cruz, CA 95060

________________________________

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain information that is confidential and/or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the contents to another person, store or copy the information in any medium, or use any of the information contained in or attached to this transmission for any purpose. If you have received this transmission in error, please immediately notify the sender by reply email or at [email-masked], and destroy the original transmission and its attachments without reading or saving in any manner.

For further information about Plantronics - the Company, its products, brands, partners, please visit our website www.plantronics.com.

---

From: Stephan Wenger <[email-masked]>
Date: Thu, 03 Nov 2011 13:28:28 -0700

Hi Cary, WG,

Cary, how did you come to your conclusion that the WG has achieved consensus
on a subject like this:
   If the MPEG-LA issues an intent to offer H.264 baseline profile on a
   royalty free basis for use in browsers before March 15, 2012, then
   the REQUIRED video codecs will be H.264 baseline.  If this does not
   happen by that the date, then the REQUIRED video codec will be VP8
   [I-D.webm].

Or this

   WebRTC clients are REQUIRED to implement the following audio codecs.

    [Š]

   o  Opus [draft-ietf-codec-opus]

I may have missed it in the flood of emails on this reflector, but I do not
recall having seen any discussion whatsoever towards a decision between the
two video codecs mentioned, let alone a decision made on commercial
constraints and an attached timeline.  Please note that I could most likely
agree to the video codec issues as drafted, with the exception of the
timeline, which is IMO overly and unnecessarily ambitious.

Similarly, I do not recall a sufficiently in-depth discussion about audio
codecs (though there has been a bit more discussion on the reflector in this
regard).  I find it strange that we consider making an
declared-as-royalty-bearing audio codec mandatory, without even having the
slightest idea of the licensing terms beyond the RAND terms offered.
Strangely, we are not providing the right holder with a timeline similar as
the one used for H.264.  Perhaps we should work with the Qualcomm guys to
see whether they would be willing to provide an RF license with a field of
use restriction to webrtc.  As the very minimum, I would request the opus
codec being profiled such that most obvious matches between patent claims
offered under royalty bearing RAND terms and opus encoder and decoder as to
be used in webrtc be eliminated.

To summarize, without having those (and perhaps a few more) points discussed
in public on the reflector, I believe that it is too early to adopt your
draft as a WG draft.

Stephan

From:  "Bran, Cary" <[email-masked]>
Date:  Mon, 31 Oct 2011 22:25:48 +0000
To:  "[email-masked]" <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  [rtcweb] Codec Draft

Hello WebRTC chairs,
 
I have updated and submitted a 02 version of the WebRTC Codec draft:
http://tools.ietf.org/id/draft-cbran-rtcweb-codec-01.txt
 
I believe that this draft is representative of areas where the working group
has achieved consensus and at this time I would like to ask that the 01
draft be adopted as a working group document.

Regards,

Cary Bran
Senior Director Advanced Software Technology and Architecture
Office:  +1 831-458-7737     Cell: +1 206-661-2398
Plantronics Simply Smarter Communications
345 Encinal St., Santa Cruz, CA 95060

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files
or previous e-mail messages attached to it, may contain information that is
confidential and/or legally privileged. If you are not the intended
recipient, or a person responsible for delivering it to the intended
recipient, please DO NOT disclose the contents to another person, store or
copy the information in any medium, or use any of the information contained
in or attached to this transmission for any purpose. If you have received
this transmission in error, please immediately notify the sender by reply
email or at [email-masked], and destroy the original transmission
and its attachments without reading or saving in any manner.

For further information about Plantronics - the Company, its products,
brands, partners, please visit our website www.plantronics.com.
_______________________________________________ rtcweb mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Bran, Cary" <[email-masked]>
Date: Thu, 3 Nov 2011 21:02:01 +0000

Good points Stephan.

I agree that more discussion is needed and all I am proposing here is a document to capture the groups collective thinking.  I will defer to the chairs to decide on timing.

Cheers,

-Cary

From: Stephan Wenger [mailto:[email-masked]]
Sent: Thursday, November 03, 2011 1:28 PM
To: Bran, Cary; [email-masked]
Subject: Re: [rtcweb] Codec Draft

Hi Cary, WG,

Cary, how did you come to your conclusion that the WG has achieved consensus on a subject like this:

   [I-D.webm].

Or this

    [...]

I may have missed it in the flood of emails on this reflector, but I do not recall having seen any discussion whatsoever towards a decision between the two video codecs mentioned, let alone a decision made on commercial constraints and an attached timeline.  Please note that I could most likely agree to the video codec issues as drafted, with the exception of the timeline, which is IMO overly and unnecessarily ambitious.

Similarly, I do not recall a sufficiently in-depth discussion about audio codecs (though there has been a bit more discussion on the reflector in this regard).  I find it strange that we consider making an declared-as-royalty-bearing audio codec mandatory, without even having the slightest idea of the licensing terms beyond the RAND terms offered.  Strangely, we are not providing the right holder with a timeline similar as the one used for H.264.  Perhaps we should work with the Qualcomm guys to see whether they would be willing to provide an RF license with a field of use restriction to webrtc.  As the very minimum, I would request the opus codec being profiled such that most obvious matches between patent claims offered under royalty bearing RAND terms and opus encoder and decoder as to be used in webrtc be eliminated.

To summarize, without having those (and perhaps a few more) points discussed in public on the reflector, I believe that it is too early to adopt your draft as a WG draft.

Stephan

From: "Bran, Cary" <[email-masked]<mailto:[email-masked]>>
Date: Mon, 31 Oct 2011 22:25:48 +0000
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [rtcweb] Codec Draft

Hello WebRTC chairs,

Regards,

Cary Bran

CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents, files or previous e-mail messages attached to it, may contain information that is confidential and/or legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, please DO NOT disclose the contents to another person, store or copy the information in any medium, or use any of the information contained in or attached to this transmission for any purpose. If you have received this transmission in error, please immediately notify the sender by reply email or at [email-masked]<mailto:[email-masked]>, and destroy the original transmission and its attachments without reading or saving in any manner.

For further information about Plantronics - the Company, its products, brands, partners, please visit our website www.plantronics.com<http://www.plantronics.com>.
_______________________________________________ rtcweb mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Bran, Cary" <[email-masked]>
Date: Thu, 3 Nov 2011 22:00:26 +0000

After further review, I think I get your point, my apologies if I caused any confusion.

What I meant to say was that I believe we have captured areas where we have consensus in the draft.  Obviously at this time there is no consensus as to which audio/video codecs will be mandatory to implement yet.     To be clear here, in the draft we put in a proposal for a mandatory to implement codec and we should have qualified it as an open issue, where we have no consensus.

Stephan, if you or anyone else, has a proposal as to what to add to the list, we would be more than happy to add it to the document and correctly label the areas where we have no consensus in an attempt to facilitate the discussion.

Regards,

-Cary

From: Bran, Cary
Sent: Thursday, November 03, 2011 2:02 PM
To: 'Stephan Wenger'
Cc: [email-masked]
Subject: RE: [rtcweb] Codec Draft

Good points Stephan.

Cheers,

-Cary

Hi Cary, WG,

   [I-D.webm].

Or this

    [...]

Stephan

Hello WebRTC chairs,

Regards,

Cary Bran

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 4 Nov 2011 10:07:48 +0100

WG,

Cary has tried to clarify his statement below, but for clarity:

There is no WG consensus on this document.

The WG chairs have made no decision yet to even call for adoption.

We will have 30 minutes in Taipei to discuss Codecs and Codec selection
for WebRTC. Please consider this draft one proposal for a starting point
in this selection. The other individual document that provides any views
on the codecs are:
https://datatracker.ietf.org/doc/draft-wenger-rtcweb-layered-codec/

So please review both in preparation for the discussion.

We WG chairs encourage discussion on the mailing list and feedback to
the authors of the documents.

Cheers

Magnus

On 2011-10-31 23:25, Bran, Cary wrote:
> I believe that this draft is representative of areas where the working
> group has achieved consensus and at this time I would like to ask that
> the 01 draft be adopted as a working group document.
> 
>  
> 
> *Cary Bran*
> *Plantronics*  Simply Smarter Communications™
> 
> ------------------------------------------------------------------------
> 
> CONFIDENTIALITY NOTICE: This e-mail transmission, and any documents,
> files or previous e-mail messages attached to it, may contain
> information that is confidential and/or legally privileged. If you are
> not the intended recipient, or a person responsible for delivering it to
> the intended recipient, please DO NOT disclose the contents to another
> person, store or copy the information in any medium, or use any of the
> information contained in or attached to this transmission for any
> purpose. If you have received this transmission in error, please
> immediately notify the sender by reply email or at
> [email-masked], and destroy the original transmission and its
> attachments without reading or saving in any manner.
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Xavier Marjou <[email-masked]>
Date: Fri, 4 Nov 2011 15:06:04 +0100

Hi,

I don't think there is a consensus on codec requirements. There are other
individual drafts also discussing the rtcweb codecs :
First, this old draft
http://tools.ietf.org/html/draft-marjou-dispatch-rtcweb-sip-rtp-interwk-reqs-00,
and
also this draft
http://tools.ietf.org/html/draft-kaplan-rtcweb-sip-interworking-requirements-00
that
I fully support by the way.

Cheers,
Xavier

On Mon, Oct 31, 2011 at 11:25 PM, Bran, Cary <[email-masked]>wrote:

> group has achieved consensus and at this time I would like to ask that the
> 01 draft be adopted as a working group document.
>
>
>
> ------------------------------
>
> email or at [email-masked], and destroy the original
> transmission and its attachments without reading or saving in any manner.
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Xavier Marjou <[email-masked]>
Date: Fri, 4 Nov 2011 15:20:17 +0100

Hi,

Regarding WebRTC codec requirements, there are also other individual drafts
with different views on the wanted codecs : first, this old draft
http://tools.ietf.org/html/draft-marjou-dispatch-rtcweb-sip-rtp-interwk-reqs-00,
and
also
http://tools.ietf.org/html/draft-kaplan-rtcweb-sip-interworking-requirements-00,
which
I fully support by the way.

Cheers,
Xavier

>> files or previous e-mail messages attached to it, may contain information
>> that is confidential and/or legally privileged. If you are not the intended

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 4 Nov 2011 17:31:19 +0100

El 04/11/2011 15:20, "Xavier Marjou" <[email-masked]> escribió:

Xavier, such draft does not propose that Webrtc must implement all the
requirements in the draft. It just lists all the requirements needed in
order to fully interoperate with current SIP deployments and opens the door
for discussion about it.

So if you "fully support" this draft it means that you are just interested
in making Webrtc to work with current SIP, regardless security requirements
in the Web.

So let me know: do you support that browsers must implement g729? Do you
support that webrtc requires not security at all in the media plane (like
legacy SIP)?

If so, I dont think you care about Webrtc for the Web, but just for telcos.
Behaviors like this one makes this WG to seem a telco party rather than a
WG working for the Web. WebRTC means RTC for the Web, rather than Web for
telcos, or that is what I hope.

Regards.

---

From: "Bran, Cary" <[email-masked]>
Date: Fri, 4 Nov 2011 17:07:23 +0000

Iñaki,

I agree with you with regards to WebRTC needs to embrace a web paradigm and I am a little confused how the latest version of our document implies a telco paradigm.

The 01 version can be found here:  http://tools.ietf.org/id/draft-cbran-rtcweb-codec-01.txt

Currently the documents lists two video codec candidates (VP8/H.264) , and three audio codec candidates, PCMA/PCMU, Telephone Event and Opus.

If you have anything codecs to add that would be considered more web centric, please let us know and we can add it to the open issues list.

Cheers,

-Cary

From: Iñaki Baz Castillo [mailto:[email-masked]]
Sent: Friday, November 04, 2011 9:31 AM
To: Xavier Marjou
Cc: Bran, Cary; [email-masked]
Subject: Re: [rtcweb] Codec Draft

El 04/11/2011 15:20, "Xavier Marjou" <[email-masked]<mailto:[email-masked]>> escribió:
>
> http://tools.ietf.org/html/draft-kaplan-rtcweb-sip-interworking-requirements-00, which I fully support by the way.

Xavier, such draft does not propose that Webrtc must implement all the requirements in the draft. It just lists all the requirements needed in order to fully interoperate with current SIP deployments and opens the door for discussion about it.

So if you "fully support" this draft it means that you are just interested in making Webrtc to work with current SIP, regardless security requirements in the Web.

So let me know: do you support that browsers must implement g729? Do you support that webrtc requires not security at all in the media plane (like legacy SIP)?

If so, I dont think you care about Webrtc for the Web, but just for telcos. Behaviors like this one makes this WG to seem a telco party rather than a WG working for the Web. WebRTC means RTC for the Web, rather than Web for telcos, or that is what I hope.

Regards.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 4 Nov 2011 18:08:28 +0100

Hi,

I don't think that the fact that SIP does not require media security has anything to do with telcos. It was a decision made by IETF to not specify any media plane requirements.

(It was also used as an argument in the good old SIP-vs-H.323 battle.)

Regards,

Christer

________________________________
From: [email-masked] [[email-masked]] On Behalf Of Iñaki Baz Castillo [[email-masked]]
Sent: Friday, November 04, 2011 6:31 PM
To: Xavier Marjou
Cc: [email-masked]; Bran, Cary
Subject: Re: [rtcweb] Codec Draft

El 04/11/2011 15:20, "Xavier Marjou" <http://tools.ietf.org/html/draft-kaplan-rtcweb-sip-interworking-requirements-00, which I fully support by the way.

Regards.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 4 Nov 2011 18:16:52 +0100

Hi Bran. I meant
.

That draft describes all the requirements for out of the box
interoperabiliy between current SIP and WebRTC. It does not try to mandate
those requirements, but just to list them. So if somebody "fully supports"
this draft it means that browsers MUST implement g729 and allow not
security at all, which is annoying. I just replied to a comment "fully
supporting" this draft.

Regards.
El 04/11/2011 18:07, "Bran, Cary" <[email-masked]> escribió:

>  Iñaki,
>
>
>
> I agree with you with regards to WebRTC needs to embrace a web paradigm
> and I am a little confused how the latest version of our document implies a
> telco paradigm.
>
>
>
> The 01 version can be found here:
> *From:* Iñaki Baz Castillo [mailto:[email-masked]]
> *Sent:* Friday, November 04, 2011 9:31 AM
> *To:* Xavier Marjou
> *Cc:* Bran, Cary; [email-masked]
> *Subject:* Re: [rtcweb] Codec Draft
>
>
>
> If so, I dont think you care about Webrtc for the Web, but just for
> telcos. Behaviors like this one makes this WG to seem a telco party rather
> than a WG working for the Web. WebRTC means RTC for the Web, rather than
> Web for telcos, or that is what I hope.
>
> Regards.
>

---

From: Xavier Marjou <[email-masked]>
Date: Fri, 4 Nov 2011 18:26:04 +0100

> order to fully interoperate with current SIP deployments and opens the door
You rephrasing is correct : however the draft does indicate that many
codecs would be desirable from an interworking perspective

> in making Webrtc to work with current SIP, regardless security requirements
I am not "just" interested : I am "also" interested in making WebRTC work
with existing networks using SIP and RTP.

So let me know: do you support that browsers must implement g729?
yes (for some calls, not for all calls)

> Do you support that webrtc requires not security at all in the media plane
> (like legacy SIP)?
>
out-of-thread : no, of course. However in some circumstances some features
may be done at another level or not needed at all (eg: for RTP vs SRTP)

---

From: Randell Jesup <[email-masked]>
Date: Fri, 04 Nov 2011 16:09:40 -0400

On 11/4/2011 1:26 PM, Xavier Marjou wrote:
> On Fri, Nov 4, 2011 at 5:31 PM, Iñaki Baz Castillo <[email-masked] <mailto:[email-masked]>> wrote:
>     Xavier, such draft does not propose that Webrtc must implement all
>     the requirements in the draft. It just lists all the requirements
>     needed in order to fully interoperate with current SIP deployments
>     and opens the door for discussion about it.
>

For example, G.722 would be desirable for some interoperation scenarios, 
even though it's worse than Opus at similar bitrates. (And it's no 
longer under patent)

> yes (for some calls, not for all calls)

Just to note: G.729's license requirements make supporting it a virtual 
impossibility for Mozilla, and unlikely for the other browsers.

-- 
Randell Jesup
[email-masked]

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 5 Nov 2011 14:07:34 +0100

> with existing networks using SIP and RTP.

If you would care just a bit about security in the Web you could never
say "I fully support this draft
(draft-kaplan-rtcweb-sip-interworking-requirements-01)". By saying
that it's clear that you just want "WebRTC to work with *current* and
*insecure* SIP and no matter how".

The purpose of WebRTC is not to work with current SIP networks, even
*less* with current insecure SIP networks.

WebRTC:  "Real Time Collaboration on the World Wide Web"

> yes (for some calls, not for all calls)

So must I pay the G729 royalty fee when downloading Firefox with WebRTC support?
IMHO WebRTC should just define and require open codecs.

> may be done at another level or not needed at all (eg: for RTP vs SRTP)

There is long rationale in this mailist about why SRTP must be
mandatory for every WebRTC scenarios, without being optional per Web
site.

Best regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Roman Shpount <[email-masked]>
Date: Sat, 5 Nov 2011 09:57:49 -0400

> mandatory for every WebRTC scenarios, without being optional per Web
There is an equally long rational of the opposite. I do not think consensus
was reached in this regard.
_____________
Roman Shpount

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 8 Nov 2011 16:31:38 -0700

On Nov 4, 2011, at 2:09 PM, Randell Jesup wrote:

> 
> Just to note: G.729's license requirements make supporting it a virtual impossibility for Mozilla, and unlikely for the other browsers.

I realize this was the case at one point in time but I thought we worked with VoiceAge to solve the problem of open source software using 729. Is it still a problem ? Can we send Jean-Marc to fix it?

---

From: Ralph Giles <[email-masked]>
Date: Tue, 8 Nov 2011 16:22:11 -0800

> I realize this was the case at one point in time but I thought we worked with VoiceAge to solve the problem of open source software using 729. Is it still a problem ? Can we send Jean-Marc to fix i…

First I've heard of it. VoiceAge has a "free download" win32 binary
for evaluation of G.729, but both VoiceAge and Wikipedia point to
http://www.sipro.com/g729onestop.php for licensing.

 -r

---

From: Ralph Giles <[email-masked]>
Date: Tue, 8 Nov 2011 16:25:35 -0800

On 8 November 2011 16:22, Ralph Giles <[email-masked]> wrote:

> VoiceAge and Wikipedia point to

Which should be http://www.sipro.com/g729_about.php

There are various terms available, but I don't see anything about open source.

 -r

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 8 Nov 2011 17:26:25 -0700

Hmm - perhaps the state is far more messed up than I thought. Initially there was the free download stuff for testing development but not real use. I thought there had been some agreement on broader usage for open source software but I've lost track of where things are on that.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 8 Nov 2011 16:49:19 -0800

> So let me know: do you support that browsers must implement g729?
Simple answer:  No. We've been through the issues relating to G.729 in a number of other contexts, such as emergency service requirements (e.g. ECRIT Phone-BCP, NENA i3).  It didn't get in, even as OPTIONAL.  For example, here is what ECRIT PhoneBCP Section 14 says on the subject of audio codecs (end system requirements):

   ED-71 Endpoints MUST send and receive media streams on RTP [RFC3550].

   ED-72 Normal SIP offer/answer [RFC3264] negotiations MUST be used to
   agree on the media streams to be used.

   ED-73/SP-41 G.711 A law (and mu Law if they are intended be used in
   North America) encoded voice as described in [RFC3551] MUST be
   supported.  If the endpoint cannot support G.711, a transcoder MUST
   be used so that the offer received at the PSAP contains G.711.  It is
   desirable to include wideband codecs such as G.722 and AMR-WB in the
   offer.  PSAPs SHOULD support narrowband codecs common on endpoints in
   their area to avoid transcoding.

   ED-74 Silence suppression (Voice Activity Detection methods) MUST NOT
   be used on emergency calls.  Here is what NENA i3 stage 3 says (ESINet requirements):  4.1.8.1 AudioAll User Agents in the ESInet must support g.711 mu-law and a-law. A-law support is required in the case that devices manufactured primarily for non-North American markets is used within North America. It is recommended that AMR, AMR-WB, EVRC[138], EVRC-B[139], EVRC-WB[140], and EVRC-NW[141] also be supported.

---

From: Jean-Marc Valin <[email-masked]>
Date: Tue, 08 Nov 2011 22:23:13 -0500

On 08/11/11 06:31 PM, Cullen Jennings wrote:
>> Just to note: G.729's license requirements make supporting it a
>> virtual impossibility for Mozilla, and unlikely for the other
>> browsers.
> 
> I realize this was the case at one point in time but I thought we
> worked with VoiceAge to solve the problem of open source software
> using 729. Is it still a problem ? Can we send Jean-Marc to fix it?

I'm also not aware of anything that was done to make G.729 available in
open source software. G.729 licensing is a bit of a mess and last I
heard (though it could have changed), VoiceAge does not even license all
of the patents that (are thought to) cover G.729.

	Jean-Marc

---

From: Miguel Casas-Sanchez <[email-masked]>
Date: Thu, 10 Nov 2011 18:14:43 +0100

Cary, Cullen,

if I can add my two pennies:

- on the audio codec requirements sec 3.1 , you could be adding as
optional mp3 (MPEG-2 layer III). I'm sure a large part of the audience
would like to beat me up after writing this, but WebRTC is about
interoperability, and there's a whole bunch of servers out there
cranking mp3. I'm not too sure if this would not suffer of the same
problems as g.729 with licensing. MPEG is easier on licensing than
ITU. Or perhaps this is not the document to discuss this optional
reqs.

- on the video codec req. sec 3.2, the frame rate attainable by the
codec is in no way dependent on the codec itself when streaming, as
far as I know. Same goes for the resolutions. It might be better to
specify a range? The sentence " MUST support a minimum resolution of
320X240" --> might have been "MUST support at least 320x240 pixels
resolution"? Shouldn't we add something on supporting/not supporting
vbr/cbr?

- on the WebRTC client requirements, you go a long way in the SHOULD
requirements such as agc etc, but  there is a real chance that those
things might be offered in software either compulsorily either de
facto. Shouldnt it be a "MAY"? And perhaps we could add some
nice-to-have on video requirements, such as "if you want video..."
then camera must support QCIF res, >10fps, etc.?

- section 5, pp4, interoperability, I read "

The codec requirements above will ensure, at a minimum, voice
   interoperability capabilities between WebRTC client applications and
   legacy phone systems."

 Really? since when is WebRTC targeted at interoperability with older
phone systems?? Please correct me if I'm wrong.

Cheers

Miguel

---

From: Ralph Giles <[email-masked]>
Date: Fri, 11 Nov 2011 21:25:11 -0800

On 10 November 2011 09:14, Miguel Casas-Sanchez wrote:

> cranking mp3.

As has been mentioned before, mp3's fixed frame size of 1152 samples
makes it unsuitable for interactive applications, especially when
combined with the usual 2 or 3 frame encoder latency.

> I'm not too sure if this would not suffer of the same

The mp3 format is also believed to be covered by patents through the
end of 2017[1]. While it might be possible to find an encoder profile
which will be free before then, it will be at least 2013 before even
that subset can be considered royalty free.

Unfortunate, I agree, but mp3 and several other more established audio
codecs were considered and discarded prior to this draft.

 -r

[1] http://en.wikipedia.org/wiki/Mp3#Licensing_and_patent_issues

---

From: Stefan Håkansson <[email-masked]>
Date: Sat, 12 Nov 2011 14:46:42 +0100

> http://tools.ietf.org/id/draft-cbran-rtcweb-codec-01.txt

Cary, in the -00 version there was also a list of OPTIONAL or 
RECOMMENDED codecs to implement if I remember correctly. Was there a 
specific reason for removing that part? Listing codecs that would be 
"good to implement" for e.g. interoperablity with legacy has some value 
I think.

> *Plantronics*Simply Smarter Communications™
>