I want to Integrate exotel with livekit cloud project to test krisp_enabled=True feature. Agent is already deployed , sip trunk is created, dispatch rule is also create. I have also integrated sip uri , connected with trunk id received after from exotel, setup the call flow in exotel . Below are the documents i followed. Voice_agents | Agents. Inbound trunk | LiveKit Documentation Dispatch rule | LiveKit Documentation Agents telephony integration - Agents telephony integration | LiveKit Documentation Unfortunately, I'm receiving the call , but it getting disconnected on instant. Please verify all of the steps. And also let know how can i cross-check and verify the location of sip server. If not India, then can I even proceed with different sip locations.

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

5g7ne8ue0lq.sip.livekit.cloud. this is the sip uri I'm using. Also, how can i cross-verify whether my agent/webhook is hosted in India or elsewhere?

Thanks — that SIP URI explains the likely cause. Acknowledgement • You’re currently using

5g7ne8ue0lq.sip.livekit.cloud

. For India PSTN flows you must use the India-specific hostname ending with

.in.sip.livekit.cloud

. Using the non-

.in.

hostname can route signaling or media outside India and cause immediate disconnects. What to change right away • Update Exotel to use: ◦

p_5g7ne8ue0lq.in.sip.livekit.cloud

◦ (Replace

p_5g7ne8ue0lq

with your exact project id if it differs — earlier you referenced

p_5g7ne8ue0lq

.) How to verify whether your agent/webhook is hosted in India Try these checks in order — each is quick and will tell you where the server is running: 1) Check your cloud provider region (easiest) • If your webhook/agent runs on a cloud VM, container, or serverless function, open the instance details in your cloud console (AWS/GCP/Azure/DigitalOcean/etc.) and check the region/availability zone. Look for regions like

ap-south-1

(AWS Mumbai),

asia-south1

(GCP Mumbai), or equivalent — those indicate India hosting. 2) Inspect the server’s public IP and geolocate it • From your webhook/agent server run: ◦ curl ifconfig.co ◦ or check the public IP in your cloud console. • Then use an IP geolocation lookup (e.g., ipinfo.io/&lt;IP> or geoip tool) to verify the country. Note: geolocation databases aren’t perfect, but they give a fast indication. Example commands: • Get public IP: ◦ curl https://ifconfig.co • Look up location: ◦ curl https://ipinfo.io/&lt;your-ip&gt;/json 3) DNS and reverse lookup of your webhook hostname • If you have a hostname for the webhook, run: ◦ nslookup your-webhook-hostname ◦ dig +short your-webhook-hostname • Then geolocate the returned IP(s) as above. 4) Use traceroute to check network path • From a terminal (macOS/Linux/WSL): ◦ traceroute your-webhook-hostname • On Windows: ◦ tracert your-webhook-hostname • Look at the hops — if the path quickly shows Indian ISP hops or ends in an Indian IP block, it’s hosted/egressing from India. If hops show Europe/US early on, it’s outside India. 5) Confirm RTP/Signaling flows during a test call • Make a test inbound call and capture network traffic on the webhook/agent host (tcpdump) to see where RTP packets go. Example (run as root): ◦ tcpdump -n host <peer-ip-or-trunk-ip> and port 5060 or port range for RTP • Verify RTP destination IPs fall within Indian egress ranges (LiveKit India egress ranges include 143.223.88.0/21 and 161.115.160.0/19). What to send me next (so I can help further) • Confirm you updated Exotel to

p_5g7ne8ue0lq.in.sip.livekit.cloud

(or tell me the exact project id you used). • Paste the public IP (or the result of

curl <https://ifconfig.co>

) from the webhook/agent host so I can help interpret its geolocation. • If comfortable, paste a short snippet of the Exotel SIP trace for one failed call (INVITE → responses → BYE) or tell me the SIP response codes you see. Quick note on krisp and audio • After fixing routing/region, ensure you use

krisp_enabled=True

OR agent-side BVC noise cancellation — not both. Using both can corrupt audio and cause other issues. If you confirm the SIP hostname and the webhook IP, I’ll guide you through the traceroute/tcpdump commands to validate that both signaling and RTP stay in India and help narrow down the cause of the instant hangup.

I'm using "livekit cloud" for this particular project. how to check if agent/webhook is hosted in India

Thanks — this is clear and helpful. I’ll answer your two questions directly: why the disconnect happens with your current SIP URI, and exactly how you can confirm whether your agent/webhook is hosted in India. Acknowledgement • You’re using the SIP URI

5g7ne8ue0lq.sip.livekit.cloud

. That explains the likely cause of the instant disconnect. • You asked how to verify whether your agent/webhook is hosted in India. Short answer • Use the India-specific SIP hostname to keep SIP signaling and media in India:

p_5g7ne8ue0lq.in.sip.livekit.cloud

. • LiveKit Cloud’s managed Agents and webhook processing run in supported regions (typically US or EU) and are not hosted in India. To meet India PSTN requirements you must ensure the webhook/agent that answers the SIP INVITE runs on infrastructure you control inside India. Why the call disconnects • When PSTN calls touch India, both SIP signaling and RTP media must remain inside India. Using the non-

.in.

hostname can route signaling or media through non-Indian POPs, and carriers (like Exotel) will often drop the call instantly if traffic leaves India. What to do right now 1. Update Exotel to use the India SIP hostname: ◦ Set the trunk target to:

