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

"Matthew Kaufman (SKYPE)" <> Tue, 18 June 2013 01:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 288B921F9BB5 for <>; Mon, 17 Jun 2013 18:46:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.148
X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nCOTZuxc4rii for <>; Mon, 17 Jun 2013 18:46:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B1A1621F9BB3 for <>; Mon, 17 Jun 2013 18:46:18 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.707.0; Tue, 18 Jun 2013 01:41:58 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.707.0 via Frontend Transport; Tue, 18 Jun 2013 01:41:57 +0000
Received: from ([]) by ([]) with mapi id 14.03.0136.001; Tue, 18 Jun 2013 01:41:56 +0000
From: "Matthew Kaufman (SKYPE)" <>
To: Roman Shpount <>, =?iso-8859-1?Q?I=F1aki_Baz_Castillo?= <>
Thread-Topic: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)
Date: Tue, 18 Jun 2013 01:41:55 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_AE1A6B5FD507DC4FB3C5166F3A05A4841A2C59D2TK5EX14MBXC273r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(189002)(377454002)(24454002)(199002)(47976001)(50986001)(55846006)(33656001)(76482001)(56816003)(47736001)(74876001)(16406001)(59766001)(80022001)(16236675002)(71186001)(20776003)(4396001)(53806001)(54316002)(77096001)(74366001)(6806003)(81542001)(65816001)(74502001)(74662001)(69226001)(81342001)(74706001)(66066001)(54356001)(561944002)(76786001)(79102001)(512934002)(77982001)(76796001)(46102001)(51856001)(56776001)(47446002)(31966008)(49866001)(63696002); DIR:OUT; SFP:; SCL:1; SRVR:BN1BFFO11HUB007;; CLIP:; RD:InfoDomainNonexistent; MX:1; A:1; LANG:en;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0881A7A935
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: Tue, 18 Jun 2013 01:46:38 -0000

Inline below

Matthew Kaufman

From: [] On Behalf Of Roman Shpount
Sent: Monday, June 17, 2013 3:04 PM
To: Iñaki Baz Castillo
Cc: <>
Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

On Mon, Jun 17, 2013 at 5:56 PM, Iñaki Baz Castillo <<>> wrote:

What is the aim of NoPlan? The draft says "This document does not
question the use of SDP and the Offer/Answer model". Why? It should
question it since it treats SDP as if it was a silly and unmanageable
binary blob. It is like "we must live with SDP because it is
mandatory, but let's try to ignore it as much as possible". If so, why
don't ignore SDP entirely?

However NoPlan is the best we have if, finally, SDP is mandated in WebRTC.

I think it is time to write two lists:

1) Advantages of using SDP in WebRTC.

Somebody wrote a bunch of code based on JSEP.

MK: And some other people thought that using SDP offer/answer would magically get full interoperability with existing SIP+SDP O/A systems.

2) Dissadvantages of using SPD in WebRTC.

An unmanageable monster was created which currently stays in the way of developing new functionality (bundle), building applications (does not provide obvious ways to implement obvious tasks, like adding an extra stream without re-negotiating all the existing ones) and even interop with existing SIP endpoints (which was the original but now is complicated since it would require a non trivial set of constraints and subsequent SDP manipulation).

MK: Pretty much sums it up, including the fallacy of SIP interop. And note that the SIP interop issue isn't just that there's no SIP systems that have ICE (which we need to protect people from their browser) and DTLS-SRTP (which we need if we don't get SRTP w/SDES)... in fact there's a draft summarizing many (but not all) of the *other* things that don't interoperate between the two without SDP mangling.


Roman Shpount