[FFmpeg-devel] [PATCH] Make RTP work with IPv6 enabled

[Luca Abeni]

Hi Ronald,

Ronald S. Bultje wrote:
[...]
>> The first UDP socket is used for receiving RTP packets (and I think the
>> rtsp
>> demuxer should NEVER use this socket for sending anything), while the
>> second
>> one is used for sending/receiving RTCP packets. Note that the destination
>> address for this socket is known since the beginning (it's the rtsp server
>> address).
> 
> 
> But not configured, rtsp.c is doing the least it has to do. You'll notice it
> opens rtp://?localport=X
Ok; I think this could be one issue. When opening "rtp://?localport=X", udp.c
binds the socket to localport on a local IP address. The problem is that the
machine can have multiple IP addresses, and in particular it can have an IPv4
address and an IPv6 address. I suspect udp_open() ends up binding to the
first address returned by getaddrinfo(), right? So, it can bind the socket to
the wrong address.
The problem is that the current API has no way to specify the local IP address.
Adding a "?localip=..." tag should address this problem properly (and this will
also help when the machine has multiple ethernet cards... :).
As I said, rtsp.c has enough information to know the correct local address, so
it can be modified to pass a correct localip tag and everything should be ok.

[...]
> One way to solve this is to open rtp://<host>?localport=X, then later call
> (again) rtp_set_remote_uri() once we received the transports and know the
> ports, but then you resolve the same host multiple times, which is network
> traffic and thus sort of stupid. Below is a patch doing this.
I cannot comment too much on this patch (I am not the RTSP maintainer), but
maybe it is a way to go. I prefer my "localip" (or "localhost") proposal
because it looks more logical to me, but we should really wait for comments
from Luca Barbato.


> I am sure I am missing something, but I really do not see any problem here.
>> Are you talking about the RTP sockets or the TCP socket used for RTSP
>> commands?
>> If you are talking about the RTP sockets, I believe that the target
>> address
>> and its family are known, because when RTP sockets are created the RTSP
>> connection
>> is already up (so, the server has already been contacted).
> 
> See above, rtsp.c doesn't use this when opening the rtp uri.
Well, of course rtsp will need to be modified... We just need to find the
most reasonable way to do it. I have the impression that RTP, RTSP, and
network support in ffmpeg is grown adding features and fixes without a
clear design... And this lead to the current mess. Maybe it's time to fix
it :)

> Also note that the SDP should tell you if we are going to send/receive
>> traffic over
>> IPv6 or IPv4.
> 
> So I guess another way to solve this is that I could add a ?family=ipv4/ipv6
> param to the udp/rtp options.
I wanted to propose something similar since the beginning...

> Kind of ugly...
But I did not propose it because I expected similar reactions ;-)


> Attached patch ffmpeg-udp-use_correct_family.patch implements the first
> proposed solution and replaces my previously submitted patch
> ffmpeg-udp-send_and_connect.patch. It changes rtpproto.c to not increase the
> provided portnum if none is given (which is on purpose).
I have to fully read and understand the patch, but I do not understand why this
is needed... When and why is rtp_set_remote_url() called without specifying
a remote port?

[...]
> With this patch, I can stream rtp/udp from ffserver.
Arg... My head is spinning again :(
The changes discussed in this email should affect the rtsp demuxer, not
ffserver (ffserver always specify a remote host when opening rtp:// URLs)...

				Luca