Re: Next steps on RTCRtpSender "doohickey" proposal

On 2014-05-08 09:46, Harald Alvestrand wrote:
> On 05/08/2014 09:43 AM, Stefan Håkansson LK wrote:
>> On 2014-05-08 08:07, Harald Alvestrand wrote:
>>> (as contributor) +1 from me.
>> Ditto.
>>> One nit: The following should be legal:
>>> addTrack(track, streamId1)
>>> addTrack(track, streamId2)
>>> this means that one track should be presented to the receiver as part of
>>> two streams.
>> I still think that conveying the MediaStream(s) a track belongs to using
>> SDP adds unnecessary complexity to the API and the solution.
>> But if we should, why not make the second (and optional) argument to
>> addTrack a list of streamId's instead (I proposed that in [1])?
>> If you can call addTrack several times with the same track as first
>> argument but different streamId's, what should happen at the far end if
>> you carry out an SDP O/A between the calls?
> The same thing as happens when you add two different tracks and do an
> SDP O/A between them: The SDP O/A reflects the state at the moment the
> CreateOffer / CreateAnswer is called.

I thought what would happen after the SDP O/A is carried out is that 
there is an addtrack event fired at the remote PC. I just thought it 
would be confusing to get a new event, with the same track, but a new 
stream Id. Maybe I'm wrong.

But now we're going half-way; we build a solution where you can add a 
Track to as many Streams as you want, and have that be reflected at the 
far end, but you can never remove a track from a stream and have that be 

> This is needed to make it possible to polyfill AddStream without adding
> a bunch of special cases.

I think the vast majority of apps needing polyfill send only one 
MediaStream, and then there is no need to carry the StreamId over via 
API and SDP.

Received on Thursday, 8 May 2014 07:56:53 UTC