Hi, I am seeing different latencies between Web calling and normal (Twilio) calling. Here are the two example calls, they both on the same assistant (same models, prompts, handoff flow) had very different perceived latencies between caller stop speaking and bot responding: - Call A (Twilio call): ~2.5s —

019da1f0-00d9-7000-b93e-05c9f4948b5c

- Call B (Web call): ~1.3s —

019da9ad-bd6c-788e-b3f1-e0b6ae337316

What's driving the ~1.2s difference? Side note: Latency I stated there is my percieved latency by reading audio recording graph. The Latency Summary numbers (1385 vs 1142) don't match the actual latency or what I see in the raw logs either. Thanks!

Latency differences are often caused by different

waitSeconds

or endpointing settings in your voice pipeline. To reduce Twilio call latency, try setting a more aggressive

waitFunction

in your `startSpeakingPlan`:

json
"startSpeakingPlan": {
  "smartEndpointingPlan": {
    "provider": "livekit",
    "waitFunction": "2000 / (1 + exp(-10 * (x - 0.5)))"
  },
  "waitSeconds": 0.2
}

Apply this to both Web and Twilio calls for consistent, faster response times. For more details, see the [Voice Pipeline Configuration documentation](https://docs.vapi.ai/customization/voice-pipeline-configuration). Source: - [Voice pipeline configuration](https://docs.vapi.ai/customization/voice-pipeline-configuration)

No they both have the same 100ms watSeconds setting.

Great question @N3squik that difference is actually pretty normal. What you’re seeing mostly comes from how the audio is handled before it even hits the assistant. Web calls (WebRTC) stream audio in real time with minimal buffering, so the system detects end-of-speech and responds faster. With Twilio, there’s extra overhead from PSTN/SIP routing, audio chunking, and more conservative silence detection, which adds a bit of delay before the assistant even starts processing. That’s also why your perceived latency doesn’t match the “Latency Summary.” Those metrics usually reflect internal processing time, not the full end-to-end delay you’re seeing in the audio graph. If you’d like, I can dig into those call IDs and help you reduce that gap there are a few tuning points that can tighten it up.

Hi, thanks for reaching out and sharing the call IDs

Thanks, yes I thought that Twilio would be part of this delay, but 1.2s difference seemed to me a bit too much and I thought it could be a bug. If you could give some advice, it would be great! I am also interested in Shaunak's investigation, maybe he can uncover an issue somewhere.

Hi, The difference is expected - Twilio/PSTN calls use PCMU audio at 8kHz which requires more conservative VAD endpointing compared to WebRTC's Opus codec used on web calls. Phone calls also go through additional network hops and trigger voicemail detection, neither of which applies to web calls. These factors compound to produce the ~1.2s gap you're seeing.

Yeah that is fair enough, but I actually dont always see it, here is an example call (

019db5ef-2332-7000-b376-e0e284fb159e

) that has pretty similar response times of ~1.3s to what is logged by Vapi, and I dont see the 1.2s gap in such calls. Could this be a bug?