Re: Specify the negotiationneeded event

I wanted to clarify. As far as I know Chrome currently fires two
negotiationneeded events when removeTrack is immediately followed by
 addTrack. Is this going to change based on this specification and only
one negotiationneeded event will be fired?

_____________
Roman Shpount

On Thu, Feb 12, 2015 at 7:24 PM, Justin Uberti <juberti@google.com> wrote:

> How about this version:
>
> The PC is considered 'dirty' when:
> * A track is added, removed, or stopped (local or remote).
> * A property that requires signaling is mutated on RTCRtpSender (e.g.
> .active).
> * A datachannel is created, and the association does not exist.
>
> 'dirty' is cleared when:
> * setLocalDescription is called (either offer or answer), and the # of
> tracks/SCTP association in the supplied description is compatible with the
> tracks/datachannels in existence on the PeerConnection.
>
> For simplicity, 'dirty' is not cleared by any other operations, such as
> addTrack(X) followed by removeTrack(X). *We should accept that it is far
> better to fire too many onNN events than too few*; spurious onNNs are
> essentially harmless, whereas missing onNNs may be fatal.
>
> When the PC is marked as 'dirty', and it is not already 'dirty':
> * if the signaling state is 'stable', a task to fire onNN is scheduled.
> * otherwise, wait for the state to return to 'stable', and then fire onNN.
>
>
> On Mon, Feb 9, 2015 at 5:44 AM, Adam Bergkvist <
> adam.bergkvist@ericsson.com> wrote:
>
>> On 07/02/15 01:25, Martin Thomson wrote:
>> > On 6 February 2015 at 10:43, Justin Uberti <juberti@google.com> wrote:
>> >>> 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 don't believe that we could implement this in Firefox.
>>
>> OK. Let's take a first stab at this without involving the operations
>> queue.
>>
>> /Adam
>>
>>
>