- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Wed, 4 Feb 2015 13:59:40 +0000
- To: public-webrtc <public-webrtc@w3.org>
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