W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2015

Re: Summary of replace track status

From: Jan-Ivar Bruaroey <jib@mozilla.com>
Date: Mon, 25 May 2015 08:37:43 -0400
Message-ID: <55631797.4020107@mozilla.com>
To: Harald Alvestrand <harald@alvestrand.no>, Eric Rescorla <ekr@rtfm.com>
CC: Peter Thatcher <pthatcher@google.com>, Adam Roach <adam@nostrum.com>, Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On 5/25/15 3:40 AM, Harald Alvestrand 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.

I think this is a good point. If we think of renegotiation as a 
lower-level detail exposed only for its unfortunate need of the JS 
signaling channel, then it follows that the semantically higher-level 
RtpSender API should invoke the lower-level API as needed. This matches 
the existing RtpSender language in the spec, and replaceTrack, or indeed 
sender.track which people rejected - though people aren't always right - 
would work consistently with all other sender attributes, 
notwithstanding the need to figure out some way to learn when the old 
track can be freed (interestingly, you learn this from 
pc.icesignalingstate when renegotiation is employed).

(I'm using "higher-level" and "lower-level" based on semantic distance 
from user-intent here, which perhaps seems backwards from the 
technological organization we have today. But if we acknowledge that an 
ideal API would not expose onnegotiationneeded at all, then it is 
perhaps clearer that it's the technology that is backwards right now).

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

Idea: The implementation could "clone" the old track and close it 
separately from the user once it's no longer needed. After all, why 
leave resource allocation to the user?

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

Six of one half a dozen of the other?

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

Good point. I've done this in a jsfiddle and it's great! (see 
instructions [1]). Have we thought about making this an automatic a 
feature of PeerConnection? Then we could remove RE-negotiation as an API 
hassle and just have initial negotiation, which would be a huge API win, 
perhaps even a step toward a future non-SDP solution?

.: Jan-Ivar :.

Received on Monday, 25 May 2015 12:38:17 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:06 UTC