Thanks — I’ve looked at what you shared. You’re seeing ~3s delay on SIP calls while the same agent on web chat responds in under 1s. Below I’ll explain the likely causes and give concrete steps you can try to reduce that SIP latency. Acknowledgement • You’re asking why SIP calls are ~3 seconds slower than web chat for the same agent. That difference is expected because SIP and WebRTC use different media flows and processing. Likely causes (what’s adding the delay) • Media transport and protocol overhead: SIP/RTP flows through PSTN/carriers and gateway hops, which add jitter, added buffering, and signaling latency. WebRTC uses optimized SRTP and peer/server paths with lower latency. • Transcoding / media bridging: SIP audio frequently needs bridging/transcoding between RTP and WebRTC-compatible codecs on the media bridge, which adds processing time. • SIP gateway / carrier hops: Third‑party trunks and carrier routing introduce extra network hops and signaling (INVITE/200 OK) before the session is fully established. • Endpointing / turn detection delays: AgentSession settings such as

min_endpointing_delay

and

max_endpointing_delay

(defaults can be 0.5s and up to 3s) increase perceived response time when voice activity detection is uncertain on lower‑quality SIP audio. • Audio processing (noise cancellation, VAD): Extra noise suppression or conservative VAD required for telephone audio can add latency compared with cleaner web mic audio. • Geographic and service co‑location: SIP calls coming through distant PSTN gateways or different regions increase RTT compared to a web client connecting directly to the LiveKit server. • Call setup sequencing: Outbound SIP flows commonly wait for the SIP participant to be answered (e.g.,

wait_until_answered=True

) before the agent joins, adding setup time not present in web chat. Recommended optimizations (practical steps) 1. Reduce endpointing delays ◦ Try lowering

min_endpointing_delay

(e.g., to 0.3s) and reduce

max_endpointing_delay

if acceptable for your use case. ◦ Example:

session = AgentSession(
         min_endpointing_delay=0.3,
         max_endpointing_delay=1.5,
         # ...
     )

1. Use a semantic turn detector ◦ Enable a turn detector model (for example

MultilingualModel

) to get faster, more accurate end‑of‑turn detection on noisy SIP audio. 1. Remove intermediate carriers where possible ◦ Use LiveKit Phone Numbers / first‑party telephony instead of third‑party SIP trunks to reduce carrier hops and signaling latency. 1. Collocate services ◦ Ensure STT, TTS, and LLM services and your agent worker are deployed in the same region as the LiveKit media server to reduce RTT. 1. Minimize transcoding ◦ Keep codecs consistent end‑to‑end where practical (e.g., prefer Opus) to avoid transcoding at the bridge. 1. Monitor metrics to find the bottleneck ◦ Track Time To First Token (TTFT) and Time To First Byte (TTFB) for both SIP and web flows to see whether the delay is media transport, STT/TTS/LLM, or setup time. 1. Tune audio processing ◦ If aggressive noise suppression is enabled, test with reduced settings to see if it cuts latency without hurting recognition quality. If you want, I can help further if you share: • whether the ~3s is total time from caller speech to agent reply or just initial call setup time, • your AgentSession settings (values for

min_endpointing_delay

/

max_endpointing_delay

, whether a turn detector is enabled), • whether you’re using third‑party SIP trunks or LiveKit Phone Numbers, • region/deployment info for the agent worker and STT/TTS/LLM services. With any of those details I’ll suggest the most targeted next step. Sources: sip | livekit/livekit_composite | DeepWiki | An open source stack for real-time multimodal AI | An open source stack for real-time multimodal AI | Introducing LiveKit Phone Numbers: zero to ringing in 60 seconds | examples/dtmf | livekit/livekit_composite | DeepWiki