Re: Specify the negotiationneeded event

On Thu, Feb 5, 2015 at 2:21 AM, Adam Bergkvist <adam.bergkvist@ericsson.com>
wrote:

> On 05/02/15 00:08, Martin Thomson wrote:
> > I think that's almost right.
>
> Great. Let's figure out what we need and make a patch.
>
> > My initial thought was to formulate it as: when any operation
> > completes and the state is "stable", then consider the conditions for
> > firing the event.  I.e., have any changes to the session been
> > requested that aren't reflected in the current session state.  I think
> > that you also need to consider updateIce in addition to
> > addStream/createDataChannel
>
> Yes. updateIce() might also be a trigger.
>

FWIW, soon to be renamed setConfiguration().

Note that addIceCandidate is not a trigger, despite changing 'state',
although not .signalingState.

Also; should .onNN fire for an initial addTrack, before any setLD/setRD? I
forget what our thinking has been on this.

>
> > I don't know that the queue being empty is a necessary condition.  I
> > think that it is probably OK to fire the event even though there is
> > something enqueued that might cause a transition out of the "stable"
> > state.
>
> 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.


> /Adam
>
> >
> > On 5 February 2015 at 00:59, Adam Bergkvist <adam.bergkvist@ericsson.com>
> wrote:
> >> Hi
> >>
> >> The negotiationneeded event is pretty underspecified at the moment. This
> >> is an attempt to fix that.
> >>
> >> It's actually easier to reason around this in the terms of when the
> >> event should *not* fire, even though you did something that eventually
> >> needs negotiation.
> >>
> >> The following is a list of triggers that *may* result in queuing of a
> >> task to fire negotiationneeded (but it may be prevented by conditions in
> >> the next section). This list will be extended as new functionality is
> added:
> >>
> >> * The operations queue[1] becomes empty and it did have state changing
> >> operations (e.g. setLocal/RemoteDescription) queued since the last time
> >> the queue was empty.
> >> * A new track is added or removed
> >> * The first DataChannel is created
> >>
> >> The following situations *prevents* a task to fire a negotiationneeded
> >> event to be scheduled:
> >>
> >> * There's already a task scheduled to fire the negotiationneeded event.
> >> * The operations queue is not empty
> >> * The signaling state is not "stable"
> >> * Both the following statements are true:
> >>     - DataChannels have been created, but the association is present
> >> pc.localDescription
> >>     - All added tracks are represented in pc.localDescription
> >>
> >> If none of the bullets above prevents the event to fire, a task must be
> >> scheduled to do the event firing. When that task is picked up, it needs
> >> to check that the signaling state is "stable" before firing.
> >>
> >> /Adam
> >>
> >> [1] The operations queue is the functionality that ensures that certain
> >> operations (e.g. createOffer and setLocalDescription) are only executed
> >> one at a time.
> >>
> >
>
>
>