On Sat, Jul 25, 2015 at 7:17 AM, Martin Thomson <martin.thomson@gmail.com> wrote: > 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