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

Re: Specify the negotiationneeded event

From: Justin Uberti <juberti@google.com>
Date: Thu, 12 Feb 2015 16:24:48 -0800
Message-ID: <CAOJ7v-07T5fbDbS+e_bfy2V__5PakUs7AakyrGbus5gVPS+yEw@mail.gmail.com>
To: Adam Bergkvist <adam.bergkvist@ericsson.com>, Cullen Jennings <fluffy@cisco.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, public-webrtc <public-webrtc@w3.org>
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.
* 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>

> 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