I read about how UDP-based services on fly.io have a somewhat reduced MTU. Does anyone know if this will be a problem for the TURN protocol that WebRTC uses to work around restrictive NAT/firewall setups?
I think it’ll be fine! The bigger issue with TURN is pinning traffic to the right VM. You pretty much have to run single VM applications to use TURN effectively on Fly right now.
So then, to use TURN effectively on Fly, I’ll need to create a separate
app (with its own hostname) for each region, and use some other means to
route the client to the correct one, right?
One other question: Can I specify a range of public port numbers for the
service? It looks like coturn expects to have a range of port numbers
that it uses for the actual relaying.
If anyone can share a working configuration for running coturn on
fly.io, I would appreciate it.
For what it’s worth, for UDP ports, you’re fine with ranges — declare any UDP port in your fly.toml, and you’ll get all UDP inbound traffic. UDP routing doesn’t discriminate on ports (remember, though, that you need to listen on the nonstandard fly-global-services address to see them).