SRT listener only responds on primary ipv4/ipv6 address

[hrodenburg]

Which version are you using?

1.15.4

Which operating system are you using?

Linux amd64 standard

Describe the issue

Hi,

When using Debian 13 (I don't think the exact distro/version matters) SRT clients can only connect to the primary ipv4 and ipv6 address of an interface. When trying to connect to a secondary ip when multiple ip addresses are set on an interface, this does not work, although srtAddress: :8890 is set. When explicitly specify the second address in srtAddress, the second ip is working.

Desired behaviour: Responding on all configured ipaddresses

Describe how to replicate the issue

As an example:

• Having a system with configured ipaddress 192.168.1.1/24, connecting to srt://192.168.1.1:8890?streamid=read:test is working as expected.
• add a secondary address, for example by: ip address add 192.168.1.2/32 dev eth0
• to be sure, restart mediamtx daemon (but doesn't make any difference)
• try to connect to srt://192.168.1.2:8890?streamid=read:test, this won't work.

When explicitly specify srtAddress: 192.168.1.2:8890, this works. But obviously this will become to only working address.
The exact same applies to ipv6.

I've checked the port bind, but by default it binds to all ip's:

$ ss -tulpen | grep 8890
udp   UNCONN 0      0                  *:8890             *:*           ino:41815 sk:1004 cgroup:/system.slice/mediamtx.service v6only:0 <->

This might be an issue in the upstream https://github.com/datarhei/gosrt, but I'm not sure about that.

MediaMTX configuration

pretty default, nothing special for SRT:

# Enable publishing and reading streams with the SRT protocol.
srt: yes
# Address of the SRT listener.
srtAddress: :8890

MediaMTX logs

On startup:

2025/12/03 16:56:48 INF MediaMTX v1.15.4
2025/12/03 16:56:48 INF configuration loaded from /etc/mediamtx.yml
2025/12/03 16:56:48 INF [metrics] listener opened on :9998
2025/12/03 16:56:48 DEB [path 3fmvsr_high] created
2025/12/03 16:56:48 DEB [path test] created
2025/12/03 16:56:48 DEB path manager created
2025/12/03 16:56:48 INF [RTSP] listener opened on :8554 (TCP), :8000 (UDP/RTP), :8001 (UDP/RTCP)
2025/12/03 16:56:48 INF [RTMP] listener opened on :1935
2025/12/03 16:56:48 INF [HLS] listener opened on :8888
2025/12/03 16:56:48 INF [WebRTC] listener opened on :8889 (HTTP), :8189 (ICE/UDP)
2025/12/03 16:56:48 INF [SRT] listener opened on :8890 (UDP)
2025/12/03 16:56:48 INF [API] listener opened on :9997

Nothing shows up on connecting (loglevel set to DEBUG).

A succesful connection shows:

2025/12/03 16:57:30 INF [SRT] [conn 172.30.50.24:54067] opened

Network dump

With tcpdump incoming data is observed, however no responses:

16:58:55.577161 IP 192.168.1.24.40735 > 192.168.1.2.8890: UDP, length 64
16:58:55.828854 IP 192.168.1.24.40735 > 192.168.1.2.8890: UDP, length 64
16:58:56.079693 IP 192.168.1.24.40735 > 192.168.1.2.8890: UDP, length 64
16:58:56.330686 IP 192.168.1.24.40735 > 192.168.1.2.8890: UDP, length 64
16:58:56.581684 IP 192.168.1.24.40735 > 192.168.1.2.8890: UDP, length 64
16:58:56.831712 IP 192.168.1.24.40735 > 192.168.1.2.8890: UDP, length 64
16:58:57.083660 IP 192.168.1.24.40735 > 192.168.1.2.8890: UDP, length 64
16:58:57.334652 IP 192.168.1.24.40735 > 192.168.1.2.8890: UDP, length 64
16:58:57.584702 IP 192.168.1.24.40735 > 192.168.1.2.8890: UDP, length 64
16:58:57.836678 IP 192.168.1.24.40735 > 192.168.1.2.8890: UDP, length 64
16:58:58.087672 IP 192.168.1.24.40735 > 192.168.1.2.8890: UDP, length 64
16:58:58.337723 IP 192.168.1.24.40735 > 192.168.1.2.8890: UDP, length 64