Re: Specify the negotiationneeded event

I think that's almost right.

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

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.

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

Received on Wednesday, 4 February 2015 23:09:21 UTC