https://vapi.ai/ logo
Join Discord
Powered by
URGENT: First message renders as silence (0 TTS ch...
# support
b
Assistant: 87be6d69-c9e9-4244-a89b-c06ab2ae8a9e Call: 019eae97-96a7-7000-a023-7c36dc144b58 On this inbound call, the first message (greeting) was logged as played — secondsFromStart 1.283, duration 8378ms — but the end-of-call cost breakdown shows ttsCharacters: 41, which is exactly the length of the second assistant line ("Hi there, what can I help you with today?"). The ~178-character greeting produced zero TTS audio. The caller heard silence, said "Hello? Hello?", and the recording contains no assistant audio for the greeting. The error field is null — no error was thrown. Voice is ElevenLabs eleven_turbo_v2_5. This is intermittent — other calls render the greeting fine. Questions: (1) Why would the first message log 8.4s "played" with 0 TTS characters and no error? (2) Does voice.fallbackPlan catch this silent-render case, or only hard provider errors? We want to make sure the greeting can never play as silence again.
@Vapi @Vapi Incident
c
b
Thanks for confirming the greeting is in the recording. The caller still said "Hello? Hello?" as if they heard silence, then hung up. Since the recording is the server-side mix, can you confirm whether the greeting audio was actually delivered down the caller's phone leg, or whether there's any sign of one-way audio / RTP delivery failure on the customer leg for this call?
Update with stronger evidence: this is one-way audio, not a TTS issue. On affected calls, Vapi's own recording shows Alex's full greeting present (teal waveform, full transcript, TTS billed), but the caller-leg audio is silent/truncated and the call ends on silence with the caller never responding. The caller is not receiving Alex's audio. Examples: call 019ea822-78c… (+1 310 897 1111), 019ea862-12c… (+1 714 313 8438), 019ea822-9e2… (+1 949 504 9932), all 06/08. PCAPs available. Please investigate one-way audio / RTP delivery to the customer leg on these calls.
c
can you share the full call ids please these ones are truncated
b
Here are the full call IDs: 019ea822-78cb-7002-965f-2e34de7e8f79 — +1 310 897 1111 019ea862-12c0-7001-a91f-5217b15d8f83 — +1 714 313 8438 019ea822-9e28-7002-9665-f4322d41e14b — +1 949 504 9932 All 06/08. Original reference call: 019eae97-96a7-7000-a023-7c36dc144b58 (+1 714 325 7415, 06/09). These inbound calls reach the Vapi number via call forwarding from the client's published business number. On your side, the recording shows Alex's full greeting (audio generated, transcript present, TTS billed) — but the caller hears silence and the call ends on silence with the caller never responding. One more data point on the failure mode: it is intermittent on the same path. On a separate inbound number, the caller's first call came through silent and a redial about a minute later, over the same routing, connected with full two-way audio. So a path that drops the audio on one call can work moments later — pointing to a transient RTP/transport drop rather than a static misconfiguration. The key question: for these calls, can you confirm from the PCAP/RTP whether Vapi actually transmitted the assistant audio out to the caller leg? Did the audio successfully leave Vapi (pointing the drop downstream, in the forwarding/routing), or is there a sign Vapi did not deliver the RTP to the customer leg? That tells us whether this is inside Vapi's transport or upstream of it.
This looks like the same class of issue as the thread titled "One-way audio on inbound phone calls," where your team flagged it as a media stream configuration / codec / inbound-audio-pass-through problem at the carrier-to-Vapi interconnect. One key difference in direction, so you check the right leg: in that case the caller could hear the assistant but the caller's audio never reached Vapi (ingress). In ours it is the opposite leg — the assistant's audio is generated and recorded on your side, but it is not reaching the caller (egress). The caller hears silence, never responds, and the call ends on the silence timeout. So specifically, on these call IDs: can you confirm whether Vapi emitted the assistant's outbound RTP toward the caller leg, and whether there is any media-stream or codec mismatch on that egress path? If the packets show Vapi sending the audio out, that points the drop downstream of you. If not, it is on the Vapi side. Happy to pull PCAPs for any of these.
c
can you please share the pcap
b
Here's the PCAP, attached. Call: 019eae97-96a7-7000-a023-7c36dc144b58 — +1 714 325 7415, 06/09, ~28s This is the strongest verified example: real caller, they spoke (LLM ran), confirmed the full greeting is in the server-side recording, yet the caller heard silence and hung up. One correction so this thread stays clean: please disregard the three 06/08 IDs I listed earlier (019ea822-78cb, 019ea862-12c0, 019ea822-9e28). On deeper review those were silent inbound calls with no caller engagement. 0 LLM tokens, no caller speech, likely robocalls, not this issue. The 06/09 call above is the verified case. The question for this PCAP: did the assistant's outbound RTP leave Vapi toward the caller leg? Packets left Vapi → drop is downstream in carrier/forwarding, and I'll chase it there. No or partial egress → it's on Vapi's side. I also have four same-number redial pairs (silent call → caller redials within 1–3 min over identical routing → fully two-way) https://cdn.discordapp.com/attachments/1514059902731948122/1514664196762243134/019eae97-96a7-7000-a023-7c36dc144b58-1781045659008-a3d23e35-19de-49e4-99ef-38a711bc20a0-sip.pcap?ex=6a2c3075&is=6a2adef5&hm=87539e59ec84a236e4811ffad1669188a6faecbfe0939efae54da2a97e737a66&
PreviousNext
Powered by