- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Tue, 02 Jun 2015 09:09:05 +0200
- To: public-webrtc@w3.org
On 06/02/2015 04:39 AM, Jan-Ivar Bruaroey wrote: > On 6/1/15 10:19 AM, Stefan Håkansson LK wrote: >> On 30/05/15 22:27, Martin Thomson wrote: >>> On 30 May 2015 at 12:26, Jan-Ivar Bruaroey <jib@mozilla.com> wrote: >>>> I'm arguing it's good enough for replaceTrack to flicker when I >>>> unplug/transition off my on-chip H.265 encoding USB camera to the >>>> built-in >>>> one. >>> I'm not sure what you think is happening here. The concern is the >>> atomicity of the update, in all its aspects. You can negotiate a new, >>> bundled track and have a single instant in time where that applies >>> (setRemoteDescription most likely). That can almost be fast enough to >>> not matter (a round trip to JS, all going well). >>> >>> But the sender is never the concern. It's the coordination of the >>> transition at the receiver that hurts. > > However complicated renegotiation is seems irrelevant to me since we > already have it. All we're discussing is whether replaceTrack should > fire onnegotiationneeded on non-negotiated codecs, or fail and have > the user remember to cover this POLA-violating corner-case *by > detecting this specific error (by name?) and react by calling > pc.onnegotiationneeded() themselves*, because I've not heard anyone > suggest "forget it then" as a desirable outcome. More likely, > different codecs just wont work by coding omission. > >> I agree, and if replaceTrack (initially at least) was specced to only >> work if the UA could simply replace the content of existing outgoing RTP >> stream(s) - SSRC and all being the same - would feel the simplest > > Simplest for whom? Browser implementers, spec writers, or users? > Assuming no users want it to fail, then it seems simpler (to the user) > for us to "just do it" (even in the hard corner-case). > > More importantly, IMHO, if the Sender/Receiver API is to outlive > renegotiation, then it needs to absorb it, not operate within its limits. When the (IETF) WG rejected the ROAP model of draft-jennings-rtcweb-signaling (2011), and went for the JSEP approach, it was also concluded that a specific protocol for renegotiation was ruled out of scope. So while datachannel negotiation may be a Really Good Idea for applications, it is not within scope to specify a protocol that can be used over that datachannel for renegotiation.
Received on Tuesday, 2 June 2015 07:09:36 UTC