Some observations on STUN, TURN and ICE in the context of WebRTC
Sep 12th, 2014 by Aswath
In a couple of hours there will be a VUC session on this topic. So I thought it will be useful to record some of my observations and outstanding questions.
- A user or administration of the local network must have a way to designate the STUN and TURN servers that override the ones specified by the application. STUN is analogous to DNS server and just like we are at liberty to specify the DNS servers, we must be able to specify the STUN server. Depending on the security considerations, a network may be obligated to record all conversations. To facilitate that, a network may deploy a TURN server and may require all RTC traffic to flow through this server.This can be simple done if the browser were to tacitly utilize its own TURN server and assign the highest priority to the corresponding ICE candidate. This is analogous to using SOCK proxy for HTTP flow.
- Both the users and application providers should recognize that external STUN and TURN providers have access to session metadata.
- TURN adds overhead and this is further added when ReTURNs are used. TURN needs this additional overhead to multiplex multiple streams between a TURN client and server. Most of the WebRTC use cases will involve a single stream. I think it is a good tradeoff to consume the occasional additional ports at the server, rather than consuming additional bandwidth for all the flows. So, it might be worthwhile to use a relay server rather than a full fledged TURN server.
- Some have expressed concern in sharing local address with other clients. Given that Trickle ICE is part of WebRTC, a modification to listing ICE candidates should be considered. Browsers should not include local addresses in the initial candidate set. Instead they should be added if and only if the peer’s server-reflexive or peer-reflexive address matches its own and te connectivity test passes. Of course, we have to recognize that the call setup time may increase slightly.
- TURN is required only when both the end-points are behind symmetric NATs. If it is known a priori that this will not be the case (as when the session is always to app’s own device/server), then we can dispense with relay addresses as ICE candidates. If further we know that app’s own device/server will have public Internet presence, then even STUN can be eliminated, since that device/server can use peer-reflexive addr it learns as part of Trickle ICE.
- As part of connectivity test, the two end-points must perform authentication of the other end before meaningful information is exchanged.