Updating 'iceServers' while call is in progress

[jawandarajbir]

Hi Damon,

Is there a way to update new iceServers details to a quickconnect call in progress?
We are trying a time based TURN server authentication mechanism. If a call goes longer than certain period, I need to update iceServers so that any new caller joining the call connects without TURN issues.

Would it be possible to provide a simple method to update iceServers?

Thanks,
Raj

[DamonOehlman]

Hey Raj - It's doable, but it would also be a little complicated as any existing peer connections would need to be terminated and new ones created with the updated iceServers specified. Let me have a think about this a bit more and get back to you. Also worth @nathanoehlman mulling it over too.

Has the use case been raised at a webrtc-discuss level yet? Would be interested to know how they would feel about having an RTCPeerConnection object that supports changing iceServers after it's been created...

[silviapfeiffer]

@jawandarajbir is this related to https://tools.ietf.org/html/draft-ietf-rtcweb-stun-consent-freshness-14 ? That spec is currently under discussion in the IETF. I'm not sure what effect that has on the Web API - I've put a question forward in the webrtc WG.

[silviapfeiffer]

My request for clarification resulted in this reply: https://lists.w3.org/Archives/Public/public-webrtc/2015Jun/0040.html . That's some useful advice there.

[jawandarajbir]

Thanks @silviapfeiffer and @DamonOehlman :)
The reply you got from Harald is interesting.

[DamonOehlman]

So it looks like rtc-quickconnect (or potentially a companion utility package) could help facilitate ice restarts, but the ability to add new ice servers is not something that's likely to be possible. Is that correct?

What's the desire to have something like this? It seems like something that would make sense to add to rtc-health if it's possible. @nathanoehlman would be the best person to ask on that, but I'm pretty sure he is currently off on paternity leave atm...

[warrenjmcdonald]

The primary driver for this is to tighten up ephemeral TURN server authentication. For instance right now we have to set the credential expiry to the longest expected meeting time. If a meeting goes past this time and a new participant joins, the TURN credentials for the already joined user are expired and we have to force a call refresh for them if they need TURN to connect to the new caller. (This is common in a lot of enterprise/institutional sites as they only allow connection via TURN for higher network security.)

If we could update the iceservers (including creds) periodically, then connections to new callers would be seamless, and we could reduce the expiry time to more acceptable levels. We would not need to restart existing peer connections as once authenticated to TURN, the TURN reallocation process ensures continued connectivity after initial allocation success.

[warrenjmcdonald]

The only other way I can see of possibly handling this is to do a late initialization of new connection objects, so that each is created on demand for each new peerconnection. This may mean moving from quickconnect to a lower level rtc.io calls. We would have to estimate size of this refactoring effort to see if this is sensible.

[DamonOehlman]

@warrenjmcdonald That might not be as difficult as it sounds as quickconnect is already creating the connections when required. The only piece of logic that would need to be refactored would be around potential deferred initialization of iceServers.

From a quick review of what's there I'd see the following being necessary to make this happen:

1. Refactor your code to pass an ice option through rather than iceServers as this provides the ability to specify an XHR function that will retrieve the desired ice servers from an endpoint instead of at quickconnect initialization.
2. Refactor rtc-quickconnect to move that asynchronous ice server initialization code to be "per connection" rather than global. Basically means moving this call to be within the connect call.

It's not trivial, but definitely doable.

[warrenjmcdonald]

@nathanoehlman I recall some discussion of this deferred initialization of iceServer. Did that make it into other changes or is this still a todo.

[silviapfeiffer]

Is this still a feature in need of development?