Support IPv6 address resolution without DNS resolver

[nanang]

This ticket will enable PJSUA application to resolve target hostname to IPv6 address. As currently PJLIB-UTIL DNS resolver has not completely supported IPv6 yet, the resolution will only work when DNS server setting (i.e: pjsua_config.nameserver) is not configured, the library will resolve hostname using pj_getaddrinfo().

Account transport type

This new field is added to PJSUA account structure (in pjsua internal), it represents account transport preference, i.e: local account will always have specific transport type (as it is created with transport ID param), and normal account will have specific transport type only if it is bound to specific transport, i.e: via pjsua_acc_config.transport_id.

For better

Contact generation

• If account is bound to a specific transport address family of the contact will use the transport address family.
• Otherwise:
  • if target is an IP address, generated contact will use the same IP version as target
  • if target is a hostname (this is rather difficult as we don't really resolve the target here, except for a special case below):
    • if account transport type is specified, generated contact will use IP version as account transport type
    • otherwise, it will use IPv4
    • special case when pjsua_acc_config.contact_use_src_port is set (by default it is set) and target param transport is TCP/TLS, it will resolve target hostname first, try to connect to that IP using transport with the same IP version as target, and update Contact address with the transport binding address, so if the hostname is resolved to IPv6, Contact address will use IPv6 address.

SIP transport

• If account is bound to a specific transport, it will use that transport
• Otherwise, it will use transport with same IP version as target (resolved address, if it is a hostname)

Media

Media transport is independent from SIP, currently it will simply follow the account setting, i.e: pjsua_acc_config.ipv6_media_use.

Caveat

• When making call using hostname 'localhost' (on Windows 10), it will now resolve to IPv6 address (was to IPv4 address). The solution is to make call using account that is bound to IPv4 transport. The OS seems to by default register 'localhost' as '::1' and '127.0.0.1' and '::1' has higher priority.