Does callkit work outside the US and are there special considerations needed when deploying?

Thanks for reaching out, William. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.

Not sure, but I have deployed it and people in US say it's working but people in other countries are reporting they aren't able to connect.

Thanks — I’m sorry non‑US users are having trouble. I’m following up on whether this is CallKit/VoIP push, network/ICE/TURN routing, or a deployment-region issue. To diagnose quickly, please provide as many of these as you can: 1. Platform & CallKit type ◦ Are affected users on iOS (Apple CallKit/PushKit), Android, or both? 1. Failure symptoms ◦ Do non‑US users: fail to receive incoming calls (no push), fail after answering (no media), or fail to establish the call at all? Any error text? 1. Deployment details ◦ Are you using LiveKit hosted, self‑hosted LiveKit, or a third‑party PSTN/SIP provider? ◦ Which cloud region(s) and where are your TURN servers located? 1. Push & entitlements (if iOS) ◦ Have you configured VoIP push (PushKit) and the Push Notification entitlement? Do push logs show delivery to non‑US devices? 1. Network conditions & examples ◦ Examples of countries/carriers where it fails, and whether users are on Wi‑Fi or mobile data. 1. Logs & artifacts ◦ Client SDK logs (ICE candidates, connect errors), server/LiveKit logs, room/session IDs and timestamps for failed calls, or WebRTC getStats output. 1. Frequency & repro ◦ Is it every non‑US user or intermittent? Any device models / OS versions showing a pattern? If you share a few example session IDs, timestamps, and which platform those users were on, I’ll inspect logs and outline exact next steps (TURN changes, push troubleshooting, or region-specific fixes). , with interactive elements

LiveKit hosted, callkit on ios

Thanks — I’m responding about CallKit on iOS with LiveKit hosted and non‑US users failing to connect. I need a few targeted details to diagnose quickly: 1. Failure symptom: do non‑US users fail to receive the incoming call (no CallKit UI / no VoIP push), or do they get the CallKit UI but the call fails after answering (no audio / ICE/connect error)? Any error messages? 2. Example sessions: please share 1–3 session/room IDs, timestamps, and the affected users’ country and iOS version so I can check logs. 3. Push config: did you enable VoIP push (PushKit) and upload the correct APNs key/certificate to the LiveKit dashboard for your production environment? Are pushes delivered to US users but not to others? 4. Network & TURN: ◦ Are affected users typically on mobile data or Wi‑Fi? ◦ Do you use LiveKit’s default TURN or have custom TURN credentials/regions configured? 1. Frequency & scope: is this every non‑US user or only certain countries/carriers? If you share the items above (especially a couple session IDs + timestamps), I’ll inspect the hosted logs and return exact next steps (push verification, TURN routing changes, or client config fixes). , with interactive elements

Operate under uncertainty and think what might be causing this. I've implemented CallKit according to your documentation and its working in US although sometimes the voice comes through the top speaker quietly like on a call instead of speakerphone but otehr than that is working fine. Problem is outside US people can't connect or they connect and cant talk and get duplicate greetings one after another.

