how to disable IPV6 on stuns server

[Steve Hardt]

I am using the google stuns server and on IPV6 supported networks I am getting IPV6 address in the candidates but I am only running IPV4 at the moment so the device cannot connect. I did not find anything in the configs to tell the stuns server to only use IPV4 addresses. Anyone know how to fix that or will I need to add support for ipv6?

Thanks for the help

Steve

[Mirko Brankovic]

I know you can discard ipv6 candidates on client side if you add a check on onIceCandidate function if I remember correctly :)

--
You received this message because you are subscribed to the Google Groups "meetecho-janus" group.
To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Regards,

Mirko

[Alessandro Amirante]

Have you explicitly enabled v6 support on Janus, either by passing the -6 option at start time or via janus.cfg? If not, Janus won't collect v6 candidates and you end up using ipv4.

A.

--

[Lorenzo Miniero]

Not sure if the ipv6=false thing impacts the way we do STUN queries if a STUN server is configured for Janus, though. I'll have to check.

L.

To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janus+unsubscribe@googlegroups.com.

[Steve Hardt]

I have the IPV6=false set in the media section of the config. When I look at the Janus start it says that the IPV6 is disabled for ICE.

Initializing ICE stuff (Full mode, ICE-TCP candidates disabled, half-trickle, IPv6 support disabled)

but when I try to connect through my phone over a LTE network I see IPV6 address being returned.

{"janus":"trickle","candidate":{"candidate":"candidate:3506238027 1 tcp 1518283007 2600:380:70e3:2657:1e31:fe2c:1cc4:4f2d 9 typ host tcptype active generation 0 ufrag yCH1 network-id 1 network-cost 900","sdpMid":"video","sdpMLineIndex":1},"transaction":"gPXWalfRfYVu"}

{"janus":"trickle","candidate":{"candidate":"candidate:2805338407 1 tcp 1518217471 2600:380:7060:9244:4e5d:ffb:8298:f629 9 typ host tcptype active generation 0 ufrag yCH1 network-id 6 network-cost 900","sdpMid":"video","sdpMLineIndex":1},"transaction":"d3rtinT5dV6Z"}

Thanks for the help.

To unsubscribe from this group and stop receiving emails from it, send an email to meetecho-janu...@googlegroups.com.

[jja...@gmail.com]

Disable IPv6 on the server if it is Linux. After that you should not see any IPV6-related messages at all because the server cannot generate IPv6 address information for any purpose.

I think, however, that the better idea is to embrace IPv6 as soon as possible. In many countries mobile service providers are completely dropping IPv4 from mobile clients (some have done that already). You mobile device will get an IPv6 address only. In most cases you get NAT64+DNS64-environment, but that seems to be poison for webrtc. Currently Janus does not work correctly in a  NAT64+DNS64-environment and the best bet is to go for dual stack or for IPv6 only.

In addition, it may not be possible for you to get a static/public IPv4 address in any case. Even if you wanted one.

Br. JJA

[Steve Hardt]

Thanks for the info. I will check to see what I need to do to enable the IPV6 on the AWS server.

[Lorenzo Miniero]

If IPv6 is disabled in the config, then yes, it's likely the problem is here:

https://github.com/meetecho/janus-gateway/blob/master/ice.c#L724

that is, where we resolve the address of the STUN server to make the test. Good chances are that the IPv6 address of the server is resolved, and so when we make that STUN test to detect the public IP we get an IPv6 address back. There are a couple of things that need to be fixed there, actually:

1. if IPv6 is disabled by config, we should only resolve the IPv4 address;
2. if IPv6 is enabled, and in case the address resolves to both IPv4 and IPv6, we should get BOTH public IPs: this is especially relevant for the 1-1 mapping, that overwrites local gathered IP addresses with the public IP we collected; as it is now, IPv4 local candidates will have an IPv6 in there;
3. once we have both addresses, set both as STUN servers in libnice, since at the moment we're only passing what we resolve and that explains why you're only getting IPv6 candidates back.

I'll take note of these for future commits: it might take a while, so if you want to open an issue on Github as a memo that would help. A quick and dirty fix for your specific case is passing the IP of the STUN server to Janus, instead of the symbolic name: this will remove any ambiguity, and force the IPv4 addresses to be resolved.

[Steve Hardt]

Thanks Lorenzo,

    I tried changing to the IP address for the stuns server and no luck, even disabled the IPV6 on the interface and still no luck. I no matter what I keep getting IPV6 addresses for the mobile device. I finally ended up adding IPV6 but before it started working I had to also disable the 1 to 1 NAT.

Thanks again for the help..

[Lorenzo Miniero]

I find that weird: if you set an IPv4 address as the STUN server, IPv4 is what you'll use to contact it, and so you cannot possibly get an IPv6 STUN address back I believe. What do you mean by IPv6 addresses for the mobile device? Do you mean the address the *mobile device* gathers? In such a case, Janus has nothing to do with it: the gathering is done by the browser/app there. The indications I gave are solely for candidates gathered by Janus itself.

L.

[Steve Hardt]

Here is an example of what I am getting from the Janus logs.

{"janus":"trickle","candidate":{"candidate":"candidate:1696541271 1 tcp 1518217471 2600:380:702d:6abc:5daa:5d88:9406:fa5f 9 typ host tcptype active generation 0 ufrag hx7W network-id 4 network-cost 900","sdpMid":"audio","sdpMLineIndex":0},"transaction":"Yy5EHuHBKg4A"}

The mobile device connect to Janus using IPV4 but but during the ICE negotiation I get the above even when IPV6 is disable in the config, on the network interface and I have the stuns server as a IPV4 IP address. This only happens when I connect through my mobile device over the AT&T LTE Network.

[Lorenzo Miniero]

Then that's a candidate collected by the device, not Janus, which as I was saying in my previous post has nothing to do with that process. If you only get IPv6 candidates from the mobile device on that network, it probably means that AT&T LTE network is IPv6 only. If so, the only way to get that working is enabling IPv6 in Janus as well (and in the server hosting it of course).

L.

[Phong Le]

I got the same issue. @Steve Hardt Could you told me how you resolved this issue?

[Phong Le]

Most users worked well. On few users the Janus client connected to server then disconnected immediatly. I took webrtc logs and compare with the success cases, there isn't any IPv4 collected link the above image!!!

On Tuesday, June 12, 2018 at 10:52:56 PM UTC+7 Steve Hardt wrote:

[Phong Le]

I remember that user can connected and publish video but very low quality and now I find out this information

https://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/enterprise-ipv6-solution/white_paper_c11-676278.html

Exact what I got :)