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

"Matthew Kaufman (SKYPE)" <> Fri, 19 July 2013 18:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7292B21E810C for <>; Fri, 19 Jul 2013 11:38:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.221
X-Spam-Status: No, score=-3.221 tagged_above=-999 required=5 tests=[AWL=-0.522, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zPXQsZbGwC0q for <>; Fri, 19 Jul 2013 11:38:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id F18A021E80D2 for <>; Fri, 19 Jul 2013 11:38:31 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server id; Fri, 19 Jul 2013 18:38:30 +0000
Received: from mail196-va3 (localhost []) by (Postfix) with ESMTP id C3D113A01E4; Fri, 19 Jul 2013 18:38:30 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;;; EFVD:NLI
X-SpamScore: -1
X-BigFish: VS-1(zzc89bh1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097hz2fh2a8h668h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h)
Received-SPF: pass (mail196-va3: domain of designates as permitted sender) client-ip=;; ; ;
Received: from mail196-va3 (localhost.localdomain []) by mail196-va3 (MessageSwitch) id 1374259108813536_16392; Fri, 19 Jul 2013 18:38:28 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id B1A8D300268; Fri, 19 Jul 2013 18:38:28 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 19 Jul 2013 18:38:22 +0000
Received: from ([]) by ([]) with mapi id 14.03.0136.001; Fri, 19 Jul 2013 18:38:11 +0000
From: "Matthew Kaufman (SKYPE)" <>
To: Adam Roach <>, Iñaki Baz Castillo <>
Thread-Topic: On babies and bathwater (was Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)
Thread-Index: AQHOhJ5X3vuWfZ1FiEyuUoqjlknpnZlsUo3w
Date: Fri, 19 Jul 2013 18:38:09 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <BLU401-EAS386F88B3FE140492B39B59693610@phx.gbl> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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:38:38 -0000

From: Adam Roach []:
> I think this is a hopelessly naïve interpretation of the facts on the ground.
> Simply discarding SDP doesn't magically make the underlying issues go away.
> We would still need to settle a vast number of issues around things like
> simulcast, FEC, codec parameters, indication of supported codecs, correlation
> of RTP streams with MediaStreamTracks, attempts by both parties to
> operate on the same stream simultaneously [1], etc. Basically, with very rare
> exception, the same set of problems that we need to solve if we *don't*
> throw SDP out the window.

Not today we wouldn't. We'd need a handful on knobs that let the most common use cases be implemented under JavaScript control, and then we could look at what other APIs need to be added later. None of simulcast, FED, or any of those things (with the exception of the "a=fmt" section for codec parameters or an equivalent) needs to be done to get WebRTC out the door.

> ...
> Your pain point isn't SDP syntax. Yeah, it's ugly, but it's not hard.
> Your pain point isn't offer/answer.

Yes it is. It immediately limits the possible operations that *any* API would be able to achieve.

> Two unilaterally declared sessions that are
> simply blasted out onto the wire only satisfies the simplest of use cases; you
> need a negotiation, and any attempt to define how that negotiation looks is
> going to arrive at something with enough rules that it is substantially as
> complicated as offer/answer.

Simply not true. Offer/answer is only one way to get two things to talk to each other, and it is a "trunk side" "peer to peer" negotiation that assumes no intelligence in the middle.

> No, your pain point here is that non-master-slave networked
> communications are not easy to get right

Aha! I think I see your problem here.

If we give the web developer some JavaScript APIs, then it isn't "non-maser-slave networked communications". In fact it is exactly the opposite. 

Just like all other "HTML5" technologies we should be assuming that the web server and the HTML+JS it sends down *is the master*, telling the browser exactly what it should do. In this scenario, there are a multitude of ways, from simple to complex, to ensuring that both (or more, for any non 1-1 use case) ends are sending data over their network connection that the other end can use and render.

> I understand comment 22 at its core [2], but it has a corollary: any system
> that replaces SDP O/A will end up being similar in complexity once all
> interested parties' use cases have been factored in.

I doubt it. But even if that's true, it will give the JavaScript developer direct control over what is happening, and that's a win. And likely, much of the "extra complexity" you are thinking of will end up in shared JS libraries, not baked into a browser. And the legacy interop you're concerned about? Any compatibility issues will get fixed right in that same place, long before any browser vendor works out exactly what is necessary to work with a particular device that a web site operator cares for their users to connect to.

Matthew Kaufman

ps. Comment 22 isn't "SDP is hard"... rather it is "if you were using our API, you wouldn't be encountering this issue at all"