Re: [rtcweb] New Draft - WebRTC JS Object API Model

Robin Raymond <> Tue, 02 July 2013 12:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 422A611E810F for <>; Tue, 2 Jul 2013 05:23:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.398
X-Spam-Status: No, score=-2.398 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eCnWKzZzTMoD for <>; Tue, 2 Jul 2013 05:23:04 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B00E811E80A2 for <>; Tue, 2 Jul 2013 05:23:04 -0700 (PDT)
Received: by with SMTP id 10so12292833ied.0 for <>; Tue, 02 Jul 2013 05:23:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=sn42e4QrmF1y1E909jtPVA1+5uvJN6jPqnzgDZxnymE=; b=IBtIrwtIqjTATg4FGocoebW8A/vB6q/LyTNP3KeE9ZpBKyBMqWDLUqg5/wPztpxHL4 q+BKGQG12mQnN4HgTtJbYIk9rLKpmJh7tFopSsoqC0rCzuM++MqGHp9cnIYnCiBYXs/j 8m4DdXenmOLRG3pGPoJiLIYIxq5sH7bzl08jkhr3i6cYHD/x0m/lIGI8tt7g2WEM6e+E cMTy9fpDIznd1AQah+8f9GZpi61zjigMJ+sBCA9hR/4sHFsURTu1vvoTBnM74GNeSQJf +SfyDctDT+gVZF46MvGcRM6TytPHNQ1ijMcoUewtVSFXUfoJ3kDJIni74M5V6u5xpkJk iDWQ==
X-Received: by with SMTP id im4mr20664145igb.1.1372767783964; Tue, 02 Jul 2013 05:23:03 -0700 (PDT)
Received: from Robins-MacBook-Pro.local ( []) by with ESMTPSA id kj5sm18104323igb.7.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 02 Jul 2013 05:23:02 -0700 (PDT)
Message-ID: <>
Date: Tue, 02 Jul 2013 08:22:58 -0400
From: Robin Raymond <>
User-Agent: Postbox 3.0.8 (Macintosh/20130427)
MIME-Version: 1.0
To: Tim Panton <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------080109050809070304050709"
X-Gm-Message-State: ALoCoQl5Yx8pLlM3Ctu2FiQMkdNpBkmB53rC0iJiRJR4evcFQo7Y3BKp3cj89Z0Va+DOg97L0+Mg
Cc: "" <>
Subject: Re: [rtcweb] New Draft - WebRTC JS Object API Model
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, 02 Jul 2013 12:23:09 -0000

You are absolutely, there are  a lot of details. But splitting the 
details into logical separate components reduces the overall complexity 
greatly. Plus many of those details are only needed because of a lack 
ability to properly describe the concept of "streams" at the lower level 
RTP layer (which really only supports tracks at best, and lacks 
sufficient details to coordinate any information between them to 
reassembly remotely as a "stream"). So we are left in a situation where 
the high layers must coordinate a lot of information to be capable of 
reassembling the streams when they really should be just negotiating the 
capabilities of the RTP layer itself.

For example, the only thing that should be needed is a flag that says 
FEC is available in the signaling for the the RTP layer. If it is set 
then that would imply the engine supports this feature and thus FEC 
streams may be created by the sending party. Alas, because RTP lacks 
sufficient depth for such concepts like FEC, you have to signal it. RTP 
doesn't even have enough information to reassemble tracks into stream, 
let allow do things like FEC between them.

Having said that, by making a scoped object that understands there is 
some definition of what a stream means needs to be describes, but 
perhaps that the "future' may not require such crazy definitions like 
all the stream/ssrc/track mappings, it allows for a short/long-term 
temporary situation where stream definitions are passed until we are 
able move to a model where that is no longer needed. When a theoretical 
next-gen RTP transport is capable of sending entire streams and 
reassembling them without explicit signaling from an upper layer, we can 
stop defining all that mapping stuff in signaling and remove that 

Basically, it's about scoping the objects, and limiting the requirements 
needed to exchange per object, and defining exactly what is 
expected/required in those definitions and allowing for future 
alternative objects that could replace current ones (if they should 
become available). The other important aspect is removing the definition 
how this information must be coordinated and exchanged to allow for a 
variety of signaling scenarios and alternative state machines. And 
keeping it relatively simple is important for the simple use cases too 
so the burden is low. We are well on our way to producing such a draft 
in short order that does exactly that.

All we ask is that people keep an open mind. We have no desire to 
prevent SDP or offer/answer, just not mandate its usage as an API model.

Make sense?


> Tim Panton <>
> 2 July, 2013 4:31 AM
> On 2 Jul 2013, at 08:21, Stefan Håkansson LK wrote:
> Conversely we shouldn't underestimate (again) the difficulty of 
> describing all the
> nitty gritty details in SDP.
> I have the sense that we may have pushed the flexibility of SDP beyond 
> it's elastic limit.
> I think that over the last year we have discovered that a dynamically 
> programmable browser
> is a fundamentally different beast from a deskphone and that what 
> suits one may well not suit the other.
> Tim.
> _______________________________________________
> rtcweb mailing list