Re: Summary of replace track status

Den 23. mai 2015 14:43, skrev Eric Rescorla:
> 
> 
> On Fri, May 22, 2015 at 5:51 PM, Jan-Ivar Bruaroey <jib@mozilla.com
> <mailto:jib@mozilla.com>> wrote:
> 
>     On 5/22/15 6:09 PM, Peter Thatcher wrote:
>>     Thank you for the example.
>>
>>     I don't view that as "needs renegotiation" as much as "the
>>     RtpSender was configured to send in a codec it's not capable of
>>     sending".  Once we, someday, have direct  control of RtpSenders
>>     (sans SDP), the browser would basically view this as "JS told me
>>     to do something I can't do".
> 
>     Or hopefully "something I can do". I hope getting rid of
>     SDP-renegotiation will mean getting rid of the need for it, rather
>     than getting rid of what it provides. ;)
> 
>     +1 on replaceTrack not triggering renegotiation, since the whole
>     reason for its existence is to avoid renegotiation. Therefore,
>     people would probably rather it fail than trigger renegotiation, or
>     they would have used addTrack/removeTrack. It's also easy enough to
>     fall back to addTrack/removeTrack if so desired.
> 
> 
> I don't agree with this conclusion. It violates POLA to have it fail
> like this and is going to cause random, unpredictable failures in the field.


POLA - Principle of Least Astonishment?

Thinking about this some more..... if replaceTrack can cause a state
that needs something else to happen before we can start sending the new
track, and if we want to keep the "smooth transition" between the old
track and the new track at the receiver side, it means that after
replaceTrack, the PC will have to keep on sending the old track "for a
while".

Given that the app then has to know whether or not it can safely
disconnect the old track, it means that replaceTrack has to return a
promise, which would resolve to success at the time the app can stop the
old track (if it wants to), because it is no longer going out. What
failure cases can exist here is left as an exercise...

FWIW, I don't agree that replaceTrack's purpose is to avoid
renegotiation. My understanding has been that the point is to replace
the input without the recipient needing to take any action.

(BTW: If people use datachannel-based signalling for renegotiation
rather than signalling through a server, the speed of renegotiation is
limited only by the speed of the UA implementation. It doesn't have to
be slow.)

Received on Monday, 25 May 2015 07:41:18 UTC