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

[Nicolas George]

L'octidi 8 brumaire, an CCXVI, Luca Abeni a ?crit?:
> Anyway, the problem here is that on MacOS X getaddrinfo() produces addresses
> that sendto() does not like. I do not think it's possible that sendto() is
> so broken (people would have noticed it before)...
> Probably the problem is in the getaddrinfo()+sendto() combination.

I may have an explanation. This is a wild guess, but it may work. In
udp_ipv6_set_local, in the call to udp_ipv6_resolve_host at the very
beginning, try to replace AF_UNSPEC by s->dest_addr.ss_family. I do not have
time to test myself, and I do not have a macos box near at hand anyway.

But I am afraid this hides some more protocol-related bugs. I will try to
look more deeply into it when I have time.

> Well, sizeof(struct sockaddr_in) for IPv4, and sizeof(<whatever an IPv6
> address is>) for IPv6 should do the job, no?

Until IPv8 comes around :)

The point is, if you get, for example, "www.ripe.net" from the user, with
the good old way, but assuming you want to support IPv6, you have to:

(1) try to resolve it for an AAAA record;
(2) try to create an INET6 socket;
(3) try to connect to the address.

And if anything above failed:

(4) try to resolve it for an A record;
(5) try to create an INET socket;
(6) try to connect to the address.

(1) can fail if the remote host does not have an IPv6 address.
(2) can fail if the local host does not support IPv6 (it can not be known at
    compile time).
(3) can fail if the local host does not have IPv6 connectivity.

For the same reasons, 4, 5, 6 can fail (and the whole point of IPv6 is that
(4) will be increasingly likely to fail as the IPv4 address space is
drained.

The method with getaddrinfo rolls everything in a single loop: the libc does
(1) and (4), and returns structures that allow to do (2-3) and (5-6) with
the same code.

> Uhmmm... Not sure this is the case for RTP/UDP streaming. When you stream
> over UDP, you just send UDP packets to a <destination address>:<port>,
> and that's a single address.

Unless <destination address> is a host name with both an AAAA and an A
DNS record.

>		      I am just trying to understand why things that I used to
> code in few lines need to be so complex when done properly :)

Unfortunately, Unix has that tendency to make things hard to do _really_
properly. With EINTR, for example.

Regards,

-- 
  Nicolas George