- From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Tue, 17 Feb 2015 06:51:05 +0000
- To: Justin Uberti <juberti@google.com>, Adam Bergkvist <adam.bergkvist@ericsson.com>, Cullen Jennings <fluffy@cisco.com>
- CC: Martin Thomson <martin.thomson@gmail.com>, public-webrtc <public-webrtc@w3.org>
On 13/02/15 01:27, 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. > > 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. I fully agree to that too few are worse than too many. But there is a cost related related to the signaling, and there is always the risk of glare (how many scripts handle that correctly today?). Can't we spec this in a way that allows implementations capable of detecting that a potential onNN will be cancelled before signaling state becomes stable to suppress that onNN? > > 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 <mailto: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 > <mailto: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 Tuesday, 17 February 2015 06:51:32 UTC