Re: Summary of replace track status

On Fri, May 22, 2015 at 6:19 AM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> 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?
>
>
That seems a very good summary to me, and pretty much exactly matches what
I recall that we came up with back at TPAC.  I support it.​



> 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?
>
>
​I'm in support of RtpSender.id, and of making it MID if it's possible
(which it might not be), and I agree it should be a separate issue from
 RtpSender.replaceTrack and we can finish replaceTrack and handle the id as
a separate issue.

I can make this RtpSender.id issue if we don't already have one.  I think
the question of which ID that ID is (MSID or MID) should probably go along
with it.  Or is there a good reason to have a separate issue?



> * 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?
>

​I don't recall of the top of my head any situation in which replaceTrack
could trigger a renegotiation.  Perhaps if we had some scenarios were we
thought that might come up, we could know how long it would take to
detect.  Does anyone have any concrete examples?



>
> Stefan
>
>