Open themightyoarfish opened 1 year ago
This is on macos, where docker host networking is not available, I will try this on Linux, but i believe this info would be valuable regardless.
Docker in the default bridge network mode introduces a NAT between the host address and the container private address. Since you typically run the host itself behind a NAT, if you run a browser on the host, it creates a cascading NAT scenario which may fail depending on the specific setup, and which a STUN server on the public Internet can't help solving as it can't see the host address.
There are multiple approaches to solve this issue:
candidate.changeAddress(HOST_ADDRESS)
(This is what you should do on a production server)Strangely, the log excerpt for the failure actually shows an ICE pair nomination, which would correspond to a successful connection.
I have an application which works fine when everything runs locally, or even when the server is remote and the client (browser) local. It's based on the SFU example and forwards rtp data to whatever receivers (browsers) are connected.
Locally, when the client connects, it gets the "server"'s offer and the setup dutifully proceeds
and I can send RTP data successfully.
But when server runs in docker (browser locally, obviously), I do not seem to get a connection established. When the signaling connects a new client, I never seem to enter the
connected
state on the server:and eventually, the state changes to failed due to timeout.
So I was wondering what ports would have to be forwarded from inside the container. So far I was mapping these ports
and set
though I'm not sure that's needed. Is there anything else I should be doing?