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

Re: Specify the negotiationneeded event

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Tue, 17 Feb 2015 06:51:05 +0000
To: Justin Uberti <juberti@google.com>, Adam Bergkvist <adam.bergkvist@ericsson.com>, Cullen Jennings <fluffy@cisco.com>
CC: Martin Thomson <martin.thomson@gmail.com>, public-webrtc <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1D1A0272@ESESSMB209.ericsson.se>
On 13/02/15 01:27, Justin Uberti wrote:
> How about this version:
> The PC is considered 'dirty' when:
> * A track is added, removed, or stopped (local or remote).
> * A property that requires signaling is mutated on RTCRtpSender (e.g.
> .active).
> * A datachannel is created, and the association does not exist.
> 'dirty' is cleared when:
> * setLocalDescription is called (either offer or answer), and the # of
> tracks/SCTP association in the supplied description is compatible with
> the tracks/datachannels in existence on the PeerConnection.
> For simplicity, 'dirty' is not cleared by any other operations, such as
> addTrack(X) followed by removeTrack(X). *We should accept that it is far
> better to fire too many onNN events than too few*; spurious onNNs are
> essentially harmless, whereas missing onNNs may be fatal.

I fully agree to that too few are worse than too many. But there is a 
cost related related to the signaling, and there is always the risk of 
glare (how many scripts handle that correctly today?).

Can't we spec this in a way that allows implementations capable of 
detecting that a potential onNN will be cancelled before signaling state 
becomes stable to suppress that onNN?

> When the PC is marked as 'dirty', and it is not already 'dirty':
> * if the signaling state is 'stable', a task to fire onNN is scheduled.
> * otherwise, wait for the state to return to 'stable', and then fire onNN.
> On Mon, Feb 9, 2015 at 5:44 AM, Adam Bergkvist
> <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@ericsson.com>> wrote:
>     On 07/02/15 01:25, Martin Thomson wrote:
>      > On 6 February 2015 at 10:43, Justin Uberti <juberti@google.com
>     <mailto:juberti@google.com>> wrote:
>      >>> The intention with waiting for the queue to drain is that there
>     might be
>      >>> operations queued that, when completed, makes negotiation
>     unnecessary.
>      >>> For example, a setLocalDescription that updated the
>     localDescirption to
>      >>> match the added tracks.
>      >>
>      >> This seems like it might be difficult to implement.
>      >
>      > I don't believe that we could implement this in Firefox.
>     OK. Let's take a first stab at this without involving the operations
>     queue.
>     /Adam

Received on Tuesday, 17 February 2015 06:51:32 UTC

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