Re: [rtcweb] No Plan

Stefan Håkansson LK <> Thu, 30 May 2013 08:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A24921F9726 for <>; Thu, 30 May 2013 01:24:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 21z+R4VuxUzE for <>; Thu, 30 May 2013 01:24:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EBA4121F972C for <>; Thu, 30 May 2013 01:24:30 -0700 (PDT)
X-AuditID: c1b4fb30-b7f9e6d000002643-bd-51a70cbd9f24
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 19.25.09795.DBC07A15; Thu, 30 May 2013 10:24:29 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id; Thu, 30 May 2013 10:24:29 +0200
Message-ID: <>
Date: Thu, 30 May 2013 10:24:28 +0200
From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCJMWRmVeSWpSXmKPExsUyM+Jvre5enuWBBgfuy1ms/dfO7sDosWTJ T6YAxihum6TEkrLgzPQ8fbsE7owPb78wFRwWqZj/6xRrA+NmgS5GTg4JAROJKxPmskLYYhIX 7q1n62Lk4hASOMUoceP6cyYIZw2jxKwPvWBVvALaEo92nWACsVkEVCV6zj4Cs9kEAiWu//8F ZosKREnMWfeADaJeUOLkzCcsILaIgLDE1le9YDXCArIS167PAKsREtCQWP1jMXsXIwcHp4Cm xL5tjCBhZgFbiQtzrrNA2PIS29/OYYYo15V49/oe6wRGgVlINsxC0jILScsCRuZVjOy5iZk5 6eXmmxiBgXZwy2+DHYyb7osdYpTmYFES59XnXRwoJJCeWJKanZpakFoUX1Sak1p8iJGJgxNE cEk1MAo1l1SyB69codSU4u7uGK/gp3R2Spji5Iy2ldMma7xnLa78pMQhbNueuKHdXnL9cc6/ gltZliz37yzZYbXvcDtDnK2qdUzoTVP7D1+VqoVlLkWrn093fHO7cOUpPzVTbksXUYGZx7k3 /4j/EPfkZApfnsrHTU1FrPeqOeNnR6T39FkLzpmixFKckWioxVxUnAgArguNlwcCAAA=
Subject: Re: [rtcweb] No Plan
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: Thu, 30 May 2013 08:24:38 -0000

Hi Emil,

a couple of comments:

"1.  Expose the SSRCs of all local MediaStreamTrack-s that the
        application may want to attach to a PeerConnection."

I don't think that would be possible, or desirable. SSRC _only_ come 
into play when a MediaStreamTrack is to be transported over the network 
- it is useless in local cases. And, the same local MediaStreamTrack 
could be sent to several peers (using different PeerConnections) and 
could have different SSRC's (and even different number of SSRC's) for 
the different peers.

I think SSRCs would only be available for MediaStreamTracks that are 
attached to a PeerConnection.

One thing I like about Plan A and B is that the naive application 
developer does not have to deal with things below MediaStream and 
MediaStreamTrack level. The application would simply add a MediaStream 
(containing MediaStreamTracks) to the PeerConnection, do the 
createOffer/setLocal and exchange signaling blobs that it need not look 
into, and the MediaStream with MediaStreamTrack's would be reflected at 
the remote end. The application would not have to deal with PT's, SSRC's 

I think that the "No Plan" proposal could be made similar if the info 
about how MediaStreamTrack's relate to SSRC's (including those for FEC 
and RTX) is exchanged using some blobs that the (naive) app can just 
exchange and need not look into.

If done that way, "No Plan" seems to me to be quite similar to Plan B, 
with the difference being that the info about how SSRC's relate to 
MediaStreamTrack's is exchanged not in the core SDP but in separate 
messages. This could be seen as an improvement I think.


On 2013-05-29 20:59, Emil Ivov wrote:
> Hey all,
> Based on many of the discussions that we've had here, as well as many
> others that we've had offlist, it seemed like a good idea to investigate
> a negotiation alternative that relies on SDP and Offer/Answer just a
> little bit less.
> The following "no plan" draft attempts to present one such approach:
> The draft relies on conventional use of SDP O/A but leaves the
> intricacies of multi-source scenarios to application-specific
> signalling, with potentially a little help from RTP.
> Hopefully, proponents of Plans A and B would find that the
> interoperability requirements that concerned them can still be met with
> "no plan". Of course they would have to be addressed by
> application-specific signalling and/or signalling gateways.
> Comments are welcome!
> Cheers,
> Emil