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

Re: Specify the negotiationneeded event

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Wed, 18 Feb 2015 10:23:54 +0000
To: Justin Uberti <juberti@google.com>, Cullen Jennings <fluffy@cisco.com>
CC: Martin Thomson <martin.thomson@gmail.com>, public-webrtc <public-webrtc@w3.org>
Message-ID: <A222C88B6882744D8D4B9681B315889023DD9156@ESESSMB307.ericsson.se>
On 13/02/15 01:25, Justin Uberti 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.

What happens if the 'dirty' state is not cleared when setLocal is done?

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

Received on Wednesday, 18 February 2015 10:24:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:04 UTC