Hi Guys I 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...

whats the region for twilio

routing is in AU1 region SIP trunks are also in au1

you could try a different sip provider with location in Mumbai

i tried plivo with indian numbers Still ~2s

did that cut the latency by .6s?

Yeah can say that cut around ~0.3s

Yes, I asked cause it seems the voice provider is whats adding to the latency based on your testing. We use direct telco connection to optimise on that. But overall Latency also depends on the agent and turn complexity. We've written a bit on it here: https://byondlabs.tech/blog/voice-agent-latency-the-sub-second-tuning-playbook

BTW here 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"}

We are observing the same issue - using Vobiz for telephony Any insights on how we could reduce the telephony leg latency? We changed from a Livekit <> SIP based approach to Pipecat <> Websocket based one and latency is atleast 1 second lower That leads me to believe that Livekit Cloud might be the culprit here

You're using pipecat for sip calls and getting 1s lower latency ? whats the total latency now ?

No, Pipecat <> Websocket based method

Yeah exactly, for higher volumes n traffic scaling n monitoring suffers, im getting ~2.5s on selfhsoted livekit sip calls

Understood, 2 second overall or only for the WebRTC<>SIP converter component?

~2.5s overall and when using livekit cloud creds then its around ~2.2s

Understood, thanks!