Re: [rtcweb] On babies and bathwater (was Re: Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)

Bernard Aboba <> Fri, 19 July 2013 18:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EAE1A11E8147 for <>; Fri, 19 Jul 2013 11:26:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.528
X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KzKnnQRqyKQv for <>; Fri, 19 Jul 2013 11:26:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CA8C221F9DED for <>; Fri, 19 Jul 2013 11:26:44 -0700 (PDT)
Received: from BLU169-W42 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Jul 2013 11:26:41 -0700
X-TMN: [893lJfd4gTpCX2dcoBwfTcD/SBSdBQBW+XmKTabi/fY=]
X-Originating-Email: []
Message-ID: <BLU169-W42578601E35650DF5628D793630@phx.gbl>
Content-Type: multipart/alternative; boundary="_2707f48b-d572-4350-8676-6f4f109abc5a_"
From: Bernard Aboba <>
To: Peter Thatcher <>
Date: Fri, 19 Jul 2013 11:26:40 -0700
Importance: Normal
In-Reply-To: <>
References: <>, <>, <>, <>, <>, <>, <>, <>, <>, <BLU401-EAS386F88B3FE140492B39B59693610@phx.gbl>, <>, <>, <>, <>, <>
MIME-Version: 1.0
X-OriginalArrivalTime: 19 Jul 2013 18:26:41.0620 (UTC) FILETIME=[83D36140:01CE84AD]
Cc: "" <>, "" <>
Subject: Re: [rtcweb] On babies and bathwater (was Re: Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)
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: Fri, 19 Jul 2013 18:27:00 -0000

Peter Thatcher said: 

"It's interesting that most of your list of things that needed to be solved without SDP (simulcast, FEC, correlation of RTP streams with MediaStreamTracks, glare) still haven't been solved for WebRTC even with SDP, despite many months (years?) of effort.  

I don't think anyone is saying "without SDP, there would be issues".  I think they're saying "without SDP, the issues are much easier/faster to solve, and the API would be much more usable and implementable".   And I don't think that's a naive opinion."

[BA] I would even go further - I'd claim that several of these issues are best solved without SDP, either in the API or on the wire.  RTP stacks used in WebRTC need to be able to adapt quickly, which implies that the adaptations cannot be signaled.  Also, if you want to scale, then it's important to strip out unnecessary operations that create performance bottlenecks in media-aware network elements (e.g. decrypt/encrypt operations , parsing of codec-specific parameter sets, transcoding, etc.). All this points to moving functionality out of signaling (and codecs) and into RTP.  If you take this perspective, then removing SDP dependencies isn't just a better plan for getting to "done" - it's an essential part of delivering the next generation realtime architecture.