[BUG]

[kwanjong]

Describe the bug:
When running multiple instances of srt-live-transmit on Amazon Linux 2 with distinct ports, I encounter an “Address already in use” error. The same commands worked fine on CentOS 7, so it appears to be specific to Amazon Linux 2.
This error does not occur every time but happens intermittently.

To Reproduce:
Steps to reproduce the behavior:
1. Run the first instance:
srt-live-transmit srt://:10005?mode=listener udp://127.0.0.1:30005
This starts successfully.
2. Attempt to run the second instance:
srt-live-transmit srt://:10405?mode=listener udp://127.0.0.1:30405
3. Observe the error: “Address already in use.”

Expected behavior:
Since I used different SRT ports (10005 vs 10405) and different UDP output ports (30005 vs 30405), I expected there would be no port conflict. On CentOS 7, the same commands and ports worked without issue.

Screenshots:
If relevant, please see the terminal output below (or attach a screenshot):
[…]
error message

The process already using port 10405.

Desktop (please provide the following information):
• OS: Amazon Linux 2
• SRT Version / commit ID: 1.4.1
• Installation method: built from source

Additional context:
• The same commands on CentOS 7 do not produce any error.
• It seems that srt-live-transmit might be reusing or sharing UDP sockets internally (multiplexer logic) on Amazon Linux 2, causing a conflict.
• I have tried different port combinations, but the issue persists whenever I run two instances.
• Any guidance on whether we need extra options like reuseaddr=false or a specific local endpoint configuration to avoid this conflict would be greatly appreciated.

Thank you!

[ethouris]

Did you try fuser -n udp 10405 after you can see this error message?

SRT is not responsible for having bound a UDP port that was not directly requested.

[kwanjong]

@ethouris
No, as shown in the screenshot attached in the main text, I used netstat -ltup after the error occurred to find the process already using port 10405.

In that case, is there any way to avoid UDP port duplication? Would something like reuseaddr=false work as a solution?

[ethouris]

I'm sorry, I'm confused. So you checked that and confirmed that the port has been bound by another application.

What you described is the intended behavior. Not sure what kind of bug you see here.

The SO_REUSEADDR option only allows the explicit local address to be allowed to bind to a port that was already bound to INADDR_ANY by another application. As you bind to INADDR_ANY here in both cases, this would change nothing.

If another application in the system has bound this port, SRT sockets cannot bind this port.

If you think of the SO_REUSEPORT option, SRT doesn't use it for a reason.

[kwanjong]

I believe I didn’t explain my situation very clearly before.

The following command starts up fine:
srt-live-transmit srt://:10005?mode=listener udp://127.0.0.1:30005

However, when I run this command:
srt-live-transmit srt://:10405?mode=listener udp://127.0.0.1:30405
I get an “Address already in use” error. It appears that the first srt-live-transmit process (on port 10005) is actually occupying UDP port 10405, causing a conflict when I try to start the second command.

Additional Information:

After encountering the error, I restarted the command
srt-live-transmit srt://:10005?mode=listener udp://127.0.0.1:30005,
and this made port 10405 available. As a result, I was able to successfully execute
srt-live-transmit srt://:10405?mode=listener udp://127.0.0.1:30405.

Question:

Even though I explicitly specified different ports (SRT ports 10005 vs. 10405, and UDP output ports 30005 vs. 30405), the operating system still perceives a conflict.
Is it not recommended to run multiple srt-live-transmit processes in parallel with different ports?
If there is a way to avoid this issue, I would greatly appreciate your guidance.

Thank you!

[ethouris]

All the examples you have shown should work with no problem, as long as no other application in the system has bound the ports that SRT would attempt to bind. If this command fails:

srt-live-transmit srt://:10405?mode=listener udp://127.0.0.1:30405

this simply means that the UDP port 10405 has been bound by another application in your system. Not sure about this 30405 port, but this shouldn't matter, the application doesn't bind a port to send to UDP, so likely it complains about the attempt of SRT to bind the port 10405. The message, however, sounds like the system error message, so this is likely the original error report from the system bind function call.

No, there's no way to avoid this issue. If you want to use this very port, you need to identify the application that has bound this port and ask it gently to free it, or kill this application if it doesn't conform.

Just to explain why no solution could be found: the port sharing for UDP, which can be set using SO_REUSEPORT actually allows multiple processes to read packets from their own sockets bound to the same port, which simply makes it possible that a randomly chosen application out of all those that bound this port can receive the packet that someone sent to this port. I'm not sure what appliances can make advantage of this solution, but there's no way to use it anyhow in SRT, as SRT requires exclusive access to the UDP link and every sinlgle packet that passes through it, with only tolerable packet loss.