W3C home > Mailing lists > Public > public-webrtc@w3.org > February 2015

Specify the negotiationneeded event

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Wed, 4 Feb 2015 13:59:40 +0000
To: public-webrtc <public-webrtc@w3.org>
Message-ID: <A222C88B6882744D8D4B9681B315889023D8B4FC@ESESSMB307.ericsson.se>
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 14:00:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:43 UTC