Re: Specify the negotiationneeded event

Den 06. feb. 2015 00:43, skrev Justin Uberti:
> 
> 
> On Thu, Feb 5, 2015 at 2:21 AM, Adam Bergkvist
> <adam.bergkvist@ericsson.com <mailto:adam.bergkvist@ericsson.com>> wrote:
> 
>     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.
> 
> 
> FWIW, soon to be renamed setConfiguration(). 
> 
> Note that addIceCandidate is not a trigger, despite changing 'state',
> although not .signalingState.
> 
> Also; should .onNN fire for an initial addTrack, before any setLD/setRD?
> I forget what our thinking has been on this.
> 
> 
>     > 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.
> 
>  
> This seems like it might be difficult to implement.


Examples I've used when thinking about this is when we have a PC with an
established connection and have the sequence

(stable state)
pc.addTrack(a)
(onnegotiationneeded fires)
(stuff happens, but no createOffer or setLD)
pc.removeTrack(a)

at this point, the UA can compare the list of tracks we want to send
to the list of tracks we're currently sending and figure out that there
is no need to change anything - so there's no new onnegotiationneeded.

For more complex setup:

(stable state)
pc.SetLocalDescription()
(state is now HaveLocalDescription)
pc.addTrack(a)
(we could fire onnegotiationneeded, but can't negotiate)
pc.removeTrack(a)
pc.setRemoteDescription()
(state is now stable)

at this point, we shouldn't need an onnegotiationneeded either -
comparing the tracks we are sending with the tracks we want to send will
give the same result as above.




>  
> 
>     /Adam
> 
>     >
>     > On 5 February 2015 at 00:59, Adam Bergkvist
>     <adam.bergkvist@ericsson.com <mailto: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 Friday, 6 February 2015 08:24:45 UTC