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

Andrew Allen <> Wed, 13 March 2013 17:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8AF9121F85D4 for <>; Wed, 13 Mar 2013 10:29:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.984
X-Spam-Status: No, score=-5.984 tagged_above=-999 required=5 tests=[AWL=0.614, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2F5vNxDU+Tfn for <>; Wed, 13 Mar 2013 10:29:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 557E821F8459 for <>; Wed, 13 Mar 2013 10:29:47 -0700 (PDT)
X-AuditID: 0a412830-b7ef86d00000339d-6e-5140b77e7df9
Received: from ( []) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by (SBG) with SMTP id FE.7D.13213.E77B0415; Wed, 13 Mar 2013 12:29:35 -0500 (CDT)
Received: from ([fe80::2494:a63d:e3:723b]) by ([fe80::c8f6:ae2e:c42b:3614%21]) with mapi id 14.02.0328.009; Wed, 13 Mar 2013 12:29:34 -0500
From: Andrew Allen <>
To: "" <>, "" <>
Thread-Topic: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIBBTajoIOkWHW02dWrWPKwvhNw==
Date: Wed, 13 Mar 2013 17:29:33 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-CA, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD2338D28AC3XMB104ADSrimnet_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLKsWRmVeSWpSXmKPExsXC5Zyvo1u/3SHQ4O58DosZF6YyW6z9187u wOSxZMlPJo9bUwoCmKIaGG2SEkvKgjPT8/TtbBLz8vJLEktSFVJSi5NtlXxS0xNzFAKKMssS kysVXDKLk3MSM3NTi5QUMlNslUyUFApyEpNTc1PzSmyVEgsKUvNSlOy4FDCADVBZZp5Cal5y fkpmXrqtkmewv66FhamlrqGSnW5CJ0/GlR8T2QpWWVTMfTCTsYHxjlkXIyeHhICJxIaFe9gg bDGJC/fWA9lcHEICbUwS0/buY4dwNjNKzHi6mBmkik1AS2L/4elMILaIQJDE9r2bwGxhgXiJ +xPvM0LEEyT+fP7NDmHrSXz8MRmsl0VAVaLn+FGwOK+Ah8T8p+fAbE6BQImrfSvBehkFZCV2 n70ONpNZQFzi1pP5TBDXCUgs2XOeGcIWlXj5+B8rhK0o8Xfvd1aI+nyJW9cfs0HMF5Q4OfMJ ywRG4VlIRs1CUjYLSdksRg6guKbE+l36ECWKElO6H7JD2BoSrXPmsiOLL2BkX8UomJtRbGBm mJyXrFeUmauXl1qyiRGUJBw1DHYwvn9vcYhRgINRiYd323SHQCHWxLLiytxDjBIczEoivMtz gUK8KYmVValF+fFFpTmpxYcYg4ABNJFZijs5H5jA8krijQ0MiOQoifOKBIoGCgmkA9NVdmpq QWoRzFAmDk6QpVxSIsXApJNalFhakhEPSo3xxcDkKNXAOI9XwvT6krsnD3WWaXnuy1E+2FT0 4O+t24mHrs23OqkswsZ9aGvzruk7tKbYzn16XKAkMfPK9V9/srdP62Nt/vvp+o4zWVNKf2Wf fP70bngFY4PffK2Hh/1VfjO5abOmbZgnkqlQdeO06LdF/NdzvL7/2d1Q4WIrfEj7o3VBkID5 p0Lu+weuXVFiKc5INNRiLipOBAChL27gYAMAAA==
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 17:29:48 -0000

If there is a business case for implementers to support other codecs for improved inteoperability with other networks and devices then they are very likely to do so.

From: Roman Shpount []
Sent: Wednesday, March 13, 2013 12:12 PM Central Standard Time
To: <>
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

Normally, when implementing VoIP devices, unless they are intended for some sort of walled garden, you try to support as many codecs as possible. This increases your chances of interoperability with other devices and your product adoption. In case of WebRTC, it would be adopted regardless of what codecs are supported. The number of enabled devices would be so great that all the legacy networks will have to adapt. This has some negative implications to the legacy networks as far as quality and costs are concerned, but these challenges are not insurmountable. So, taking this into consideration, I want to place the same questions differently:

Do web browser implementers currently plan to support any other codecs except MTI (G.711 and OPUS)?

Is there anything we are going to say here regarding legacy interop that would make browser manufacturers to change their mind? After all, this represents additional cost to them with no direct benefit for the use cases which are most important to them (browser to browser calls).

For me, the desired outcome would be that browsers, at least for the next few years, do support a reasonable set of other codecs in addition to MTI, including G.722, AMR, AMR-WB, and may be Speex, . This would give me an opportunity to migrate from devices that support legacy codecs to devices that support Opus. The fact that different browser versions would support different codec sets (like desktop browsers not supporting AMR) is not a big issue, at least for me, since we always have G.711 or transcoding to fall back to. The same goes for browsers fazing some of the legacy codecs out in the future. The end result would still be better then 100% G.711 or transcoding.
Roman Shpount

This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.