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

Re: Specify the negotiationneeded event

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>
Message-ID: <A222C88B6882744D8D4B9681B315889023D8E192@ESESSMB307.ericsson.se>
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

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