Comments (8)
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.
from eturnal.
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:
- 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!).
- 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.
from eturnal.
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:
- 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
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.
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?
from eturnal.
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.
from eturnal.
so is port 5349 of any use in my config?
what config would you recommend?
from eturnal.
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
from eturnal.
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.
from eturnal.
I see, thank you.
from eturnal.
Related Issues (20)
- Can relay_ipv4_addr and relay_ipv6_addr be set as an FQDN? HOT 4
- Support UDP proxy protocol
- How to prevent abuse by using amplification/reflection DoS attack? HOT 2
- mod_stats_prometheus: make bucket sizes configurable
- Please delete this
- WebRTC Connectivity Issue with Safari on iPhone (Works on Desktop Chrome)
- Add support for ETURNAL_SECRET_FILE to allow Docker secrets workflow HOT 5
- TCP supported for TURN? HOT 2
- Crash report in eturnal.log
- Two other log errors HOT 1
- syslog logging?
- TURN using docker not work with transport=udp HOT 8
- Unable to use TURNS HOT 1
- Docker anonymous volumes created HOT 3
- Add credentials dynamically HOT 9
- Repository eturnal does not exist! at /usr/share/perl5/Debian/ExtRepo/Commands/Enable.pm line 33. HOT 2
- SSL problem HOT 16
- memory usage HOT 14
- Rejecting permission creation request: Forbidden
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from eturnal.