Re: Specify the negotiationneeded event

> On Feb 18, 2015, at 8:46 AM, Justin Uberti <juberti@google.com> wrote:
> 
> 
> 
> On Tue, Feb 17, 2015 at 2:27 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> On 18 February 2015 at 05:34, Justin Uberti <juberti@google.com> 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.
> 
> Agree with this, as well as your suggested naming. 
> 

+1