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

Re: API points for ICE/DTLS warmup

From: Peter Thatcher <pthatcher@google.com>
Date: Mon, 27 Jul 2015 09:19:37 -0700
Message-ID: <CAJrXDUGS8vWK5VzCxD3mmjtEzd_unM8jkNsLAp=O7+OwbgQ7iQ@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Sat, Jul 25, 2015 at 7:17 AM, Martin Thomson <martin.thomson@gmail.com>

> On 24 July 2015 at 13:18, Peter Thatcher <pthatcher@google.com> wrote:
> > B > A, because an RtpSender without a track seems cleaner than a dummy
> > track. But I could live with A.
> I think that if we intend to send nothing, then I agree.  A dummy
> track that sends nothing is a little odd.
> > D > C, because we don't have to add anything.  I think we shouldn't add
> > RtpReceiver.active.
> I'm not sure about this, but adding an API point is easier than removing
> one.
> > F > E, because we don't have to add anything.  I think that even if we
> add
> > RtpReceiver.active, it should not cause an SDP renegotiation, just like
> > RtpSender.setParameters doesn't.
> I'm fine with that, if that was the decision for setParameters.
> I'm not sure about that decision though.  It seems like we have tried
> hard to ensure that you could frob the various hoosits and rely on
> onnegotiationneeded to tell you when to send an offer out.  Do you get
> onnnnnn firing if you replace a track?

​If my memory serves me correctly, w
e specifically said that all the things that go in 1.0 setParameters​
  must not cause renegotaition.  In other words, for 1.0, we're limiting
ourselves to the things that don't cause renegotaition.  If we didn't have
that restriction, we could put in a lot more things.  But it's my
understanding that we decided not to go there for 1.0.
Received on Monday, 27 July 2015 16:20:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:08 UTC