I have hosted livekit on my server(mumbai)
Im havi...
# ask-aic
cuddly-bird-77915
04/17/2026, 10:06 AMI have hosted livekit on my server(mumbai)
Im having more latency over sip calls
My STT, LLM , TTS are fast (Groq ~300ms, Cartesia ~300ms and Deepgram ~220ms), everything up to date , twilio for number
No audio packet loss or jitter, No CPU or memory issues
On web calls(~1.5s to respond) it works fine but sip calls it takes time like ~2.6s
How should i figure out the root cause, i have tried everything...
✅ 1
t
tall-airline-16756
04/17/2026, 10:06 AMThanks for reaching out, Karrrtik. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
tall-airline-16756
04/17/2026, 10:06 AMThanks — I hear your frustration. You’ve confirmed STT/LLM/TTS are fast, no packet loss/jitter, and web calls are ~1.5s while SIP is ~2.6s. That gap suggests the extra latency is somewhere in the SIP path or routing rather than audio processing.
Please try these diagnostic steps so we can pinpoint the root cause:
1. Verify SIP region routing
◦ Is your Twilio trunk explicitly pinned to an India/Mumbai media gateway? If Twilio routes through a non-India gateway the RTT can increase even with a Mumbai LiveKit server.
◦ If you can, trace SIP INVITE/200 OK paths (SIP trace/pcap or Twilio call logs) and check RTT to the media gateway.
1. Confirm SIP region pinning on LiveKit
◦ SIP traffic must be region-pinned to keep media in Mumbai. Is SIP region pinning enabled for your LiveKit project (sip-in.ap-south.livekit.cloud)?
1. Compare per-stage timing between web and SIP
◦ Use your agent observability or logs to break down time spent in: VAD → STT → LLM → TTS → SIP egress. Which stage adds the extra ~1.1s on SIP calls?
1. Test with an alternate SIP path
◦ Temporarily route a call through a localized Indian SIP trunk (or another Twilio region/gateway) and compare latency. If latency drops, the original trunk/gateway is likely the issue.
1. Measure network RTT and hops
◦ From your Mumbai server, run traceroute/ICMP to the Twilio media gateway IPs and to the SIP endpoint you use. High hop-count or detours indicate routing issues.
1. Short A/B test
◦ Make the same call flow: (a) browser client → LiveKit, (b) PSTN via Twilio → LiveKit. Capture timestamps at handoff points so we can compare where the extra time occurs.
If you can share:
• The SIP gateway/region you see in Twilio logs (or media IPs),
• A per-call timing breakdown (VAD/STT/LLM/TTS/SIP egress), and
• Results of a traceroute from your Mumbai server to the SIP gateway,
I’ll help interpret them and recommend the next action (e.g., reconfigure Twilio gateway, enable SIP region pinning, or test alternative trunk).
Sources: Building Performant Voice Agents in India | LiveKit | Understand and Improve Agent Latency | LiveKit | Building Performant Voice Agents in India | LiveKit | Checklist for Regional Deployments | LiveKit | Introducing LiveKit Phone Numbers: zero to ringing in 60 seconds | LiveKit, with interactive elements
c
cuddly-bird-77915
04/17/2026, 10:54 AMhere are my latency metrics for a sip call (aus to aus number):
[LATENCY][SIP] source=periodic sample=3 rtt_ms=0.045 jitter_ms=2518.4 packet_loss_pct=0.0
[LATENCY][SIP] source=periodic sample=4 rtt_ms=0.051 jitter_ms=4889.601 packet_loss_pct=0.0
[LATENCY][SIP] source=periodic sample=5 rtt_ms=0.051 jitter_ms=7283.2 packet_loss_pct=0.0
[LATENCY][SIP] source=periodic sample=6 rtt_ms=0.051 jitter_ms=9676.8 packet_loss_pct=0.0
[LATENCY][TURN] turn_id=1 reason=agent_returned_to_listening stt_ms=614.308 ttft_llm_ms=517.716 tts_ms=180.128 eot_ms=1312.152 llm_ms=9150.543 ttfb_ms=517.716
[LATENCY][SIP] source=periodic sample=7 rtt_ms=0.051 jitter_ms=12086.4 packet_loss_pct=0.0
[LATENCY][SIP] source=periodic sample=8 rtt_ms=0.182 jitter_ms=14476.8 packet_loss_pct=0.0
[LATENCY][SIP] source=periodic sample=9 rtt_ms=0.182 jitter_ms=16876.8 packet_loss_pct=0.0
[LATENCY][TURN] turn_id=2 reason=agent_returned_to_listening stt_ms=433.874 ttft_llm_ms=316.3 tts_ms=161.974 eot_ms=912.147 llm_ms=8931.566 ttfb_ms=316.3
[LATENCY][SIP] source=periodic sample=10 rtt_ms=0.207 jitter_ms=19273.6 packet_loss_pct=0.0
[LATENCY][SIP] source=periodic sample=11 rtt_ms=0.182 jitter_ms=21654.4 packet_loss_pct=0.0
[LATENCY][SIP] source=periodic sample=12 rtt_ms=0.182 jitter_ms=24025.6 packet_loss_pct=0.0
[LATENCY][TURN] turn_id=3 reason=agent_returned_to_listening stt_ms=743.714 ttft_llm_ms=288.404 tts_ms=244.276 eot_ms=1276.394 llm_ms=5597.958 ttfb_ms=288.404
[LATENCY][SIP] source=periodic sample=13 rtt_ms=0.182 jitter_ms=26396.801 packet_loss_pct=0.0
[LATENCY][TURN] turn_id=4 reason=agent_returned_to_listening stt_ms=577.235 ttft_llm_ms=405.754 tts_ms=157.929 eot_ms=1140.917 llm_ms=6369.273 ttfb_ms=405.754
[LATENCY][SIP] source=periodic sample=14 rtt_ms=0.182 jitter_ms=28774.4 packet_loss_pct=0.0
[LATENCY][SIP] source=periodic sample=15 rtt_ms=0.182 jitter_ms=31164.8 packet_loss_pct=0.0
[LATENCY][SIP] source=periodic sample=16 rtt_ms=9.85 jitter_ms=35635.202 packet_loss_pct=0.0
[LATENCY][TURN] turn_id=5 reason=agent_returned_to_listening stt_ms=415.272 ttft_llm_ms=320.007 tts_ms=164.039 eot_ms=899.319 llm_ms=None ttfb_ms=320.007
[LATENCY][SIP] source=periodic sample=17 rtt_ms=4.73 jitter_ms=40515.201 packet_loss_pct=0.0
[LATENCY][TURN] turn_id=6 reason=superseded_by_new_turn stt_ms=444.088 ttft_llm_ms=534.313 tts_ms=None eot_ms=None llm_ms=None ttfb_ms=534.313
[LATENCY][SIP] source=periodic sample=18 rtt_ms=0.273 jitter_ms=43942.401 packet_loss_pct=0.0
[LATENCY][SIP] source=periodic sample=19 rtt_ms=0.273 jitter_ms=46787.2 packet_loss_pct=0.0
[LATENCY][SIP] source=periodic sample=20 rtt_ms=0.273 jitter_ms=49180.801 packet_loss_pct=0.0
[LATENCY][SIP] source=periodic sample=21 rtt_ms=0.273 jitter_ms=51580.8 packet_loss_pct=0.0
[LATENCY][SIP] source=periodic sample=22 rtt_ms=0.273 jitter_ms=53980.8 packet_loss_pct=0.0
[LATENCY][TURN] turn_id=7 reason=agent_returned_to_listening stt_ms=378.803 ttft_llm_ms=517.62 tts_ms=1187.13 eot_ms=2083.552 llm_ms=22166.152 ttfb_ms=517.62
[LATENCY][SIP] source=periodic sample=23 rtt_ms=0.273 jitter_ms=56371.2 packet_loss_pct=0.0
[LATENCY][TURN] turn_id=8 reason=agent_returned_to_listening stt_ms=144.947 ttft_llm_ms=2.285 tts_ms=112.324 eot_ms=259.556 llm_ms=None ttfb_ms=2.285
[LATENCY][SIP] source=periodic sample=24 rtt_ms=0.273 jitter_ms=58758.401 packet_loss_pct=0.0
[LATENCY][TURN] turn_id=9 reason=final_cleanup stt_ms=774.803 ttft_llm_ms=244.102 tts_ms=180.316 eot_ms=1199.22 llm_ms=None ttfb_ms=244.102
[LATENCY][SIP] source=final_cleanup sample=25 rtt_ms=0.375 jitter_ms=0.614 packet_loss_pct=0.0
[LATENCY_REPORT] {"source":"final_cleanup","recorded_at":"2026-04-17T103547.938Z","call_type":"sipcall","phone_number":"+6112345678","timestamps":{"call_created_at":"2026-04-17T103352.015Z","call_connected_at":"2026-04-17T103352.015Z","call_ended_at":"2026-04-17T103547.938Z","participant_context_resolved_at":"2026-04-17T103352.015Z","first_agent_speech_at":"2026-04-17T103353.798Z","first_user_speech_at":"2026-04-17T103404.625Z"},"pipeline":{"stt":{"unit":"ms","count":9,"latest":774.803,"avg":503.005,"min":144.947,"max":774.803},"ttft_llm":{"unit":"ms","count":9,"latest":244.102,"avg":349.611,"min":2.285,"max":534.313},"llm":{"unit":"ms","count":5,"latest":22166.152,"avg":10443.098,"min":5597.958,"max":22166.152},"tts":{"unit":"ms","count":8,"latest":180.316,"avg":298.514,"min":112.324,"max":1187.13},"eot":{"unit":"ms","count":8,"latest":1199.22,"avg":1135.406,"min":259.556,"max":2083.552},"ttfb":{"unit":"ms","count":9,"latest":244.102,"avg":349.611,"min":2.285,"max":534.313},"turn_count":9},"sip_transport":{"samples_collected":25,"last_sample_at":"2026-04-17T103547.938Z","rtt":{"unit":"ms","count":25,"latest":0.375,"avg":0.745,"min":0.0,"max":9.85},"jitter":{"unit":"ms","count":23,"latest":0.614,"avg":28515.227,"min":0.614,"max":58758.401},"packet_loss":{"unit":"percent","count":23,"latest":0.0,"avg":0.0,"min":0.0,"max":0.0}},"note":"runtime telemetry only; excluded from DB and API"}
t
tall-airline-16756
04/17/2026, 10:55 AMThanks — this data is very helpful. I’re responding to your SIP telemetry and the pipeline report.
Quick observations
• RTT is very low (avg ~0.75 ms, max 9.85 ms) and packet loss is 0% — network round-trip to the SIP endpoint is fine.
• Jitter is extremely high (avg ~28.5s, spikes up to ~58.8s) — those huge jitter values explain the perceived delay on SIP calls.
• LLM latency spikes (avg ~10.4s, max ~22.2s) and EOT/TTFB variability also contribute to overall turn time, but web calls don’t show the same user-facing delay, so SIP jitter + any SIP egress buffering is the likely immediate cause.
What this means
• Calls are hitting extreme jitter at the SIP transport layer; even without packet loss that will cause packet re-ordering, buffering, or retransmission behavior in the SIP/codec path and add seconds before audio is played out.
• The large LLM spikes increase end-to-end time for some turns, but the main difference from web ~1.5s → SIP ~2.6s is explained by SIP jitter and how the SIP path is handling playout/buffering.
Immediate next diagnostic steps (please run and share results)
1. Capture a short pcap of a SIP call (RTP) around an affected turn and check RTP timestamp continuity and packet arrival intervals. Look for large inter-packet gaps matching the jitter spikes.
2. From the Mumbai server, run continuous ping/traceroute to the SIP media gateway/gateway IPs reported by Twilio during the call to spot intermittent route changes or blackholes timed to jitter spikes.
3. Check Twilio trunk/media gateway settings:
◦ Which Twilio media gateway region/IPs were used for this call?
◦ Is the trunk pinned to an Australian gateway? If not, request region pinning so media stays local.
1. Confirm LiveKit SIP region pinning is enabled for your project (sip-in ap-south equivalent). If SIP egress is routed cross-region, that can amplify jitter impact.
2. Reproduce the call while switching codecs to a lower-playout-buffer profile (if configurable) to see if playout buffering is the main latency source.
Short tests you can run now
• A/B test: place identical call flows (same number) via Twilio vs a different local SIP trunk/provider and compare jitter/RTP pcaps.
• Short RTP stress: use iperf/udp to the media gateway during a call window to see if transient network congestion correlates with jitter spikes.
What I can help interpret if you share
• RTP pcap (or summarized RTP packet arrival times)
• Twilio call SID and media gateway IPs used for the call
• Traceroute/ping logs timed to jitter spikes
With any of those I’ll point at whether the issue is carrier/trunk routing, intermittent network path issues, or SIP playout buffering behavior and give concrete remediation steps (re-pin, change gateway, adjust playout settings).
Would you like to start with a pcap capture or the Twilio media gateway info?
, with interactive elements
2 Views