Re: Specify the negotiationneeded event

On Mon, Feb 16, 2015 at 10:51 PM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> 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?
>

I am sure that we could, but I think we need to consider whether there is
any real-world benefit. The actions mentioned in this thread (e.g. adding a
track and then removing it immediately) seem like academic cases.

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