Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP

"Matthew Kaufman (SKYPE)" <> Fri, 08 March 2013 14:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DD5C821F84F7 for <>; Fri, 8 Mar 2013 06:55:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KJRJe94HHZmj for <>; Fri, 8 Mar 2013 06:55:50 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1E7F621F8491 for <>; Fri, 8 Mar 2013 06:55:49 -0800 (PST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.620.12; Fri, 8 Mar 2013 14:55:41 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.620.12 via Frontend Transport; Fri, 8 Mar 2013 14:55:41 +0000
Received: from ([]) by ([]) with mapi id 14.02.0318.003; Fri, 8 Mar 2013 14:55:27 +0000
From: "Matthew Kaufman (SKYPE)" <>
To: Stefan Håkansson LK <>, Peter Thatcher <>
Thread-Topic: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP
Thread-Index: AQHOG99cNdIHhEwrJ0yj3rXtTeVDRpibz/yAgAAEBQCAAAub8A==
Date: Fri, 08 Mar 2013 14:55:26 +0000
Message-ID: <>
References: <> <> <> <>
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
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(51704002)(199002)(189002)(56776001)(74502001)(54316002)(49866001)(80022001)(47736001)(56816002)(54356001)(46102001)(65816001)(16406001)(44976002)(69226001)(33656001)(47446002)(50986001)(74662001)(53806001)(51856001)(66066001)(79102001)(50466001)(20776003)(23676001)(31966008)(47976001)(55846006)(47776003)(4396001)(63696002)(77982001)(59766001)(76482001); DIR:OUT; SFP:; SCL:1; SRVR:BY2FFO11HUB031;; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-Forefront-PRVS: 077929D941
Cc: "" <>
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus 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: Fri, 08 Mar 2013 14:55:51 -0000

Stefan Håkansson LK:
> I agree to the above - signaling is entirely up to the application. I'm sorry if my
> message gave another impression. But we need to define the format of the
> "blobs" (if we call them that) that browser A produces so that they can be
> plumbed into browser B and things work. 

No we don't. In fact that is exactly what we should mean when we say "signaling is entirely up to the application".

There is no reason why Browser A must produce something a serialized blob that can be stuffed directly into an API at Browser B. And in fact, doing so means that your two browsers are very likely doing things you don't expect... because instead of your JavaScript application saying "do this" to each, it is saying "do whatever this blob that was generated by code I don't control *means to you* (even if that meaning is subtly different than what it meant to the sender)". And then if you want to influence that you have either the pointy sticks called constraints or editing of the blob as your only remaining avenues of control.

Worse, because this now carries the explicit assumption that the two browsers are negotiating directly between each other's code (and really *not* expecting anything in the middle to mess with those blobs), you need a whole set of semantics on top of this to ensure that the browsers converge on something that works without their JavaScript app helping them. That brings in RFC3264-style Offer/Answer (which is not the only way to do it, but the one that was chosen). This then means that if you instead are trying to use the "blob" interface for direct manipulation, you are fighting against what may be an entirely incompatible state machine inside the browser.

> So far the assumption has been
> that those blobs are SDP descriptions, and my point is that changing that to
> something else may cost us more than we gain.

We need to provide the browser with an *API*. And that API should allow the JavaScript developer to directly influence what is happening. Preferably without the browser fighting its developer by trying to run the offer-answer state machine itself. Getting hung up on being able to pass blobs back and forth is now and has always been the whole problem.

Matthew Kaufman