Re: Specify the negotiationneeded event

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