Re: Specify the negotiationneeded event

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.

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>
wrote:

> On 07/02/15 01:25, Martin Thomson wrote:
> > On 6 February 2015 at 10:43, Justin Uberti <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
>
>