[FFmpeg-devel] [PATCH] avformat/rtpproto: add support for RTP/UDP socket reuse

[Camille Oudot]

Hi, I'm back on the topic. Thanks to all of you for your comments.

> So I agree that SO_REUSEADDR is "absolutely not a hack"... if you use
> it to recycle IP/port pair without waiting for the time-out. But
> that's mainly of interest of listening/receiving sockets.

That is indeed the case for TCP sockets, but as far as I know this does
not apply to UDP as there is no TIME_WAIT state associated to datagram
sockets.

The classical use of this option would be for having a process binding
on udp:0.0.0.0:1234 then another one binding on e.g.
udp:192.168.1.10:1234 without triggering a "address in use" error. This
is indeed a matter of listening socket.

> If you use it to bind two concurrent sockets on the same IP/port
> pair, then it is absolutely not just a hack but a platform-dependent
> non-portable hack and a latent vulnerability in the OS (since one
> process can hijack datagrams for another).

The use of REUSEPORT instead of REUSEADDR is meant to mitigate this
risk (but it's far from perfect).


I definitely agree that using these options instead of refactoring or
rewriting the RTP protocol to support RTP bundle and RTCP mux is a
hack. I should take some time in the future to look into a proper
solution. In the meantime, several people are looking for this feature:

- http://ffmpeg.org/pipermail/ffmpeg-user/2018-September/041393.html
- https://trac.ffmpeg.org/ticket/1774
-
https://mediasoup.discourse.group/t/simulcast-with-plainrtptransport-and-ffmpeg/863


When the REUSEADDR option was added in FFmpeg UDP protocol what was the
reason back then? And wouldn't this reason also apply for RTP? If we
enable it for some legit reason, this could provide a (hacky and OS-
dependent) solution for RTP bundle and RTCP mux, until the RTP protocol
is properly refactored.

Regards

-- 
Camille