Re: Summary of replace track status

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