Re: Update of RTCRtpSender "doohickey" proposal

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.


On Mon, Apr 28, 2014 at 7:19 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 28 April 2014 16:51, Justin Uberti <juberti@google.com> wrote:
> > I thought about it a bit, and I don't really see an issue with making it
> > arbitrary. This will put the track to be in the specified MS at the other
> > side, but I don't see a need to force the tracks to be bagged up on the
> send
> > side.
>
> Why not just put the stream in, not its identifier and avoid the issue?
>
> As for the null case, generate a new stream on the remote side for
> every track that is added that way.
>

Received on Tuesday, 29 April 2014 06:12:03 UTC