Re: API changes to clarify ICE/SDP split, and align with MediaStream mapping

On 09/23/11 09:40, Stefan Håkansson LK wrote:
> On 2011-09-22 22:51, Timothy B. Terriberry wrote:
>> Harald Alvestrand wrote:
>>> I concluded from that discussion that we can say that all tracks in a
>>> MediaStream share a CNAME, but we can't say that all tracks with the
>>> same CNAME go to the same MediaStream.
>>
>> So what happens when a stream is added, with the same CNAME as a set of
>> existing streams? The current API has callbacks for adding/removing
>> MediaStreams, but not individual tracks within a MediaStream.
>>
> I think we need to separate things that is observable in the API and 
> what happens at the SDP/RTP level.
>
> IMO, each MediaStream should have an identifier so that it can be 
> referenced when transmitted over a PeerConnection. The current API 
> draft has the "label" attribute for this purpose. So the web app 
> developer works with MediaStreams.
>
> CNAME, SSRC, RTCP, ... is to me tools used in the transport over a 
> PeerConnection to make sure that what should be in sync is in sync and 
> so on - nothing the web developer should know or care about. In 
> addition they will probably be used, perhaps in combination with 
> something additional, to convey the label attribute of the MediaStream 
> in some way.
>
> There may be situations when one track is part of two or more 
> MediaStreams that are sent over the same PeerConnection. A natural 
> optimization would be that that track is on an RTP level actually only 
> sent once (i.e. only one RTP stream), but this is not visible to the 
> web app.
Since we can create one MediaStream from another MediaStream, it is 
completely logical to have one track as part of multiple MediaStreams.

We may conclude that per-SSRC labels need to be a set (indicating the 
set of MediaStreams it is intended to be part of), not unique per SSRC. 
That would make the SDP parsing/generating code slightly more complex.

Received on Friday, 23 September 2011 08:27:53 UTC