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

Roman Shpount <> Wed, 13 March 2013 17:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C90CA21F8E3B for <>; Wed, 13 Mar 2013 10:12:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nin2ep2Jhk1S for <>; Wed, 13 Mar 2013 10:12:53 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::235]) by (Postfix) with ESMTP id C395021F8E34 for <>; Wed, 13 Mar 2013 10:12:52 -0700 (PDT)
Received: by with SMTP id hm6so994746wib.14 for <>; Wed, 13 Mar 2013 10:12:52 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:mime-version:x-received:in-reply-to:references:date :message-id:subject:from:to:content-type:x-gm-message-state; bh=MTNh5NsgdhqkLxjZpvDxljUz3mUX3yQtdOJxYkBDF/c=; b=CL1Dpj/LWssK48lceI9EkrM0/FsIE4BN/j1MSCxkoKH7cDi8vfOy3PlmVc+4U0tgwc bLNWZcvyeZNkHTjoK8hEZWIBeYOJK3Dwm4YNg+Lnt/NlrWIBvgtivEClwF/AT2MFOFwL asPtquYMmCxDGzALqjp51sQrVxp9i+20UDLTd3l46bxu34f/oN6p+7Gvj+Me2XPidZkl DWLt/EyeLRP2pc8tWd9fGVGQ3X34CUKX3Fz1mqofeGayjygkJlAl/Q30KPFQCJ/ROaO7 wJPozNlQ8vQQxRMfPLYhm7yLHJ8fsPDpOBtRsGJbbyzH67/VN7n7wKdbcqWV4Qqm1t2n ap+w==
X-Received: by with SMTP id bs2mr33827271wib.0.1363194771960; Wed, 13 Mar 2013 10:12:51 -0700 (PDT)
Received: from ([2a00:1450:400c:c00::22a]) by with ESMTPS id bs6sm4338036wib.4.2013. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 13 Mar 2013 10:12:51 -0700 (PDT)
Received: by with SMTP id 12so174148wgh.3 for <>; Wed, 13 Mar 2013 10:12:50 -0700 (PDT)
MIME-Version: 1.0
X-Received: by with SMTP id y9mr35840949wje.47.1363194770002; Wed, 13 Mar 2013 10:12:50 -0700 (PDT)
Received: by with HTTP; Wed, 13 Mar 2013 10:12:49 -0700 (PDT)
In-Reply-To: <20130313161446.GG12022@audi.shelbyville.oz>
References: <> <> <> <20130313142732.GE12022@audi.shelbyville.oz> <> <20130313161446.GG12022@audi.shelbyville.oz>
Date: Wed, 13 Mar 2013 13:12:49 -0400
Message-ID: <>
From: Roman Shpount <>
Content-Type: multipart/alternative; boundary=047d7b5d277406cea804d7d1846d
X-Gm-Message-State: ALoCoQnV2FCv8SQq+6oIf6Xmmni+rjBGJ19PjldJpzdfE2FK0KO6c1ikBoPLaUvkOpQAPrEH7UbS
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:12:53 -0000

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
Roman Shpount