Re: ReplaceTrack - need to evaluate alternatives

On Mon, Apr 13, 2015 at 1:51 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> <chair hat>
> At the October 2014 TPAC, we had a presentation on the proposed
> ReplaceTrack function.
>
> Despite some misgivings (OK, a lot of them mine) about the way
> ReplaceTrack works with the identifiers of tracks, the WG decided to go
> ahead with adopting ReplaceTrack, and asked for a complete proposal.
>
> At the moment, we have two proposals for ReplaceTrack or equivalent up as
> pull requests, both by Jan-Ivar.
>
> The two proposals are:
>
> https://github.com/w3c/webrtc-pc/pull/195 - RTCRTPSender.ReplaceTrack(MediaStreamTrack
> withTrack)
>
> https://github.com/w3c/webrtc-pc/pull/196 - RTCRTPSender.track attribute
>
> Both proposals suggest that the action of replacing a track either fires
> negotiationnneeded or "just switches". Neither proposal says what happens
> to the identifiers on the receiving side - presumably they would be
> unchanged in the "no signalling" case, but I'm not sure what would happen
> in the "signalling" case.
>
> We have to decide:
>
> a) whether the proposals are complete enough to evaluate or not
>
> b) whether the proposals' suggestions for how to handle signalling is the
> right one
>

​The more I read the discussion, the more I think it's a mistake to be
signalling MediaStreamTrack.ids at all.  There's just too much complexity
for too little gain.  Like Justin and Martin have suggested, I think we
need to change our thinking to having and our IDs or labels on RtpSenders
and RtpReceivers, not tracks.  I think we should signal IDs or labels for
RtpSenders, not tracks.

As I suggested in another thread, I think there is a good comparison to be
made with RTCDataChannel and createDataChannel.  The JS provides a label
for the channels, not the "source" of where the data comes from.
Similarly, I think we can simplify things a lot by labelling the RtpSender
and RtpReceiver, not the "source" where the media comes from.


> c) if we prefer the "replaceTrack()" or ".track" representation of the
> functionality.
>

​As I suggested on the other thread, I prefer replaceTrack (or setTrack).
I think ".track = " would be a mistake.​



>
> Comments welcome!
>
>           Harald
>
>
>