- From: Adam Bergkvist <adam.bergkvist@ericsson.com>
- Date: Thu, 5 Feb 2015 10:21:32 +0000
- To: Martin Thomson <martin.thomson@gmail.com>
- CC: public-webrtc <public-webrtc@w3.org>
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. > 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. /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. >> >
Received on Thursday, 5 February 2015 10:22:00 UTC