Ordering with multiple STUN servers

[mglettig]

I would like to use a list of STUN servers where the library tries the first server and only uses the second one if it can't contact the first one. If I understood the code / behavior correctly currently it shuffles the list of STUN servers and this it's random which one it takes.

Any thoughts on my idea? Would that be a change that makes also sense for others?

[paullouisageneau]

The ICE protocol requires that every ICE server is reached in parallel during connection establishment, therefore you can't try them one after another. The library picks one STUN server randomly only because the underlying libraries libjuice and libnice currently accept only one STUN server but multiple TURN servers.

Multiple ICE servers should not be used for redundancy. If you want redundancy, you should implement it on user side as you would for Websockets or HTTP requests.

[mglettig]

Are there any plans to add support for multiple STUN servers in libjuice? Testing all STUN servers in parallel as defined by the protocol would be even better than trying it sequentially.

Multiple ICE servers should not be used for redundancy. If you want redundancy, you should implement it on user side as you would for Websockets or HTTP requests.

I think I didn't get this point; Why shouldn't one use multiple ICE servers for redundancy? It's hard to find a single STUN server that is fully reliable and available in all the regions around the world. E.g. the one from Google is probably blocked in China.

By the way: Thanks a lot for maintaining this great library. 🥇

[paullouisageneau]

I think I didn't get this point; Why shouldn't one use multiple ICE servers for redundancy?

The whole issue is that every server is queried in parallel with ICE. For STUN server, it allows the agent to handle corner cases like networks with cascading NATs. However, it is not ideal for redundancy because there is no notion of fallback: if a STUN server is overwhelmed, it is still queried every single connection in parallel to the non-overwhelmed one, which keeps the DDoS going.

Also, a lot of implementations don't trickle candidates but wait for gathering complete to send a description with all candidates. Since gathering is only complete when all ICE servers are reached or timed out, a single STUN server from the list failing means the connection will be delayed by a long timeout delay. The longer the list, the more probable a failure.

It's hard to find a single STUN server that is fully reliable and available in all the regions around the world. E.g. the one from Google is probably blocked in China.

Simply deploy your own STUN server, you shouldn't rely on random third parties for a production service. Google STUN servers are not a public service like public DNS, they just happen to be there for some Google products and people use them, but there is no SLA of any kind.

By the way: Thanks a lot for maintaining this great library. 🥇

Thanks, I'm glad the library is useful!