Re: Summary of replace track status

On Mon, May 25, 2015 at 12:40 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

> 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?
>

Yes.



> 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...
>

This seems like a pretty big change in the semantics of the API in general,
and I'm not sure it's necessary for this case. If we're going to bother
putting
this logic into the PC, wouldn't it mostly cover this case to have it just
hold
a strong reference to the original track until the renegotiation succeeds
and
then release it, at which point it will be garbage collected.

I recognize that this is somewhat less flexible in the sense that the app
doesn't know what's happened and so can't (for instance) change the
self-view, but I think that's a price I'm willing to pay for API simplicity.

-Ekr