PTAL at https://github.com/w3c/webrtc-pc/pull/186 On Wed, Feb 18, 2015 at 9:23 AM, Justin Uberti <juberti@google.com> wrote: > > > On Wed, Feb 18, 2015 at 2:23 AM, Adam Bergkvist < > adam.bergkvist@ericsson.com> wrote: > >> 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? >> > > Stays dirty, and a new onNN is fired when the state returns to stable. > >> >> > 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 Thursday, 26 February 2015 07:15:25 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:04 UTC