Support #2377
open
DNS Resolution Failure for `sip.cloudonix.io`
0%
Description
We are experiencing DNS resolution failures for sip.cloudonix.io, which are causing VoIP call timeouts in our system. The logs show the following error:
Failed to resolve 'sip.cloudonix.io'. Err=320046 (No working DNS nameserver (PJLIB_UTIL_EDNSNOWORKINGNS))
This results in call setup failures due to transport errors. The issue occurred during a call session with Session ID: eac0eaa99c8a4de3b8a6afda4ece0acb, where the call was first marked as CALLER_CONNECTION_STARTING, but eventually failed with CALLER_CONNECTION_DISCONNECTEDDUETOTIMEOUT.
The system attempted to dial 1001019592@prod.watchinu.com, but the call could not proceed due to the DNS resolution failure. This has been impacting our VoIP service reliability, and we would appreciate your assistance in diagnosing and resolving this issue.
Could you please check if there are any issues on your end affecting DNS resolution, or provide guidance on how we can resolve this on our side?
Files
Updated by Oded Arbel 6 days ago
- Status changed from New to Feedback
We know of no issues with our DNS service, and according to the error message quoted - that is not the problem.
According to the error message, the SDK failed to connect with a DNS server at all - so the DNS query to the local resolver failed. If there was an issue with the Cloudonix DNS service provider, you'd expect to either PJLIB_UTIL_EDNSNOANSWERREC error or PJLIB_UTIL_EDNS_NXDOMAIN error.
Are you using the USE_LOCAL_NAME_SERVERS configuration flag in the SDK? we've discussed this before and IIRC you are using that flag. If so - this is likely a problem with the network provider: the USE_LOCAL_NAME_SERVERS sets the SDK to use whatever DNS resolver is published by the network provider as the "LAN DNS resolver".
Updated by Vahnish Itamar 6 days ago
- File 275072-13-02.log 275072-13-02.log added
Hey Oded,
Thanks for the quick response. We are using USE_LOCAL_NAME_SERVERS.
I forgot to post the full logs. Let me know if you find anything else. Might be a DNS configuration issue with the user's wifi. I will ask to try on cellular. But if you can take a look at the logs and see if I missed anything.
Thank you.
Updated by Oded Arbel 6 days ago
I've reviewed the logs quickly, and the full context is this:
[MobileSDK-5.2.72.3277] 393481631 PJLog: sip_resolve.c PJSIPImpl Starting async DNS A query: target=sip.cloudonix.io, transport=TLS, port=443 [MobileSDK-5.2.72.3277] 393481632 PJLog: resolver.c PJSIPImpl Nameserver [2001:4860:4860::8844]:53 state changed Probing --> Bad [MobileSDK-5.2.72.3277] 393481632 PJLog: sip_resolve.c PJSIPImpl Failed to resolve 'sip.cloudonix.io'. Err=320046 (No working DNS nameserver (PJLIB_UTIL_EDNSNOWORKINGNS)) [MobileSDK-5.2.72.3277] 393481632 PJLog: tsx0x1161fb8a8 PJSIPImpl Failed to send Request msg INVITE/cseq=594 (tdta0x11cbf80a8)! err=320046 (No working DNS nameserver (PJLIB_UTIL_EDNSNOWORKINGNS)) [MobileSDK-5.2.72.3277] 393481632 PJLog: tsx0x1161fb8a8 PJSIPImpl State changed from Null to Terminated, event=TRANSPORT_ERROR [MobileSDK-5.2.72.3277] 393481632 PJLog: dlg0x11c89e8a8 PJSIPImpl Transaction tsx0x1161fb8a8 state changed to Terminated [MobileSDK-5.2.72.3277] 393481632 cxsdk.PJSIPImpl: Entering on_call_tsx_state call 1 [MobileSDK-5.2.72.3277] 393481632 cxsdk.PJSIPImpl: Entering on_call_state on_call_state PJSIP_EVENT_TSX_STATE [MobileSDK-5.2.72.3277] 393481632 cxsdk.PJSIPImpl: Call info->last_status = 503 tx state: DISCONNECTED DISCONNCTD
A. This is not using USE_LOCAL_NAME_SERVESR - the configuration that has USE_LOCAL_NAME_SERVER is the watch, and in this case, its the iOS caregiver app - it is using the default Google name servers.
B. Several transactions were successful before the problematic transaction (at 2025-02-13 14:05:00).
C. From the last reachability report (at 2025-02-13 14:04:40), the device is on WiFi that has only a reachable IPv4 address.
D. For some reason, the SDK decided to make a DNS query to the IPv6 DNS server address 2001:4860:4860::8844 - which then failed as expected.
It is not clear why that happened - as can be seen at 2025-02-13 14:04:40.6940, the SDK is expected to make a DNS query to all 4 default name servers (2 on IPv4 and 2 on IPv6), which doesn't seem to be the case at (at 2025-02-13 14:05:00).
I will investigate more tomorrow.