why telephony (outbound call SIP) agent has more latency then web call agent? In my experience telephony (outbound call SIP) agent has ~2-3 seconds latency where web call agent has ~1-2 seconds latency? Is it because of us number from twilio?

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

What can i do to decrease latency in telephony agent? I am doing outbound call from twilio (US number) to india?

Thanks — I’m responding to your question about lowering latency for outbound telephony (Twilio US number → India). Below are targeted, practical steps you can take and a couple of quick diagnostics to pinpoint where latency is coming from. Quick summary • The biggest contributors are extra network hops (LiveKit → Twilio → PSTN → India endpoint), carrier routing, and gateway/transcoding by the SIP/PSTN provider. • You can reduce latency by removing intermediaries, co-locating services, choosing lower-latency carrier routes, and measuring where delays occur. Actionable steps to reduce latency 1. Reduce intermediary hops • Use LiveKit Phone Numbers (if available to you) instead of routing through Twilio SIP trunks. This removes a third-party SIP trunk hop and often lowers end-to-end delay. 1. Co-locate services and agents • Host your STT, TTS, and agent logic in the same region as your LiveKit deployment. For calls to India, consider using a region geographically closer to India (if LiveKit offers a South Asia region) or the region that minimizes round-trips to Twilio’s media egress. • Ensure your application server and media processing are in the same cloud region to avoid cross-region network hops. 1. Optimize the SIP provider path • Ask Twilio (or review their docs/console) for the media egress POPs used for calls to India and choose a provider or configuration that uses POPs closer to India. • If Twilio offers direct media anchoring or control over media region, select the region closest to the destination to shorten the PSTN leg. 1. Minimize transcoding and codec negotiation • Use a single high-quality codec end-to-end where possible (e.g., Opus) to avoid extra transcoding steps. • Configure your SIP trunk and Twilio settings to favor codecs that avoid server-side transcoding. 1. Provision capacity and prefer low-latency endpoints • Use provisioned inference or dedicated capacity for STT/TTS/LLM so model and TTS latency is stable and predictable. • Avoid routing audio through public SaaS endpoints that can add variable processing delay. 1. Tune RTP and network settings • Enable and tune jitter buffers conservatively (too large buffers add latency; too small cause packet loss). • Use QoS tagging on your network to prioritize real-time media if you control the network path to the media gateway. 1. Select better carrier routes for PSTN • Some carriers and routes into India are lower-latency than others. Compare carriers (or Twilio’s carrier choices) and test routes to find the fastest path. • If you regularly call the same destinations, provision direct SIP trunks or carrier interconnects that target lower-latency routes into India. 1. Reduce application-side processing • Batch or streamline any server-side audio processing before sending audio to the SIP gateway. • Keep voice activity detection (VAD), noise suppression, and any server-side audio transforms as lightweight as possible. Diagnostics to identify where latency is introduced 1. Timestamp checkpoints • Add timestamps at these points and compare: a. Audio capture at caller b. Arrival at LiveKit (or your app server) c. Handoff to Twilio SIP trunk (SIP INVITE/ACK times) d. Twilio media egress / PSTN answer e. Audio arrival at callee in India • This isolates whether the bulk of delay is before/after handing off to Twilio. 1. Run controlled tests • Place test calls from the same Twilio number to: ◦ A local US mobile number ◦ A phone in India ◦ A web (WebRTC) participant in the same region as your agent • Compare end-to-end latencies to see how much the PSTN leg to India adds. 1. Measure round-trip times and packet loss • Capture RTP stats (RTT, jitter, packet loss) on both sides if possible. High RTT/jitter on the Twilio → PSTN leg will point to carrier/PSTN issues. What I can help with next • If you share: the LiveKit region you’re using, whether you can switch to LiveKit Phone Numbers, and any STT/TTS providers/regions, I can give a prioritized checklist specific to your setup. • I can also provide a simple timestamping test plan you can run and the exact places to capture timing data. Which would you like to try first — a test checklist to measure where time is lost, or recommendations prioritized for your current region/setup?