tl;dr:

I am not sure if this issue is from coturn specifically, or some universal browser security issue I can’t find documented anywhere, but it seems that the coturn service uniquely can’t be accessed by hostname/URL but only by the hardcoded IP with any given browser, while every other service I run works either way.

Long version:

I am building my own WebRTC peer to peer voice/video chat and have a working prototype running on my local LAN.

However it seems that no matter what I do, I cannot access my own STUN/TURN server via hostname like I can with any Node Web Servers, SSH, etc etc.

That is, I can use “My-PC:8080” in the URL of the browser (assuming My-PC was the hostname on my LAN and the web server is listening on 8080 either natively or published via docker) and it works, but if I provide “stun:My-PC:3478” for the RTCPeerConnection constructor it doesn’t find it. But if I use “stun:<My-PC’s-Hardcoded-IP-Address>:3478” for the constructor it does find it. Wt..?

The reason this is important is I don’t want to rely on static IP addresses, either hardcoded or injected. Ideally I would be able to have my library make the address from the same URL as the webserver, like so:

stun:${window.location.hostname}:3478, or maybe stun:stun1.${window.location.hostname}:3478 if it’s on a subdomain of the main app.

At first I thought maybe this was to do with docker network mapping, but no matter what I tried it didn’t fix it, so then I installed it directly on a couple machines in my network, and it still works and fails in this same way when ran on either/all of them.

What is more, this site for testing STUN/TURN servers (https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/) always returns some 701 errors for my coturn server, allegedly from onicecandidateerror, even on addresses it also reports successfully finding the srflx candidate from. My own prototype that also listens to onicecandidateerror doesn’t seem to get any errors. Note: despite this difference in error generation, my prototype still succeeds and fails otherwise the exact same way as their test app (ie it finds the srflx candidate with the IP but not the URL/hostname). (Also note that their site gets fewer 701 errors from addresses it actually finds an srflx candidate from, but still gets at least one.)

Been searching the internet all day for stuff about this and so far nothing helpful.
Have tried all kinds of different things in the config too, including different ways of specifying the listening-ip, external-ip, realm, etc. Nothing seems to make any difference.