Re: Next steps on RTCRtpSender "doohickey" proposal

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.

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