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 > >Received on Friday, 13 February 2015 00:25:39 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:04 UTC