Use getaddrinfo instead of gethostbyname (fixes #3156) #3159
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.