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

Harald Alvestrand <> Wed, 19 June 2013 16:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 47C6C21F9A12 for <>; Wed, 19 Jun 2013 09:04:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.548
X-Spam-Status: No, score=-110.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u8raZ+l6AGXt for <>; Wed, 19 Jun 2013 09:04:05 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 84B5C21F9A65 for <>; Wed, 19 Jun 2013 09:03:26 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0092139E128 for <>; Wed, 19 Jun 2013 18:03:25 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id q15Y0SxFknwU for <>; Wed, 19 Jun 2013 18:03:23 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTPSA id BE86439E0E1 for <>; Wed, 19 Jun 2013 18:03:23 +0200 (CEST)
Message-ID: <>
Date: Wed, 19 Jun 2013 18:03:22 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------030806070207030803010706"
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: Wed, 19 Jun 2013 16:04:11 -0000

On 06/19/2013 05:15 PM, Peter Thatcher wrote:
> On Mon, Jun 17, 2013 at 6:00 PM, Silvia Pfeiffer 
> < <>> wrote:
>     Hi Peter, all,
>     I'm looking at all this from the view of a JS developer and I am
>     really excited that there is movement in this space. Having hit my
>     head hard against the limitations of the current WebRTC API and being
>     forced to learn SDP to achieve some of the less common use cases, I'm
>     feeling the pain. I am therefore happy to see that there is a proposal
>     for a higher-level API with similarities to the Microsoft's CU-WebRTC
>     proposal and I hope that together with Microsoft's input this can
>     become a really useful API.
> I hope so as well.  Unfortunately, Microsoft's input seems to be "our 
> way or the highway" and the input of others seems to be "SDP ought to 
> be enough for anybody".  My thinking is that we can make incremental 
> improvements toward a cleaner API without being so extreme at either 
> end.  And I hope I can find others that think similarly.
>     What I would like to see, though, is a bit different from what you've
>     proposed. In particular, the MediaFlowDescription object is the one
>     object that I believe is supposed to enable JS developers to  do "SDP
>     hacking" without having to understand SDP. Unfortunately, the way in
>     which it is currently written, this API doesn't help a JS developer
>     much. There are properties in that object like "ssrc" that mean
>     nothing unless you understand SDP.
> Actually, it helps some JS developer a lot.  It happens to be very 
> good for the JS I am writing :).

And it might be really obvioius and come across as really condescending, 
but there's absolutely no way anyone can write sensible code to control 
the parameters of transmission or encoding without understanding how 
that controlling affects the transmission or encoding.

Thus, as long as one uses RTP, one needs to understand concepts like 
payload types, SSRCs, RTP sessions, RTCP feedback and so on - OR accept 
that one programs to a higher level abstraction where these attributes 
are not visible, and accept that one does not have control over them.

In some cases, interfaces can be made with "options" - so that if one 
doesn't care, one gets a sensible default, and if one does care, one can 
get detailed control - but sometimes, one has to pick the level of an 

I'd like to think that we recognize that these tradeoffs have to be made.