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