Re: replaceTrack proposal

On 03/09/14 20:34, "Martin Thomson" <martin.thomson@gmail.com> wrote:

>On 3 September 2014 11:31, Peter Thatcher <pthatcher@google.com> wrote:
>> If the sender changes to a different local source of media, what does
>> the receiver need to know about it?  Could we simply changing nothing
>> (no renegotiation or change of identifiers), and just treat it at as
>> purely sender-side change?    I suppose that may mean what appears as
>> Track A to the receiver actually comes from Track B on the sender.  Is
>> this a serious problem?  Are there other problems that you see?  It
>> doesn't seem like a big deal to me.
>
>
>I was always of the opinion that copying the stream and track
>identifiers through was a bad idea.  We probably needed to add a new
>sort of identifier for correlation purposes rather than try to
>superimpose two namespaces like we have.

The main purpose of the id's has for me always been to be able to
reference tracks at the remote end. Let's say that two video tracks show
up simultaneously (set up with the same SDP O/A), the app at the remote
end must be able to reference them (to show in the right video element).

It does not really matter if we use the current id's, or something new
(though I wonder what the use case can be for local only id's). With the
RTPsender (hm, where is that pull request?) we have the API surface for
the app to give a "remote id" for a track, and swapping the track for
another at the sending and would not affect the id at the remote end.


>
>So this works perfectly well, if you are OK with essentially removing
>the identifier requirements we have already agreed to.

I guess there must be some kind of id, or how should getTrackById work at
the remote end? But it does not need to be the same as on the sending end,
so personally I'd be fine with changing.

>