Re: Specify the negotiationneeded event

On 06/02/15 09:26, Harald Alvestrand wrote:
> 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.

This makes sense. The proposal covers this with the comparison between 
added tracks and pc.localDescription (when removeTrack() triggers a 
request to queue a negotiationneeded event).

> For more complex setup:
>
> (stable state)
> pc.SetLocalDescription()

Should the above be a setRemote for an incoming offer or is there an 
addTrack() done before?

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

Received on Friday, 6 February 2015 10:36:26 UTC