STUN with an FQDN fails with uvloop about aioice HOT 3 CLOSED

Just curious, is there a reason why you used gethostbyname instead of getaddrinfo? There's an async version of getaddrinfo available as AbstractEventLoop.getaddrinfo(host, port, *, family=0, type=0, proto=0, flags=0).

from aioice.

I'm using gethostbyname as we absolutely want only IPv4 addresses, does that make sense?

from aioice.

Um, not really?
My best guess: If a STUN server is dual-stack, a naive address resolution method may use only one IPv6 address, while a STUN server is much more useful for discovering IPv4 candidates because IPv4 is much more likely to be behind NAT.
If that's the case, then the best course of action is probably: If the host name resolves to both IPv4 and IPv6 addresses, take one of each and use them as two separate STUN servers.
And now I wonder whether any of the RFCs mention host name resolution for dual-stack STUN servers.

Anyways, getaddrinfo(..., family=socket.AF_INET) should also restrict resolution results to IPv4 addresses.

(I was a bit startled to see run_in_executor, but it turns out loop.getaddrinfo() is also implemented by running the synchronous socket.getaddrinfo() in an executor, so not much of an improvement there.)

from aioice.