Re: ReplaceTrack and track.id (Re: ReplaceTrack - need to evaluate alternatives)

I think the first approach is the most sensible one, and fits with the
discussion at IETF Dallas regarding MSID.

Basically, when you add a track, and thereby generate a new RtpSender, the
"track id" associated with the sender is fixed for the lifetime of the
RtpSender. So if A sends X, and then later does replaceTrack to send Y,
this doesn't change anything for media or future signalling.

In essence, this means that MSID really serves as the id of a RtpSender. If
you want to change the id, removeTrack + addTrack to get a new RtpSender.

On Tue, Apr 14, 2015 at 11:19 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> Contributor hat on....
>
> I'm worried about the idea that tracks have IDs that vary over time, and
> that the change in the ID is not correlated with the change in content.
>
> In particular, the scenario (-> = signalling)
>
> A -> B: I send video track with id X
> B -> A: OK, I can receive
> B gets a video track with id X
>
> A sends the content of X
>
> A decides to send the content of Y instead, and does ReplaceTrack
>
> B receives the content of Y, but associates it with id X
>
> At some later time, A decides that negotiation is needed:
>
> A -> B: I send video track with id Y (where X was before)
> B -> A: OK, I can receive
>
> What happens next?
>
> Either of these is a self-consistent description, but they're mutually
> exclusive:
>
> - B simply never updates the ID of the track. X is a perfectly valid
> identifier, and if A wants to talk about it, A can take on the task of
> remembering that it has to say "X" when talking to B about this video, even
> though its local track has id Y. (This is the simplest solution. I like
> simple.)
>
> - B updates the ID of the track when signalling happens. A has to remember
> that it must use X when talking about the track before signalling, and Y
> afterwards. (I think this is what Jan-Ivar's pull requests state now).
>
> - B takes the signalling as an indication that track X has stopped and
> track Y (a new track) has started. It has actually been receiving Y-content
> on track X for a while, but has no way of knowing that, so it has to tear
> down the X-association and establish the Y-association (perhaps replacing
> the track in its MediaStream, so that it remains connected to the same
> <video> or other sink?) (this is the most convoluted. I don't like
> convoluted.)
>
> I think we have to pick one.
>
>
>