[0.x], [1.x] VideoRoom RTP Forwarder Doesn't Work When IPv6 is Disabled

[shmuelzon]

Hey,

What version of Janus is this happening on?
I've seen it on v0.10.5 but I believe is relevant to v1.0.0 as well

Have you tested a more recent version of Janus too?
No, mainly due to other dependencies in the system.

Is there a gdb or libasan trace of the issue?
No trace, as there's no crash. Just an error message in the logs:

Could not open UDP socket for RTP stream for publisher

Additional context
Looking at the sources, the socket created for forwarding RTP packets is always created as IPv6 and then marked for IPv4 as well. On systems where IPv6 is disabled, e.g., when adding ipv6.disable=1 to the kernel command line, the call to socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP); fails. Although the rtp_forward command does allow to specify the host family, it seems that this is only used for DNS resolving.

I'm not sure what would be the best way to over come this but perhaps if all the forward stream requests are IPv4, we can create the socket that way in the first place? Though that would only be relevant for the first time the socket is created. Following calls to rtp_forward might add a new IPv6 host.

Thanks in advance!

[lminiero]

Already discussed at length here: #2051

I'm not sure what would be the best way to over come this but perhaps if all the forward stream requests are IPv4, we can create the socket that way in the first place? Though that would only be relevant for the first time the socket is created. Following calls to rtp_forward might add a new IPv6 host.

Exactly, you don't know in advance what will be needed, and we currently use a single socket for all forwards coming from the same publisher, which is why we need a socket that can send to anything. The alternative would be creating a different socket for each forwarded stream, which is something I personally don't like.

[shmuelzon]

What about creating "just" two sockets, one for IPv4 and one for IPv6 and one or the other according to the destination?

Edit: I just saw the previously suggested PR. Is a two-socket solution still reasonable? It's a bit more cumbersome that a single socket but better than one for each forwarder...

[lminiero]

I forgot the discussion there, and the potential action item on a conditional check of IPV6_V6ONLY to address your use case. I'd rather investigate that approach, rather than the two sockets, which I personally don't like much. I don't have a way to check if this runtime check does indeed work, though. Maybe a simpler approach is to try and create an IPv6 socket when we first load the plugin: if that fails, we know IPv6 is disabled, and so can always create an IPv4 socket instead (and should also return an error when trying to forward to an IPv6 address). Would that work for you?

[lminiero]

Maybe a simpler approach is to try and create an IPv6 socket when we first load the plugin: if that fails, we know IPv6 is disabled, and so can always create an IPv4 socket instead (and should also return an error when trying to forward to an IPv6 address). Would that work for you?

Even though that wouldn't fix the MacOS problem, where the socket is created without problems, but it's sending to an IPv4 address from an IPv6 socket that fails. But anyway, that's a different issue than yours, which I can think can be solved more simply with the check at startup to know the constraints.

[lminiero]

@shmuelzon please test the PR above and let me know if it fixes the problem for you.

[lminiero]

@shmuelzon ping 🙂

[shmuelzon]

Hey,

I'm really sorry for not replying, I was shifted to a different urgent matter. I've been using pre-built packages up until now so I need to try to compile this one myself. Are there any major difference (external APIs and/or configuration files) between 1.x and 0.x or only internal implementation? If so, I'll need to apply your changes on 0.x to test in my environment but I don't think much has changed there.
In any case, testing should be simple on Linux, just need to add ipv6.disable=1 to your GRUB configuration (on Ubuntu it's GRUB_CMDLINE_LINUX at /etc/default/grub).
I'll try to get on it soon.

Thanks for your help!

[lminiero]

Are there any major difference (external APIs and/or configuration files) between 1.x and 0.x or only internal implementation?

Most APIs were kept for backwards compatibility, so it should be safe to test. The VideoRoom in particular can still be accessed via legacy APIs.

[atoppi]

In any case, testing should be simple on Linux, just need to add ipv6.disable=1 to your GRUB configuration (on Ubuntu it's GRUB_CMDLINE_LINUX at /etc/default/grub).

It is worth mentioning that grub configuration must be regenerated after this change.

In Ubuntu you can use the helper

update-grub2

If the helper is not available or you are using other distros the command is

grub-mkconfig -o /boot/grub/grub.cfg

(double check /boot/grub is the right path)

[lminiero]

@shmuelzon any update?

[shmuelzon]

Hey,

Once again, I'm really sorry for the delay here but I'm happy to say I finally got the chance to test this.
I'm also happy to say that it works as expected in my scenario.
I see the new log message:

[Thu Mar 31 07:40:20 2022] [WARN] IPv6 disabled, will only create VideoRoom forwarders to IPv4 addresses

And RTP forwarding for video rooms also works.

I'd just note that I only tested the video room plugin on 0.10.5 and needed to backport your patch. There were some conflicts (nothing major) so I'm attaching here the patch I used:
ipv4_only.patch.txt

Thanks again for all you help!

[lminiero]

Ack, thanks for the feedback, I'll merge then, and after that I'll backport the same fix to 0.x.

[lminiero]

The above commit added the same feature to 0.x, please let me know if this doesn't work as expected.

[shmuelzon]

Will do, thanks again!