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

Martin Thomson <> Mon, 17 June 2013 21:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1A5A021F9CD0 for <>; Mon, 17 Jun 2013 14:56:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.519
X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5FoLANV21TFP for <>; Mon, 17 Jun 2013 14:56:19 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::233]) by (Postfix) with ESMTP id 488A521F9CCF for <>; Mon, 17 Jun 2013 14:56:19 -0700 (PDT)
Received: by with SMTP id e11so2810481wgh.18 for <>; Mon, 17 Jun 2013 14:56:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=q5xvj9jtFVmnm/yltEEkbfWzuyIUfCHOFuXIoEMyzU4=; b=oqw9L3VGLOrOSnQ/dTIo0I8Sq3KrqK8/EvZ17J2ics15L924IAmu2Pvj24x+C3271b 4CNp+vDuRB3KLaun1L4B9HY40DUUK3UpdLr4tM+Y/GCcXGd5ca1DRcx/ArVpGTR7MpEM PsEL9AGcGw0ldBuLbJousZHsu2kbchEwM39VseLp3plXPeZx9gz/1rauGBSVfmlelK0x fdTk8N/V0023G0AWaI5p5PrJSNx0Zg8KaJQBIMUxym2XqBe6670pBP45lXB6doKU4aoV CF7kS8BnyZaBTGZB3QVTlpDrqhlcyzJFX9Rr8sgsE8vgNv4htD18m1Ynkgmd8zHyEP7t rFuw==
MIME-Version: 1.0
X-Received: by with SMTP id k14mr6003913wie.14.1371506178439; Mon, 17 Jun 2013 14:56:18 -0700 (PDT)
Received: by with HTTP; Mon, 17 Jun 2013 14:56:18 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Mon, 17 Jun 2013 14:56:18 -0700
Message-ID: <>
From: Martin Thomson <>
To: Peter Thatcher <>
Content-Type: text/plain; charset=UTF-8
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: Mon, 17 Jun 2013 21:56:20 -0000

On 17 June 2013 12:26, Peter Thatcher <> wrote:
> Yes, I was expecting you to be more supportive.  I'm surprised out how your
> want "all or nothing".  I'm afraid if our options for a clean API are all or
> nothing, we'll just end up with nothing.  I'd prefer to try incremental
> improvements to word toward (eventually) a clean API.

Yes, I apologize if the language seemed strong, but I stand by those words.

The problem that I see with this, and it is a problem with any
incremental approach, is that it produces two very different
interaction models for things that are approximately the same
fundamental operation.

That is, when I add the first video track to a session I perform one
set of actions.  Then, when I add subsequent tracks, it's different.

This also has all the purported drawbacks of comment 22 with respect
to usability, whatever they are.  There must have been some because I
got a lot of heat about that when we discussed it.

> Do you think it is impossible to work toward a clean API in an incremental
> approach?  If you think it's possible, I'd like to hear your thoughts on
> how.

The fundamental problem in WebRTC is the Offer/Answer semantics in the
API.  That's hard to remove now.  I can't see an incremental change
that would remove that, and that's every bit as much of a problem as
having to deal with SDP.  That's how we got to comment 22.

I know that you wanted to do some sort of object representation of
SDP.  That can be done incrementally by adding to
RTCSessionDescription, or by replacing it entirely, but it doesn't
really go to the core of the problem.  If you were willing to tolerate
the fact that there would be two code paths, two control surfaces that
effectively did the same things.

> By the way, these API additions would greatly minimize the amount of SDP
> editing necessary for JS clients that don't use SDP for signalling.  And
> later incremental improvements could reduce it further.  Also, it's no
> longer necessary to do offer/answer for adding tracks.  It's only the intial
> PeerConnection setup that needs to do Offer/Answer.  So, it doesn't inherit
> all the problems quite as much as you described.  It may be slightly
> abominable, but I certainly consider it less abominable than the SDP editing
> necessary without it.

If I am forced to do SDP, I'd rather not have something else as well
unless that something else is getting me something concrete.  What you
are proposing does too little to advance a cleaner API model to
justify the extra overhead that it introduces.  It doesn't tackle the
hard problems.

I appreciate the philosophy behind no-plan, which is not a non-plan in
any sense.  It addresses a concern that we (unfortunately) didn't
really touch on in the MMUSIC call this morning.  However, the
requirements of the-not-no-plan could be far more elegantly addressed
within the constraints of the current API without adding all those
extra description bits.