p_5g7ne8ue0lq.in.sip.livekit.cloud

◦ Replace

p_5g7ne8ue0lq

with your exact project id if needed. 1. Ensure your webhook/agent is hosted in India: ◦ If your webhook or agent is an endpoint you control, deploy it to an India region (examples: AWS ap-south-1, GCP asia-south1, Azure Central India). ◦ If you rely on LiveKit-managed Agents, know that they run in supported regions (US/EU) — you cannot move LiveKit-managed agent compute into India. For compliance you must host the answering webhook/agent in India yourself. How to verify where your agent/webhook is hosted (quick checks) 1. Check your cloud provider region: ◦ Open the instance/container/function details in your cloud console and look at the region (e.g., AWS

ap-south-1

, GCP

asia-south1

= India). 1. Check the public IP and geolocate it: ◦ On the server hosting your webhook/agent, run: ▪︎ curl https://ifconfig.co ◦ Then query: curl https://ipinfo.io/&lt;IP&gt;/json ◦ The response shows country/region. 1. DNS lookup (if you use a hostname): ◦ Run: nslookup your-webhook-hostname or dig +short your-webhook-hostname ◦ Geolocate the returned IP(s) as above. 1. Traceroute (to see network path): ◦ traceroute your-webhook-hostname (macOS/Linux) or tracert on Windows. ◦ Look for hops within Indian providers or IP blocks; early non-Indian hops show it’s outside India. 1. Capture traffic during a test call: ◦ On the webhook/agent host run tcpdump while making an inbound test call and confirm RTP destinations are within Indian IP ranges (or the LiveKit India egress CIDRs if available). What I need from you to continue helping • Confirm you’ve updated Exotel to

p_5g7ne8ue0lq.in.sip.livekit.cloud

. • Paste the output of curl https://ifconfig.co from your webhook/agent host (the public IP) or tell me the cloud region shown in your cloud console. • If you can, share a short Exotel SIP trace for one failed call (INVITE → responses → BYE) or the SIP response codes you see. Next steps I’ll help with after you share that • If the IP shows the webhook is outside India, I’ll outline how to deploy a minimal India-hosted webhook/agent for testing. • If webhook is in India and calls still drop, I’ll walk you through precise tcpdump/traceroute checks and the log traces to collect from Exotel and LiveKit to find whether signaling or media left India or a SIP-level rejection occurred. • I’ll also confirm krisp usage: enable

krisp_enabled=True

on the LiveKit side and ensure you’re NOT also enabling agent-side BVC noise cancellation at the same time. If you paste the public IP or cloud region now, I’ll interpret it and give the next command(s) to verify RTP/signaling paths. Sources: Data Processing Addendum | LiveKit | Support data sovereignty in Saudi Arabia | LiveKit | Support data sovereignty in India | LiveKit

sip:5g7ne8ue0lq.in.sip.livekit.cloud:5060;transport=tcp this also didn't work.

Thanks — I can see you tried the India hostname but it’s still failing. I’ll help narrow this down quickly. Acknowledging what you tried • You attempted:

sip:5g7ne8ue0lq.in.sip.livekit.cloud:5060;transport=tcp

and the call still disconnects immediately. Immediate checks and likely cause • The India hostname must include your project prefix exactly as LiveKit expects. Earlier you referenced

p_5g7ne8ue0lq

as the project id. The correct SIP target should be: ◦ p_5g7ne8ue0lq.in.sip.livekit.cloud • Using

5g7ne8ue0lq.in.sip.livekit.cloud

(without the leading

p_

if your project id includes it) will still route incorrectly and can cause immediate hangups. Please confirm this first: 1) What is the exact project id shown in the LiveKit Cloud dashboard? If it is

p_5g7ne8ue0lq

, change the Exotel trunk target to: • sipp 5g7ne8ue0lq.in.sip.livekit.cloud5060;transport=tcp If that does not fix it, I need three small pieces of info to continue troubleshooting: A — Public IP / hosting-region of your webhook/agent • On the machine hosting your webhook/agent, run: ◦ curl https://ifconfig.co • Paste the returned IP (or the cloud provider region if you know it, e.g., AWS ap-south-1). This tells me whether your webhook is actually running in India. B — A short Exotel SIP trace for one failed call • From Exotel logs, copy the SIP exchange around the failed call (INVITE → any provisional or final responses → BYE). Even the SIP response codes (like 403/403/480/486/etc.) and any Reason headers will help pinpoint why the call is torn down. C — Any LiveKit telephony/agent logs for that call (trace id or timestamps) • If you can share the LiveKit call/session ID or a timestamp for the failed call, I’ll tell you which log lines to look for and what to paste. Other quick checks while you gather that • Ensure your Exotel trunk uses TCP on 5060 (as you set) and that no intermediate firewall/NAT is blocking SIP or RTP ports. Confirm Exotel is set to send signaling to the exact

p_...in.sip.livekit.cloud

host. • Confirm you are not mixing PSTN + WebRTC legs in the same session for this test. • Confirm

krisp_enabled=True

is not used together with any other agent-side noise cancellation at the same time. If you share the three items above (project id confirmation, webhook public IP/region, and a short SIP trace), I’ll: • Confirm the exact SIP hostname you must use, • Verify if your webhook is outside India and how to move/replicate it inside India for testing, • Read the SIP trace to identify the hangup reason and give next steps (tcpdump/traceroute commands or config fixes).