As the title says, this patch gets rid of the few places where we were still using gethostbyname (AudioBridge, SIP and NoSIP plugins) in order to use getaddrinfo instead, which we were already using in other places. This addresses issue #3156 which is where this was pointed out.
That said, this patch may have some implications that is worth investigating. In fact, the main point of getaddrinfo is that it makes it easier to use IPv6 as well, rather than stick to IPv4 which is what those plugins were doing, but this means we now use IPv6 sockets whether it will actually be v6 or not (so with IPV6_V6ONLY set to 0, via setsockopt). This is something we did with forwarders too, but in the past we figured out this could actually be problematic, e.g., on MacOS or systems that have IPv6 entirely disabled. As such, I'll have to probably add some tweaks to the current patch so that we create the socket with a specific family, maybe depending on the local_ip the plugins are using (still not sure).
Apart from this, simple functional tests (using IPv4 addresses) seemed to still work fine in both SIP and NoSIP plugins (I haven't tested plain RTP participation in the AudioBridge yet with this changes). If you use any of those plugins for RTP usage, you're strongly encouraged to test this PR, so that you're not caught by surprise if any regression we didn't anticipate shows up in your deployments.
As the title says, this patch gets rid of the few places where we were still using
gethostbyname
(AudioBridge, SIP and NoSIP plugins) in order to usegetaddrinfo
instead, which we were already using in other places. This addresses issue #3156 which is where this was pointed out.That said, this patch may have some implications that is worth investigating. In fact, the main point of
getaddrinfo
is that it makes it easier to use IPv6 as well, rather than stick to IPv4 which is what those plugins were doing, but this means we now use IPv6 sockets whether it will actually be v6 or not (so withIPV6_V6ONLY
set to0
, viasetsockopt
). This is something we did with forwarders too, but in the past we figured out this could actually be problematic, e.g., on MacOS or systems that have IPv6 entirely disabled. As such, I'll have to probably add some tweaks to the current patch so that we create the socket with a specific family, maybe depending on thelocal_ip
the plugins are using (still not sure).Apart from this, simple functional tests (using IPv4 addresses) seemed to still work fine in both SIP and NoSIP plugins (I haven't tested plain RTP participation in the AudioBridge yet with this changes). If you use any of those plugins for RTP usage, you're strongly encouraged to test this PR, so that you're not caught by surprise if any regression we didn't anticipate shows up in your deployments.