Re: Specify the negotiationneeded event

I think that would work and it's pretty easy to understand. 

> On Feb 12, 2015, at 5: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
> 
>

Received on Friday, 13 February 2015 04:17:01 UTC