search

meetecho / janus-gateway

Janus WebRTC Server
https://janus.conf.meetecho.com
GNU General Public License v3.0
8.25k stars 2.48k forks source link

[1.x] ipv4/ipv6 public IP confusion #3313

Closed sstreng closed 11 months ago

sstreng commented 11 months ago

What version of Janus is this happening on? 1.2.1 - Tue 19 Dec 10:33:47 CET 2023

Have you tested a more recent version of Janus too? Yes, see above.

Was this working before? No.

Is there a gdb or libasan trace of the issue? No.

Additional context Janus is running on a dual stack system with a private v4 address and a public v6 address. v4 udp hole punching is no problem. The goal is to be reachable for v4 and v6 clients, internal and external. This works for all combinations except v4 public clients because of the following reason:

Because of the NAT we have to use an STUN server which is also reachable via v4 and v6 (google's stuns for example). The hostname of the STUN server is always resolved via v6 and so our (only) public ip is v6 (which we already know as it is also local) but we never get our public v4 and so our public v4 is never used in the ice messages which leads to failing connections with external v4 clients. Interestingly it doesn't seem to make any difference whether we set "-6" or not. The name resolution and the returned public ip don't change.

Using an external TURN server solves this issue but is IMHO a little bit "too much" considering the only issue is just host name resolution.

"--nat-1-1" with our current public v4 ip also solves the issue but looks a bit "static" to me and makes the configuration practically unusable on dialup connections where the public ip changes from time to time.

Therefore I would like to make the proposal to resolve and connect to any STUN or TURN server via both v4 and v6 (if enabled) and add all responses to the address pool.

alexamirante commented 11 months ago

Why don't you just put the STUN server's IPv4 address in the config, so that name resolution is not performed and you always get your v4 srflx candidates?

lminiero commented 11 months ago

Therefore I would like to make the proposal to resolve and connect to any STUN or TURN server via both v4 and v6 (if enabled) and add all responses to the address pool.

Unfortunately that's not possible, because we use libnice and you can only specify a single STUN server to use. The libnice library always expects an IP address for the STUN server to use, which is why we resolve any address ourselves if you provide a domain name, and we use the first result we get, which in your case probably is an IPv6 address. As such, the workaround Alex suggested would address your requirement.

sstreng commented 11 months ago

Thank you both for your responses. I will probably go that way then, although it disables STUN usage for ipv6 completely (which is hopefully no problem in the field).

lminiero commented 11 months ago

although it disables STUN usage for ipv6 completely

You mentioned the public IPv6 IP you know already as it's local (which makes sense, it's what IPv6 was created for, not needing NATs), so I guess candidates for that address are already gathered. Closing the issue.