Re: ice restart ?

On 26.04.14, 14:42, Robin Raymond wrote:
>
> 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?

Personally I don't see much need for changing ICE credentials on an 
existing transport. I'd expect an ICE restart to always end up with a 
new ICE transport.

> 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.

Well actually ... (and I apologise I am still catching up with ORTC's 
intended semantics) ... why can't we just use the ICE transport as the 
object that provides context grouping? Is this what you were suggesting 
as well?

Emil


-- 
https://jitsi.org

Received on Saturday, 26 April 2014 13:40:38 UTC