Re: [rtcweb] Codec Draft

Miguel Casas-Sanchez <> Thu, 10 November 2011 17:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 576BB21F8B95 for <>; Thu, 10 Nov 2011 09:14:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_VISITOURSITE=2, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ef79kjqsdcjP for <>; Thu, 10 Nov 2011 09:14:46 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 4027B21F8B89 for <>; Thu, 10 Nov 2011 09:14:46 -0800 (PST)
Received: by wyf28 with SMTP id 28so1229455wyf.31 for <>; Thu, 10 Nov 2011 09:14:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=A/1hKTKhw+asGGafQ9T0n7uSeCMHdSZcFTn8MDzMxC4=; b=LaxLteg0em3r5autzFfNU+lhd34E536MLzPN4OSSap4qdm3fy1rcBqeMmCy4pzA4N4 7hnYw7y6J+WMr3c7+TalHLXiGWV/VrbHwXeaLTMULURjNySqS7yDqhgE8qlX8tAeUxt8 JXxWZ4HZNfFGTHBVXzwv5NBEFnzoxBqQj8ia8=
MIME-Version: 1.0
Received: by with SMTP id t37mr1551008wei.44.1320945283982; Thu, 10 Nov 2011 09:14:43 -0800 (PST)
Received: by with HTTP; Thu, 10 Nov 2011 09:14:43 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
Date: Thu, 10 Nov 2011 18:14:43 +0100
Message-ID: <>
From: Miguel Casas-Sanchez <>
To: "Bran, Cary" <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 11 Nov 2011 20:47:31 -0800
Cc: "" <>
Subject: Re: [rtcweb] Codec Draft
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Nov 2011 17:15:23 -0000

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

- 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

- 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.



On 4 November 2011 18:07, Bran, Cary <> wrote:
> 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:
> 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 []
> Sent: Friday, November 04, 2011 9:31 AM
> To: Xavier Marjou
> Cc: Bran, Cary;
> Subject: Re: [rtcweb] Codec Draft
> El 04/11/2011 15:20, "Xavier Marjou" <> escribió:
> >
> >, 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.
> ________________________________
> 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, 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
> _______________________________________________
> rtcweb mailing list