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

"DRAGE, Keith (Keith)" <> Wed, 13 March 2013 17:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 19B7F21F8E09 for <>; Wed, 13 Mar 2013 10:37:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.173
X-Spam-Status: No, score=-110.173 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NqgygSdDg7MB for <>; Wed, 13 Mar 2013 10:37:07 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7365D21F8E04 for <>; Wed, 13 Mar 2013 10:37:06 -0700 (PDT)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id r2DHb2Zx025182 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Mar 2013 12:37:02 -0500 (CDT)
Received: from ( []) by (8.14.3/8.14.3/GMO) with ESMTP id r2DHavm6012595 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 13 Mar 2013 12:37:02 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 13 Mar 2013 13:37:00 -0400
Received: from ([]) by ([]) with mapi id 14.02.0247.003; Wed, 13 Mar 2013 18:36:59 +0100
From: "DRAGE, Keith (Keith)" <>
To: Andrew Allen <>, "" <>, "" <>
Thread-Topic: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01
Thread-Index: AQHOIBBTajoIOkWHW02dWrWPKwvhN5ij4Osg
Date: Wed, 13 Mar 2013 17:36:57 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-GB, en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_949EF20990823C4C85C18D59AA11AD8B013D9DFR712WXCHMBA11zeu_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on
X-Scanned-By: MIMEDefang 2.64 on
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:37:10 -0000

The problem is that the business case for the device vendor or end user may not be the business case for the browser vendor.

To be honest this discussion goes round and round in circles, with people trying to say things are out of scope.

What I believe we need is something that encourages creation of APIs for embedded codecs in the devices. Those API's should then be made available within the browser.

This gets even more important when we get to video codecs. I am certainly interested in gateways from RTCWEB endpoints to other SIP based networks. Having to transcode from one video codec to another because of this impasse is a nightmare.

Someone has to break this loop.


From: [] On Behalf Of Andrew Allen
Sent: 13 March 2013 17:30
Subject: Re: [rtcweb] Agenda time request for draft-marjou-rtcweb-audio-codecs-for-interop-01

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.