Thanks — I’m responding about CallKit on iOS with LiveKit hosted where US users mostly work but non‑US users see connection failures, one‑way audio/duplicate greetings, and occasional audio coming from the phone earpiece. Below are the most likely causes and concise troubleshooting steps. After you try these, please share 1–3 example room/session IDs with timestamps and the affected users’ countries and iOS versions so I can check hosted logs. Likely causes & what to check • VoIP push (incoming call delivery) ◦ Symptom: non‑US users don’t see CallKit UI at all. ◦ Check: APNs VoIP key/certificate is uploaded for the correct environment (production vs sandbox) in the LiveKit dashboard. Confirm pushes are being delivered to non‑US device tokens (Push diagnostics / provider logs). • TURN / ICE routing and network reachability ◦ Symptom: clients connect but have no audio, or connect intermittently; duplicate greetings from re-connecting sessions. ◦ Check: Verify TURN servers are reachable from affected countries (some regions/carriers block UDP or specific ports). Try forcing TURN (TCP/TLS) in the client to test if NAT/firewall is the issue. • Mixed/mis-ordered session signaling (duplicate greetings) ◦ Symptom: users hear duplicate greeting messages — usually caused by retries, multiple publishers, or reconnect loops. ◦ Check: Confirm client logic avoids publishing the greeting multiple times on reconnect. Look at server/room logs for repeated join/publish events for the same user. • Audio routing on iOS (earpiece vs speaker) ◦ Symptom: audio plays quietly from top earpiece. ◦ Check: Ensure the audio session category/mode is set correctly for VoIP with CallKit (e.g.,

AVAudioSessionCategoryPlayAndRecord

/ appropriate mode) and that CallKit/AVAudioSession activation is performed per CallKit callbacks. Confirm speaker is forced when desired. Quick actionable tests to run now 1. Reproduce with one non‑US device on Wi‑Fi and on mobile data; capture client logs (ICE candidates, connect errors) and note timestamps. 2. Force TURN/TCP in the client and retry a failing call to see if media improves. 3. Temporarily enable verbose push logging in your push provider to see delivery attempts for non‑US device tokens. 4. Add a short server-side guard so greeting audio is played only once per successful publish (to rule out duplicate publish on reconnect). 5. On iOS test device, toggle AVAudioSession to speaker after the call connects to confirm routing behavior. What I can do next if you share examples • Inspect LiveKit hosted logs for the provided room/session IDs and timestamps to confirm push delivery, signaling errors, and any repeated join/publish events. • Point out specific ICE/TURN failures or push delivery results and recommend exact config changes (TURN regions/ports, push certs, or client fixes). If you share 1–3 session IDs, timestamps, and the affected countries/iOS versions I’ll check the hosted logs and return precise next steps. , with interactive elements

Can there be ghost disconnections due to battery optimisation in device?

Short answer: yes — iOS power/battery behavior can cause “ghost” disconnections that look like sudden call drops, missed media, or repeated reconnects. Why this can happen • iOS may suspend or throttle background work for apps that aren’t actively using required VoIP entitlements or whose audio session/CallKit integration isn’t kept active. • If VoIP pushes (PushKit) or CallKit activation aren’t handled exactly as required, the app can fail to wake reliably and the WebRTC connection may never establish — or it may connect briefly and then get suspended, causing one‑way audio or reconnect loops (which can cause duplicate greetings). • Aggressive carrier/NAT/firewall policies or blocked TURN ports in some countries can make clients rely on fragile direct connections that break when the app is backgrounded or the device’s network changes; that can look like ghost disconnects. What to check now (concise) 1. Confirm VoIP push & CallKit flow ◦ Ensure VoIP pushes are used to wake the app and CallKit is activated immediately on push. Do not start long network work before CallKit/AVAudioSession activation. 1. AVAudioSession & CallKit state ◦ Set AVAudioSession to

playAndRecord

(or equivalent) and activate it in the CallKit answer callback; ensure you set the proper category/mode so iOS doesn’t suspend audio. 1. Push certificate/environment ◦ Verify APNs VoIP key/cert uploaded for the correct environment. Check push delivery to non‑US tokens. 1. Keep reconnection logic safe ◦ Avoid background reconnect attempts that publish audio repeatedly; play greeting only once after a confirmed successful publish. 1. Network resilience ◦ Force TURN (TCP/TLS) in failing regions to avoid UDP-blocking carriers. Ensure TURN servers are reachable from affected countries and support TCP/TLS on common ports (443). 1. Device / OS factors ◦ Ask users to check Low Power Mode and any vendor battery optimizations. Note iOS version and device model for pattern detection. What to collect and share so I can investigate • 1–3 failing session/room IDs with timestamps, affected user country, iOS version, and whether they were backgrounded/locked or on Low Power Mode. • Client logs around the failure (ICE state changes, push receipt, CallKit callbacks, AVAudioSession activation). • Whether pushes were observed by your push provider for those attempts. If you share one example session and logs, I’ll inspect the hosted logs and show exactly where the connection dropped and which of the checks above will resolve it. , with interactive elements

Android

