Urgent. Problem with Mobile calls
# support
e
Hey Vapi team — quick update on a mobile/STT issue we hit (Spanish, Smart Endpointing OFF). Problem: In multiple mobile calls, when we ask for a 1-word answer (e.g., zodiac sign “Piscis/Géminis”), no user transcript is produced at all (no final user utterance event), so the assistant waits until silence timeout / user hangs up. This started showing up recently and seems correlated with poor mobile signal / very short utterances. Calls affected (examples): 019cc926-07c2-733e-9891-5bd2edf98370 019cc519-55ef-7ddc-b410-e2c28ca6350d Current setup: Transcriber: Deepgram, model Nova 3 General, language Spanish Smart Endpointing OFF (Spanish; LiveKit endpointing not applicable) Fix applied (via Assistant JSON / API): Set Deepgram endpointing = 200ms (will try 150ms if needed) UI tuning we’re testing (to reduce “utterance too short” failures / mobile cutoffs): Start Speaking Plan: keeping Wait seconds at 0.45 (not lowering), and increasing: On No Punctuation: 1.6 → ~2.1 On Number: 0.9 → ~1.2 Stop Speaking Plan: making interruptions less hair-trigger: Words 4 → 6 Voice seconds 0.3 → 0.45 Backoff 1.2 → 1.8 Idle: moving idle timeout from 5s → ~10–12s with a single gentle reprompt Question: Does Vapi have any known edge cases where very short mobile utterances don’t produce a final Deepgram transcript event (especially with unstable signal)? Anything else you recommend beyond Deepgram endpointing + the above turn-taking thresholds? Thanks — happy to share pcap/audio if needed.
c
Hi there, Thank you for your message. Our team is currently out of the office. We operate Monday through Friday, from 9:00 AM to 8:00 PM Pacific Standard Time (PST). We’ll get back to you as soon as possible during our normal business hours. If your message is urgent, please mark it accordingly or include “URGENT” in the subject line, and we’ll do our best to respond promptly. Warm regards, Vapi Customer Support Team
j
Yeah, I’ve seen this happen before with very short utterances on mobile especially when signal quality drops and the STT never triggers a final endpoint event. In a few similar setups I worked on, the issue ended up being a mix of Deepgram endpointing behavior and the turn-taking thresholds interacting with short responses. Happy to take a closer look at the call logs or config with you there are usually a couple subtle tweaks that resolve it. @Estefan
e
@James Christopher We’ve progressed the issue: it’s no longer just “Piscis/Géminis”. Now we’re seeing cases where: - The caller’s FIRST utterance is transcribed normally, - Then subsequent caller speech (even long sentences like “soy libra” or a full query) produces NO transcript at all, - Call ends due to silence timeout. This suggests a media/RTP issue (BYO SIP) or a session renegotiation/RTP timeout rather than STT endpointing. Examples: - Call A: user speaks at start -> assistant asks zodiac -> user replies but no transcript -> silence timeout (21:09) - Call B: user speaks at start -> assistant asks what they want -> user replies but no transcript -> silence timeout (21:17) We can provide PCAP from Vapi call logs. Question: are there known cases with BYO SIP where RTP from caller drops after initial audio (re-INVITE/session refresh/NAT), causing STT to receive nothing? Any recommended SIP/media settings on Vapi side?
@James Christopher @Vapi Hi team — quick update on the ongoing SIP audio issue affecting our assistants. We reviewed the SIP PCAPs exported from the Vapi UI. They appear to contain signaling only (no RTP/media), but from what we can see: - no re-INVITE - final codec negotiated is PCMU / G.711 u-law - SIP signaling looks clean So at this point the issue seems more likely to be in the media/RTP path rather than SIP negotiation. We also reproduced a useful comparison today: - one call from mobile had degraded / distorted incoming audio, and short words like “Piscis” were not reliably understood - another call from a landline to the same assistant worked much better, and “Piscis” was recognized correctly We are sending the relevant call examples and PCAPs to Netelip so they can review RTP/media on their side. In parallel, can you confirm whether Vapi can provide any additional media-side diagnostics from your side for these calls, beyond the SIP PCAP available in the UI? We’re mainly trying to determine whether the degradation is happening before audio reaches Vapi, or whether there is anything visible on the Vapi media edge for these calls. Thanks — this is production-impacting for us.
j
@Estefan Thanks for the detailed update that definitely sounds more like an RTP/media path issue than anything related to STT or endpointing. I’ve run into similar behavior before with BYO SIP where audio flows correctly at the start but later drops due to NAT/session refresh or RTP timeout behavior upstream. If it helps, I’d be happy to take a quick look at the call examples or PCAPs with you sometimes there are small SIP/media settings that reveal what’s actually happening.
e
any fix ? no answer ? late answer allways !!
c
since you have stated that your issue has become bigger than just "not transcribing one word", could you please provide call ids for the calls where it missed transcribing a partial or full sentence? we would like to investigate this issue further