ice restart ?

In WebRTC 1.0 they have the option "iceRestart" to create new ice 
credentials on an existing transport.

For the ORTC API, we have an RTCIceListener where every RTCIceTransport 
created with the same RTCIceListener therefor shares the same ice 
credentials (because they share the same ice host / reflexive / relay 
candidates). I'm assuming (maybe incorrectly) that we need to support 
changing the existing RTCIceListener's ice credentials as well as 
opposed to just creating a new RTCIceTransport based on a new implicit 
RTCIceListener. Is this true?

If it's true, then we have to expose the appropriate method/mechanism to 
allow the restart. If it's false, then creating a new RTCIceTransport 
could impact the idea of implicit ice freezing based on RTCIceTransport 
construction order (since new objects are thus put to the last of the 
implicit freeze order).

Peter mentioned he was going to propose an alternative strategy for 
RTC/RTCP non-mux and ice freezing with a similar idea of an RTCSession 
(or RTCContext) but with a different exposed mechanism. That might 
address the concern about ice freezing should the answer be "if you want 
ice restart, simply create a new RTCIceTransport from scratch". So I'm 
eager to see that proposal.

-Robin

Received on Saturday, 26 April 2014 12:42:53 UTC