Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

Bernard Aboba <> Thu, 27 June 2013 04:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4D3D921F99C3 for <>; Wed, 26 Jun 2013 21:14:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.259
X-Spam-Status: No, score=-102.259 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id elVKFyHLJnee for <>; Wed, 26 Jun 2013 21:14:10 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8FB6821F99BE for <>; Wed, 26 Jun 2013 21:14:08 -0700 (PDT)
Received: from BLU169-W22 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Wed, 26 Jun 2013 21:14:07 -0700
X-TMN: [xm0nDIA8bYmVDpHmoIoz+5G9ObT7UnW2]
X-Originating-Email: []
Message-ID: <BLU169-W225763F0847397377AA5AE93750@phx.gbl>
Content-Type: multipart/alternative; boundary="_f07f1269-9fea-4249-9707-4d309582bb7d_"
From: Bernard Aboba <>
To: Robin Raymond <>
Date: Wed, 26 Jun 2013 21:14:06 -0700
Importance: Normal
In-Reply-To: <>
References: <>, <>, <>, <>
MIME-Version: 1.0
X-OriginalArrivalTime: 27 Jun 2013 04:14:07.0101 (UTC) FILETIME=[C444BAD0:01CE72EC]
Cc: "" <>
Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)
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, 27 Jun 2013 04:14:16 -0000

Robin said: 

"If provided a lower level API that works without SDP where the 
individual network/media component wiring/attributes can be controlled, 
we could create the same WebRTC API that exists today'
[BA] I wouldn't require a shim to provide "the same WebRTC API that exists today" because that API is very underspecified, so that it is not possible to produce a set of conformance tests for it without reverse engineering.  And of course, that reverse engineered specification would only remain valid until the next set of SDP hacks invalidated it. 
So while the shim might provide a "similar high level WebRTC API", holding WebRTC API 2.0 to a "bug for bug" compatibility standard is neither feasible nor desirable.   The goal of WebRTC API 2.0 should be to deprecate 1.0, not to increase the WebRTC API implementation barriers even further.