Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

<> Wed, 13 March 2013 19:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE2AE21F8CD3 for <>; Wed, 13 Mar 2013 12:37:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DmlNYnCeXjx3 for <>; Wed, 13 Mar 2013 12:37:01 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5AC0021F8CB1 for <>; Wed, 13 Mar 2013 12:37:01 -0700 (PDT)
Received: from (unknown [xx.xx.xx.3]) by (ESMTP service) with ESMTP id 944E322CDC4; Wed, 13 Mar 2013 20:37:00 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown []) by (ESMTP service) with ESMTP id 718E94C017; Wed, 13 Mar 2013 20:37:00 +0100 (CET)
Received: from PEXCVZYM14.corporate.adroot.infra.ftgroup ([fe80::a42f:c628:bc76:d592]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 20:36:59 +0100
From: <>
To: Jean-Marc Valin <>, MARJOU Xavier OLNC/OLN <>
Thread-Topic: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOG09ymYYSjCiSbkqm//fZ3y/fLpijkgEAgABnSICAABKQoA==
Date: Wed, 13 Mar 2013 19:36:52 +0000
Message-ID: <31611_1363203420_5140D55C_31611_11752_1_cb7bfd1e-a4ca-40ba-bbbc-cb23fb3f3edb@PEXCVZYH02.corporate.adroot.infra.ftgroup>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-PMX-Version:, Antispam-Engine:, Antispam-Data: 2013.3.13.152725
Cc: "" <>
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
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: Wed, 13 Mar 2013 19:37:03 -0000


Our understanding is that the reason of the "no consensus" on additional recommended codecs was the additional costs for browsers.
The proposal is then to make these "MUST" fully conditional to the case of no (or very reduced) additional costs, when the codecs are already available on the device and when no additional license fee is required

We could even live with lower level of "requirements" with respectively May and Should (instead of Should and shall) but we think that this proposal is a way to take into account both browser manufacturers concerns on browsers costs and telcos concerns on transcoding costs and some other companies share this view.


-----Message d'origine-----
De : [] De la part de Jean-Marc Valin
Envoyé : mercredi 13 mars 2013 20:24
Cc :
Objet : Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Hash: SHA1


I'd really like to understand how the chairs coming to the conclusion that there was *no consensus* on recommended codecs can result in a draft that includes 3 MUSTs and 1 SHOULD. This draft effectively makes
3 new codecs MTI for a range of devices. I understand that it's an individual draft and you can write whatever you like in there, but it definitely goes against the result of the WG discussion.



On 03/13/2013 09:14 AM, Xavier Marjou wrote:
> Here is a summary of the
> draft-marjou-rtcweb-audio-codecs-for-interop-00 presentation that I 
> had prepared for yesterday's session:
> - The co-authors want to underline that non-WebRTC voice endpoints 
> usually use one of the following codecs: AMR, AMR-WB or G.722, which 
> will result in massive transcoding when there will be communications 
> between WebRTC endpoints and non-WebRTC endpoints.
> - On one side, transcoding is bad for many reasons discussed in the 
> draft (cost issues, intrinsic quality degradation, degraded 
> interactivity, fallback from HD to G.711...);
> - On the other side, it is recognized that implementing additional 
> codecs in the browsers can generate additional costs.
> - In order to reach a compromise, we would like to add some text in 
> the WG draft draft-ietf-rtcweb-audio providing incentives for the 
> browser to use these three codecs: make them mandatory to implement 
> when there is no cost impact on the browser (e.g. if codec already 
> installed, paid by the device vendor...).
> Any opinion on that?
> Cheers,
> Xavier
> PS: I will be ready to present the slides on Thursday if time permits 
> it.
> (c.f.
> )
> On Thu, Mar 7, 2013 at 11:18 AM, Ted Hardie < 
> <>> wrote:
> Magnus and I discussed this this morning, and we encourage you to 
> prepare something.  If the discussion of working group last call items 
> runs short, we may be able to fit this in at that time or at the end 
> of day one if its full agenda his finished.  This is not a commitment, 
> however, so please try and get discussion on the list on the points 
> from the draft you feel need resolution.
> regards,
> Ted
> On Mon, Mar 4, 2013 at 2:31 PM, Espen Berger (espeberg) 
> < <>> wrote:
>> Hello,
>> I would like to request agenda time for:
>> draft-marjou-rtcweb-audio-codecs-for-interop-01
>> The document  presents use-cases underlining why WebRTC needs
>> and G.722 as additional relevant voice codecs to satisfactorily 
>> ensure interoperability with existing systems.
>> A 10-minute time slot should be sufficient for presentation and
> discussion.
>> Regards
>> -Espen
>> _______________________________________________ rtcweb mailing list 
>> <> 
> _______________________________________________ rtcweb mailing list 
> <> 
> _______________________________________________ rtcweb mailing list 

Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -

rtcweb mailing list


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.