Re: ReplaceTrack - need to evaluate alternatives

On 4/13/15 4:51 AM, Harald Alvestrand wrote:
> 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, 

I believe both proposals speak to that [1][2]:

"If no negotiation is needed, then have the sender seamlessly switch to 
transmitting withTrack in place of what it is sending, without 
negotiating. *On the remote receiving end, the track maintains its 
existing grouping and id until the connection ends or a renegotiation 
happens, whichever is sooner.* If a renegotiation happens, then the 
remote receiver /SHOULD/ use SSRCs to detect tracks that have been 
renamed in this manner, and update their ids and groupings, rather than 
treat them as new tracks."

Best case: nothing happens remotely except the remote sees the new 
content the sender is sending in place of the old, seamlessly.

> but I'm not sure what would happen in the "signalling" case.

In the signaling case, replaceTrack would be the equivalent of 
removeTrack/addTrack with the same stream args, but with the same sender 
in place. Not exciting I hope. I was going to lift detail from addTrack 
but didn't find much. I'm happy to add text similar to addTrack if 
someone can point me to it.

> We have to decide:
>
> a) whether the proposals are complete enough to evaluate or not

Thanks for posting Harald. Yes everyone please evaluate! Let us know if 
there are things you think needs to be clarified or made more explicit.

> b) whether the proposals' suggestions for how to handle signalling is 
> the right one

The model for RtpSender as a whole seems to be to allow changes locally 
and have negotiationneeded fire in response only when needed. 
ReplaceTrack follows that model.

"Track-renaming" on the receiver of subsequent renegotiation, is new. 
Please comment.

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

The latter returns a promise, is the only difference. The promise lets 
you learn when the new track is sending, whatever that means. I suppose 
it would allow for implementations to do some of the work that might 
fail asynchronously. The reason I'm a little fuzzy on this is that 
Firefox's current implementation is synchronous.

> Comments welcome!
>
>           Harald

.: Jan-Ivar :.

[1] 
http://htmlpreview.github.io/?https://raw.githubusercontent.com/jan-ivar/webrtc-pc/replacetrack/webrtc.html#methods-3
[2] 
http://htmlpreview.github.io/?https://raw.githubusercontent.com/jan-ivar/webrtc-pc/sendertrack/webrtc.html#attributes-6