[1.x] can't create socket for streaming endpoint if ipv6 is disabled on host

[spscream]

What version of Janus is this happening on?
master

Have you tested a more recent version of Janus too?
no

Was this working before?
I don't have information

Is there a gdb or libasan trace of the issue?
no

Additional context
We have server with disabled ipv6 and if we create stream with following parameters:

    request_body = %{
      "request" => "create",
      "type" => "rtp",
      "id" => stream_id,
      "name" => description,
      "description" => description,
      "media" => [%{
        "type" => "audio",
        "mid" => "1",
        "port" => 0,
        "pt" => 111,
        "codec" => "opus"
      }]
    }

we got an error:

[ERR] [plugins/janus_streaming.c:janus_streaming_create_fd:7292] [(null)] Cannot create socket for audio... 97 (Address family not supported by protocol)
[ERR] [plugins/janus_streaming.c:janus_streaming_create_rtp_source_stream:7503] [(null)] Can't bind to port 0...
[ERR] [plugins/janus_streaming.c:janus_streaming_process_synchronous_request:3575] Can't add 'rtp' stream '(null)', error creating data source stream...

if I specify iface parameter for create all is working good. I think its due this ternary here(https://github.com/meetecho/janus-gateway/blob/master/src/plugins/janus_streaming.c#L7289):

fd = socket(family == AF_INET ? AF_INET : AF_INET6, SOCK_DGRAM, IPPROTO_UDP);

In case iface isn't set when family is 0, but AF_INET is 2.

[nekogasuki91]

Hello.

We encountered a similar problem with Janus in a docker container started on a host where IPv6 is disabled and with an RTSP stream. The container is based on a debian:12-slim image.

We patched by adding the line
family = AF_INET;
just before https://github.com/meetecho/janus-gateway/blob/master/src/plugins/janus_streaming.c#L7289.

It's dirty, but it allowed us to run the stream for test purposes while waiting for a fix or before switching to an alternative solution such as MediaMTX.

[lminiero]

The Streaming plugin probably just needs the ipv6_disabled property we added to other plugins (e.g. AudioBridge and VideoRoom), where we basically try and create an IPv6 socket as soon as the plugin is loaded, and if that fails, we set ipv6_disabled = FALSE which then impacts how sockets are created, for instance:

audiobridge->rtp_udp_sock = socket(!ipv6_disabled ? AF_INET6 : AF_INET, SOCK_DGRAM, IPPROTO_UDP);

There may be a reason why we didn't add it to the Streaming plugin too, back then, but on the top of my head I can't remember if that was the case.

[lminiero]

There may be a reason why we didn't add it to the Streaming plugin too, back then, but on the top of my head I can't remember if that was the case.

Checking the code, even in the VideoRoom where we have the IPv6 check, we actually only use it for forwarders but not for the RTCP socket, which is a socket that expects stuff on the way in, just as the Streaming plugin does in general for media too. I'll have to check my old notes to see if there was a reason why we didn't extend that to sockets for incoming data as well, rather than just sockets for sending data.

[lminiero]

@spscream @nekogasuki91 I made a first small fix, as I noticed a potential inconsistency in our IP utilities. Specifically, I noticed that if you passed "0.0.0.0" or "::", our interface lookup queries would fail, which I think was incorrect. Considering that we already have guidance for the REST and WebSocket transports to use "0.0.0.0" for binding when you don't have IPv6 at all, I thought we could do the same in the Streaming plugin, which is what this fix should enable.

Please do test and let me know if it helps. I don't see this as a definitive fix, considering that I still think the Streaming plugin should check if IPv6 is supported at all, for instance, and that this fix wouldn't help for VideoRoom RTCP support (where we don't have a way to specify an interface, IIRC?) , but at least it should be a good starting point, and something that was needed nevertheless for consistency.

[spscream]

@lminiero we will test it after NY, we are going to vacation till 8th of January

[spscream]

btw one our clients has faced problem today with ipv6 disabled and add_remote_publisher:

2024-12-28 13:28:46.253 call_id=6c5267f5-265f-55f7-809e-0be9b0da9918 pid=<0.23608.85> [warning] add_remote_publisher response: %{"janus" => "success", "plugindata" => %{"data" => %{"error" => "Could not open UDP socket for RTP stream", "error_code" => 499, "videoroom" => "event"}, "plugin" => "janus.plugin.videoroom"}, "sender" => 3349866170457039, "session_id" => 3119391460534970, "transaction" => "jd4LyK6hPUQ"}

I made them version with this commit and it doesn't help them.
We don't specify any interface for add_remote_publisher now, it starts to work if interface is specified.