Re: Specify the negotiationneeded event

On 06/02/15 00:43, Justin Uberti wrote:
>
>
> 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 think we need to treat the initial addTrack() differently; it 
also needs negotiation. The example in the spec uses it to initiate 
negotiation and implementations that support the event (e.g. Chrome) 
work that way.

>
>     > 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.

I think the sentence above describing the reason for having it makes 
more complicated that it is. Regarding the trigger, the check if the 
operations queue is empty is already in the spec (step 3 in the queued 
operations algorithm [1]).

/Adam

[1] http://w3c.github.io/webrtc-pc/#operation (second algorithm)

Received on Friday, 6 February 2015 10:18:28 UTC