Summary of replace track status

Hi,

the discussion on replace track covered a lot of things, some that are 
not related to track replacement per se. I would like to break things 
down a bit to see if there are some things we can agree on, and get into 
the spec, while the discussion on other items continue.

My interpretation is that we have consensus regarding:

* sender.replaceTrack(new_track) (as opposed to e.g. setTrack) as API model

* The identifier at the remote end can remain unchanged, i.e. for the 
sequence
	senderX = pc.addTrack(X);
	senderX.replaceTrack(Y);
the Id at the remote end would stay unchanged

* If the track switched to cannot be sent without a renegotiation,
replaceTrack should fail, and the original track (X) would continue to 
flow.

Is there anyone not aboard with the above?

There are aspects are still open as far as I can tell:

* Id at remote end: this Id is intended to enable the application to 
refer to the right track (e.g. Id A is participant X's video, Id B X's 
audio etc.). Up to now that has been the MediaStreamTrack Id (which must 
be carried over), but I've heard arguments that we should instead have a 
sender-receiver Id. Both would solve the reference problem.

* Id, MID and MSID: there was a long discussion around this, but it 
seemed to be related to add/removeTrack and m-line recycling rather than 
replaceTrack. Could someone file an issue describing this problem so we 
don't forget it?

* Detection/reporting of that negotiation would be needed: as said 
above, there seem to be consensus of that if the new track (provided by 
replaceTrack) would require a re-negotiation, replaceTrack should fail. 
How quickly can this be detected? How should it be reported back to the 
application?

Stefan

Received on Friday, 22 May 2015 13:19:54 UTC