Hi, I'm experiencing audio issues on outbound calls using VAPI + Telnyx (Spain). All details, settings, Agent ID, and Call Log ID are in the attached document. Could you please review and advise? Thanks you https://cdn.discordapp.com/attachments/1484839641323540611/1484839642191757362/message_support_vapi.md?ex=69bfb02d&is=69be5ead&hm=b0a5c5c7ef78a75b9f82025e15ee28c4e59a578b39e3c6b96f65713f63e3a739&

Thanks for sharing all this — super helpful. This really looks like an inbound audio issue (Telnyx → VAPI), probably around codec or network quality. Could you try forcing G711A only and see if it still happens? Also, do you see any packet loss/jitter on that call in Telnyx, and do the drops match RTP timeout or SIP BYE events? @eytanlevy

Hi, thanks a lot for your help — your suggestion pointed me in the right direction. I couldn't access the Media Stats section in our Telnyx account, but I found the root cause by looking at the call end reason on the VAPI side. What I found: - Telnyx shows Q.850 cause code 16 (Normal Call Clearing) so it's not a network crash, VAPI is intentionally hanging up - VAPI end reason: Silence Timeout (6 seconds) VAPI doesn't detect any intelligible speech, assumes the user is silent, and ends the call So the chain is: audio noise → transcriber can't understand the user → VAPI thinks there's silence → silence timeout fires → call ends cleanly (hence Q.850/16) Next step: Following your advice, I'm going to force G711A only (removing G711U and G729) and test again. Do you think this should fix it? And is there anything else you'd check on the VAPI side given this new information? Are you part of VAPI support team ? @Ramsey

That Silence Timeout (6s) is the smoking gun. It confirms the background noise or codec distortion is so bad that VAPI’s ASR (Speech-to-Text) is filtering out the user entirely and just hanging up to save on costs. Forcing G711A (PCMA) is the right move for Spain, as it should stop the transcoding issues that often cause that 'static' sound. @eytanlevy

You’re definitely on the right track here , this isn’t a network problem, it’s how the inbound audio is being interpreted. Forcing G711A only should help a lot since it removes transcoding issues, especially on Spain routes where A-law is standard. Even though your MOS is high, that small packet loss plus codec switching can slightly distort audio, and that’s enough for the ASR to treat speech as silence. That’s why VAPI is triggering the silence timeout even though the user is actually talking. On the VAPI side, I’d try increasing the silence timeout to around 10–15 seconds and, if possible, tweak the transcriber or input sensitivity so it’s less strict with noisy PSTN audio. The goal is to make it more tolerant, not just “cleaner.” I’m not part of VAPI support, but I’ve handled similar voice setups, if you want, we can take this further privately and I can help you debug it properly end-to-end. @eytanlevy

Thanks for your answers. So The CODECS on Telnyx is on G711A - but the audio noise is still here on the VAPI call log recording therefore the Call stop due to Silence detected.

Good , this narrows it down clearly. Codec is no longer the issue, the problem now is jitter + VAPI speech detection being too strict. That ~93ms jitter spike is high enough to “smear” parts of speech, so even if audio sounds okay to humans, the ASR loses chunks and VAPI treats it as silence. Here’s exactly what I’d do next: On Telnyx: set jitter buffer to ~100–120ms (fixed if possible, not adaptive) Keep G711A only (don’t reintroduce others) Disable extra noise suppression if still on (can distort PSTN audio) On VAPI: Increase silence timeout to 12–15s If available, switch to a more tolerant STT / lower endpointing sensitivity If after this it still happens, then it’s not network anymore, it’s how VAPI is handling RTP/ASR. @eytanlevy

hey, ok I did all your changes, just for Disable extra noise suppression if still on (can distort PSTN audio) do you mean : Noise supression "Both Inbound and Outbound" ?

Yes set Noise Suppression to Both OFF (inbound + outbound). It can clip speech on G711A, causing ASR to read it as silence. Test after you should see fewer silence timeouts. @eytanlevy

so the noise when back and the VAPI agent cant really understand what the caller said.

That jitter (92ms) is actually the bigger problem here not packet loss. Even with low loss, spikes like that will mess up audio timing enough for ASR to miss speech completely, which explains the silence timeout. I’d look at stabilizing the connection first (wired > WiFi, closer region routing, or Telnyx edge settings) alongside forcing G711A. I’m not official support, but you can try this it’s usually where I’d start with similar issues or preferably we resolve this together 😊

How do you stabilise the network ? The number is Spainish. *

Since it’s a Spanish number, the issue usually isn’t the number itself but how the media is being routed. That jitter typically comes from unstable routing between Telnyx and the media server handling the call.

Ok, and on the vapi side the ai chatbot told me to try Opus + G711A. I will try your solution also

Alright bruhh , update me about the progress

@Mary , ok My changes did not change anything - So I looked on what you have said about : What’s I can suggest is that you should make sure calls are hitting a EU/Spain-closest media region (not US), Check if Telnyx is auto-routing via a distant POP, Avoid WiFi on the client side if involved (use wired where possible), - What i found is that on VAPI my Assistant AI is in OREGON (US) so : Every second of audio travels this path: Spain → Oregon (USA) → Spain That's ~10,000 km round trip for every single audio packet, dozens of times per second. This is why the Telnyx network stats look perfect but the audio still crackles — the problem isn't the network quality, it's the distance the audio has to travel. ---> so I ask VAPI to change this to EU - I am waiting for the SUPPORT

Alright 👍

@Mary do you think you can help me and guide me to solve my issue?