iOS and IPv6 problems (again)

[ednt]

Describe the bug

If we use IPv6 on iOS (15 and 16) we get several 'bugs'

1. sip_reg.c Invalid Contact: "sip:xxxxx@2a05:123:4556::1:52081;ob"
   We don't set the contact manually. The [] are missing (my opinion)

2. If we use a name as proxy it will not resolved in IPv6
   We can work arround this by getting the IPV6 address 'by hand' (getaddrinfo() with hint AF_INET6)
   and set it by acc_cfg.proxy.0 = pj_str("sip:[xxxxx]:5061")
   This works. Without [] it does not work. Against the documentation where mentioned that no [] should be used.

But if we have a network change we can not detect which transport is now used to set the new proxy.
(we need to set the new proxy since we wrote the IP address as proxy and not the name)
How can we detect the current used transport for an account?
We tried different things like pjsua_transport_get_info() and looked at usage_count,
the on_ip_change_progress_cb and looked at transport_id but all transports are affected and not only the current used one.

Steps to reproduce

Set a proxy by name and use IPv6 in an iOS app.

PJSIP version

2.13.1

Context

several iPhones with iOS 15 and iOS 16

Log, call stack, etc

sip_reg.c Invalid Contact: "<sip:xxxxx@2a05:123:4556::1:52081;ob>"


sip_resolve.c DNS resolver not available, target 'xxx.ednt.eu:5061' type=UDP will be resolved with getaddrinfo()
sip_resolve.c Failed to resolve 'xxx.ednt.eu': gethostbyname() has returned error (PJ_ERESOLVE)

[ednt]

Just tested on macOS:

In a pure IPv6 network the proxy name is also not solvable:

sip_resolve.c ...Failed to resolve 'dev-k4-64.ednt.eu': gethostbyname() has returned error (PJ_ERESOLVE)

If I use

ping6 dev-k4-64.ednt.eu

I get:

PING6(56=40+8+8 bytes) 2a0f:a4c2:1:60:d944:143b:f788:efcd --> 2a01:4f8:c2c:615b::1
16 bytes from 2a01:4f8:c2c:615b::1, icmp_seq=0 hlim=50 time=8.929 ms
16 bytes from 2a01:4f8:c2c:615b::1, icmp_seq=1 hlim=50 time=8.033 ms

The name is definately resolvable.

[ednt]

It makes also a difference if the name has only an AAAA record or A and AAAA record.
If there is only an AAAA record it looks that the name resolving stops when no A record (first search) is found.

If there are both entries, it stops after the A record is found.

At the first start (add account) it asks A and AAAA record for the domain. But never for the proxy.

We now also tested this stuff in linux and it is not working too.

[ednt]

The problem is not that we missconfigured IPv6 in PJSIP.

The problem on macOS / iOS is inside of pj_getaddrinf()

If you use hints.ai_flags = 0 it is handles like AI_DEFAULT according to the apple documentation.

This results in ::ffff:128.140.11.97 instead of 2a01:4f8:c2c:615b::1

That it works on macOS/windows/linux I added:

hints.ai_flags = AI_ALL|AI_V4MAPPED

And I needed to continue if a ::ffff adress was found.

Now we test it on iOS.

[nanangizz]

Let's discuss the first issue first. Yes, it seems to be a bug indeed, however I need to be able to reproduce the issue here for creating a fix. (Simply adding a check of IP address version returned by pjsua_acc_get_uac_addr() can be used for deciding whether IPv6 address brackets need to be added, but perhaps identifying the problem cause may be a good idea, e.g: it may provide some hints to some other bugs).

So, I used pjsua app, configured with target/proxy by name, with SIP transports IPv6 only (TCP6 & UDP6), without binding the account to this transport, I got

Unable to generate suitable Contact header for registration: Unsupported transport (PJSIP_EUNSUPTRANSPORT) [status=171060]

It is because the library assumes the target is IPv4 and it does not have any IPv4 transport. If there is any IPv4 transport, the contact will be using IPv4 address.

If account is bound to a IPv6 transport (as recommended by this IPv6 doc), the account Contact was setup properly (using IPv6 and square brackets).

So could you share your setups which may be related to the issue, e.g: whether account is bound or not to a transport, which transports are created by the app, whether the device has IPv6 address only, STUN or uPnP settings, NAT64 settings.

[sauwming]

Closing this due to lack of update. The implementation of #3590 should also help with this issue. Please feel free to reopen if you still have any problem even with #3590.