Re: Update of RTCRtpSender "doohickey" proposal

On 29/04/14 18:50, Martin Thomson wrote:
> On 28 April 2014 23:11, Justin Uberti <> wrote:
>> The issue could still exist if you do addTrack(T, S) and then later
>> S.removeStream(T). We might prefer taking the stream directly for
>> syntactical reasons, but I don't think it avoids the core issue.
> That's fine; the stream configuration on the receiving end always lags
> the configuration at the sending end.  I'm just not convinced that we
> need a way to specify identifiers in this way, Harald's speculation on
> rehydration notwithstanding.

In principle we can have the situation that a track added to the PC is 
member of several MediaStreams on the sending side. Should the "stream" 
argument be a list (regardless of it is a list of MS objects or MS 


Received on Friday, 2 May 2014 06:12:38 UTC