I'll take a shot at a PR for this and we can move the discussion there. On Tue, Feb 17, 2015 at 5:17 PM, Cullen Jennings <fluffy@cisco.com> wrote: > > > 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 > > >Received on Wednesday, 18 February 2015 02:56:37 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:04 UTC