- From: Robin Raymond <robin@hookflash.com>
- Date: Mon, 28 Apr 2014 13:33:17 -0400
- To: Peter Thatcher <pthatcher@google.com>
- CC: "public-ortc@w3.org" <public-ortc@w3.org>
- Message-ID: <535E90DD.3010809@hookflash.com>
Thanks for a great summary. Yes, I agree those are the three options. I think I prefer option "a". Let me list my reasons: a. Makes sense to me, attach a new listener to transport or create a brand new one and it forces a restart b. I worry about the security implications, specifically if ice is still being used for consent reasons. By not doing this we don't have to fear that. c. My only concern is that two RTCIceTransports could the same RTCIceListener so calling a iceTransport1.restart() in that cause would actually affect the other iceTransport2 indirectly because what's actually being restarted is not the RTCIceTransport but the RTCIceListener which both are attached. -Robin > Peter Thatcher <mailto:pthatcher@google.com> > April 28, 2014 at 1:11 PM > > > > On Sat, Apr 26, 2014 at 5:42 AM, Robin Raymond <robin@hookflash.com > <mailto:robin@hookflash.com>> wrote: > > [...] > > > > We've chatted about this before. I think our 3 options were: > > a. Create a new IceTranport (or IceListener). This would require > being able to swap out the .transport of either the DtlsTransport or > the RtpSender/RtpReceiver. This seems elegant, but does add some > implementation complexity, and some burden to the JS. > > b. Allow the JS to set the ICE ufrag/pwd at any time. This would be > really simple, but has some security concerns. > > c. Add an IceTransport.restart() method that changes the ice/frag and > restarts the machine. This is pretty simple and doesn't have any > security concerns, and not much burden to the JS. > > I don't remember if we ever decided on one. I'd be happy with any of > them. > > > > -Robin > > >
Received on Monday, 28 April 2014 17:33:49 UTC