Thanks — I’m following up about Android. Quick clarifying questions so I can help precisely: 1. Are the failing non‑US users on Android only, or both Android and iOS? 2. On Android users: do they fail to receive calls, connect but have one‑way audio, or connect and hear duplicate greetings? Any error text or behavior pattern? 3. Android details: OS versions, device models, and whether users were on Wi‑Fi or mobile data when it failed. 4. Push & background: are you using FCM for incoming call notifications and waking the app? Do pushes show as delivered for non‑US devices? 5. TURN/network: are you using LiveKit hosted TURN or custom TURN servers? Which regions are affected? 6. Logs/examples: please share 1–3 session/room IDs with timestamps and any client logs (ICE state changes, connect errors). Why I ask: Android-specific causes differ from iOS — battery optimizers, Doze mode, improper FCM handling, or blocked TURN/UDP can cause ghost disconnects, one‑way audio, or reconnect loops. With the details above I’ll analyze logs and give exact steps (FCM/foreground service, audio focus/route handling, forcing TURN/TCP, or client reconnect fixes). , with interactive elements

Issue happening in android

Thanks — I’m responding about the Android failures for non‑US users. Quick clarification so I can diagnose precisely: 1. Symptom: do Android users fail to see incoming calls (no notification), connect but have one‑way audio, or connect and hear duplicate greetings? 2. Push: are you using FCM for incoming calls? Do pushes appear delivered for non‑US devices? 3. Network: are affected users on Wi‑Fi or mobile data, and which countries/carriers show the issue? 4. TURN/hosting: are you using LiveKit hosted TURN or custom TURN servers? Any custom TURN regions/ports? 5. Device info: Android OS versions and device models for affected users. 6. Examples & logs: please share 1–3 session/room IDs with timestamps plus client logs (ICE state changes, connect errors) for those sessions. Likely causes to check now (short): • FCM/foreground handling and WakeLocks/foreground service — Android battery/Doze can prevent app wake and break signaling. • TURN/UDP blocked by carrier or region — force TURN over TCP/TLS (port 443) to test. • Reconnect logic causing repeated publishes (duplicate greetings) when background reconnects succeed later. • Audio focus / routing on Android — ensure proper audio permissions and audio mode for VoIP. Next step: if you share the session IDs, timestamps, affected countries, and any logs, I’ll inspect the hosted logs and return exact fixes (FCM handling, TURN config, or client code changes). , with interactive elements

If i set dtx to false Audio packets will then constantly send and recieved So then it will not cut the connection

You're right — disabling DTX will cause the client to continuously send audio packets (even during silence), which can reduce the chance that a WebRTC connection is considered idle or gets adversely affected by network/codec timing — so it can help prevent the one‑way audio / “ghost” disconnect behavior you're seeing. Key points and tradeoffs • Effect: With DTX disabled you keep steady RTP packets flowing, which helps NAT/idle timeouts, keeps TURN allocations active, and reduces chances of reconnection loops that play duplicate greetings. • Bandwidth: Continuous packets increase upstream bandwidth (and downstream for other participants). Estimate depends on codec and packetization — expect higher data use. • Battery: More frequent encoding/transmission can increase CPU and battery use on mobile devices. • Not a full fix: If root causes are blocked UDP, TURN misconfiguration, FCM/Push/foreground handling, or buggy reconnect logic, disabling DTX mitigates symptoms but doesn’t address underlying issues. Recommended next steps 1. Keep DTX disabled as a short‑term mitigation for affected regions and monitor if failures stop. 2. While DTX is disabled, collect example failing session IDs and timestamps (if you still see issues) so I can inspect hosted logs for ICE/TURN/publish retries. 3. Test forcing TURN over TCP/TLS (port 443) from affected countries — this often fixes carriers/regions that block UDP. 4. Verify client reconnect logic so greeting audio only plays once after a confirmed successful publish. 5. Monitor bandwidth/battery impact on sample non‑US devices and revert when root cause fixed. If disabling DTX solved the problem for you, tell me how long you tested and any remaining symptoms (duplicate greetings, one‑way audio). If it didn’t fully fix it, please share 1–3 session IDs, timestamps, affected countries, and client logs and I’ll inspect the hosted logs for specific failures. , with interactive elements

@numerous-waiter-97064, you're in the wrong thread.

I don't have the answer you're looking for. You could also try asking your question: • in one of the other Slack channels or • to https://deepwiki.com/livekit/livekit_composite which is trained on all LiveKit source code If you find the answer, please post it here to help others!