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