Re: ReplaceTrack - need to evaluate alternatives

On Mon, Apr 13, 2015 at 10:34 PM, Randell Jesup <randell-ietf@jesup.org>
wrote:

>
>  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.
>>
>
> So long as we maintain the ability to not cause negotiation-needed except
> when actually required, this is good for me.  I want the be able to change
> what I'm pushing into the pipe without a negotiation delay (and failure
> modes, and ability for the other side to reject, etc).  For example when
> using it to mute/unmute a camera with a slate or anim/video, or to swap
> which local camera I'm streaming - I want the switch to happen now, not
> X-hundred ms from now (assuming all agree), and also avoid possible
> glitching/etc from the negotiation resolution.  (I'm just re-iterating the
> discussion from the interim, with much less detail.)
>
> This is especially important as we don't have the Video equivalent to
> WebAudio that could "hide" all these manipulations between a source and
> where it goes into a PeerConnection.
>
>
>>  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.
>>
>
> I'm good with either; at this point I don't see need for a promise, but
> predicting the future (and other people's impls) is hard.
>
>
The argument for a promise is that (assuming you want a seamless switch)
you want to know when the switch has completed and you can stop the old
track.

Note though that this makes the negotiation case difficult; I don't think
it makes sense to not resolve the promise until after negotiation has
completed, so you would need some sort of EPENDING indication to say that
the operation is still unresolved.

Generally, I think the scenario where replaceTrack can't complete without
negotiation is complex enough that we should disallow it, at least for now.
We should have the promise resolve with an error instead in this case. The
app can still do removeTrack/addTrack if it really wants to.