Auto routing

[docjojo]

Hello Holger,

metered.ca offers "Access to Global TURN Servers, with automatic routing to the user's nearest server".

Do you know how they manage to route a user to the nearest server? Any idea how to implement this?

Thank you. C.

[docjojo]

I have talked to metered.ca and they use a fixed domain for the ice list. their DNS returns the IP of the nearest server, depending on the request origin. I checked that STUN/TURN works with IP only, but TURNS does not, as it requires TLS/SSL and therefore a domain name? Do you have any idea how to solve this?

I could use bunny.net DNS service to do the IP routing, but how to solve the domain/SSL issue?

Thank you.

[weiss]

their DNS returns the IP of the nearest server, depending on the request origin.

Yes, I think that's the most-common solution and would've been my first suggestion.

I checked that STUN/TURN works with IP only, but TURNS does not, as it requires TLS/SSL and therefore a domain name?

Globally trusted CAs won't issue certificates for IP addresses but only for host names indeed, so if the clients insist on certificate validation, you'd need to use host names for TLS indeed. I don't have a single obvious solution to suggest here, it depends e.g. on whether or not you control the client code. If you do, you could e.g. perform some DNS lookup that returns a host name, or resolve the returned IP address back to a host name before feeding it to the TURN client code.

Two additional notes that might be relevant when thinking about a solution, just in case these points weren't obvious:

1. As WebRTC connections are end-to-end encrypted anyway, TURNS is typically not used for its security properties, but just as a fallback to circumvent restrictive firewalls that permit nothing but TLS connections (typically only on port 443!).
2. If the server routing can't easily be implemented for TLS, maybe it's good enough to start without that routing in the TURNS case for the moment, and keep the problem for later? TLS adds significant latency by itself, which is why WebRTC clients typically prefer plain UDP anyway.

[docjojo]

Thank you Holger.

I do not control the client, rather run the STUN/TURN and provide credentials. Otherwise i could leave it to the client to find the closest server.

Notes:

1. So you basically think that TURNS is useless for WebRTC? How does the client decide to use the fallback?

if this is the ice setting, should I add another entry with just turn:... so that the client can decide which connction to use?

const iceServers = [ { urls: 'stun:semdr.chat:3478' }, { urls: 'turns:semdr.chat:5349', username: 'turnuser', credential: 'xxx' } ];

This is my typicall eturnal.yml. What is your recommendation if I want to provide STUN/TURN on port 3478 and STUN(S)/TURNS on port 5349.

listen:
    -
      ip: "::"
      port: 3478
      transport: udp
    -
      ip: "::"
      port: 3478
      transport: tcp
    -
      ip: "::"
      port: 5349
      transport: udp
    -
      ip: "::"
      port: 5349
      transport: auto

2.

My interpretation of what you say is, that TURNS is likely to be used on port 443 not 5349? But I am not running it on port 443.

3.

I have the bunny.net config up and running. So auto-routing works for the non SSL connections. I could give the users the generic domain for non TLS and leave it up to them to select appropriate server if they want to use SSL connections.

What do you think?

[weiss]

So you basically think that TURNS is useless for WebRTC?

For typical setups, yes. As I said, WebRTC streams are end-to-end encrypted anyway. And one of the two TURN relay hops is always using plain UDP, even if the first is TLS-encrypted (see the web site for a short explanation).

However, you mentioned elsewhere that you're using static credentials. Those are not covered by WebRTC encryption, so a reason for sticking to TLS might be to avoid exposing those credentials (which would allow the attacker to use your TURN service). Many WebRTC setups use ephemeral credentials for that reason, see the [first paragraph of the documentation][4] for how that works. If you're hard-coding TURN credentials into your clients rather than retrieving them from some web service, that won't be an option, though.

Anyway, if possible, I'd avoid TURNS due to the additional latency, except as a fallback for clients behind restrictive firewalls.

How does the client decide to use the fallback?

ICE clients typically try all options you offer. They have a hard-coded preference for plain UDP and use TLS if nothing else works.

But I am not running it on port 443.

In that case, it won't serve the purpose of circumventing restrictive firewalls.

I could give the users the generic domain for non TLS and leave it up to them to select appropriate server if they want to use SSL connections.

Personally I wouldn't bother users with that decision. Understanding the implications (both regarding latency and security) is non-trivial, so most users would be overwhelmed and perceive such questions as bad UX.

[docjojo]

so is port 5349 of any use in my config? what config would you recommend?

[docjojo]

I think it would be better to turn to ephemeral credentials, but I can not find a good docu with example, except for the script at

[weiss]

As for offering TLS on a high port, I would've hoped I mentioned the details that allow you to make an informed decision yourself. If anything is unclear, feel free to ask.

As for ephemeral credentials, a common setup is to have the client retrieve the TURN credentials from some web service. That web service would derive temporary credentials from the same secret as eturnal. Deriving them requires a few lines of code as described at the top of the eturnal docs, see the example script in the repository.

[docjojo]

I see, thank you.