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

Re: Specify the negotiationneeded event

From: Justin Uberti <juberti@google.com>
Date: Tue, 17 Feb 2015 18:55:50 -0800
Message-ID: <CAOJ7v-12FL224PxofGuai+qc7TAd3agPhTJwRVZ6BKFMsQp2TQ@mail.gmail.com>
To: Cullen Jennings <fluffy@cisco.com>
Cc: Martin Thomson <martin.thomson@gmail.com>, Stefan HÃ¥kansson <stefan.lk.hakansson@ericsson.com>, Adam Bergkvist <adam.bergkvist@ericsson.com>, public-webrtc <public-webrtc@w3.org>
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