Re: Specify the negotiationneeded event

On 18 February 2015 at 05:34, Justin Uberti <> wrote:
>> 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?
> I am sure that we could, but I think we need to consider whether there is
> any real-world benefit. The actions mentioned in this thread (e.g. adding a
> track and then removing it immediately) seem like academic cases.

Yes, I wouldn't bother with that.  What concerns me more is what Roman
pointed out: some applications rely on getting multiple events
(obviously they aren't using Firefox...), and even as described, the
event will fire less than they might previously have relied on.

I'm not super-concerned about that.  Applications that blindly
renegotiate based on the event aren't going to work particularly well
anyway.  Justin's proposed formulation does address that by ensuring
that dirty (what I think we should call negotiationNeeded) is only
cleared if the session description completely covers the requested set
of channels/tracks.

Received on Tuesday, 17 February 2015 22:27:34 UTC