Hi VAPI team, I'm experiencing one-way audio on outbound PSTN calls using an imported Telnyx number. Telnyx support analyzed my call logs and confirmed: Inbound RTP packets ARE reaching Telnyx (5,449 packets received) The PSTN leg negotiated PCMA but VAPI is hardcoding PCMU in the stream This is a known issue per your community forum Call Control ID: v3:kTmZ62ATlTZDuZnvhyKZExmMQ57LYz1DqWDd022Vs0vlc3cScJEWUw Phone Number ID: 2c295772-68b8-45c4-bb63-448599698f87 Please advise on a fix or workaround. #bug #help #question #integration

Thanks for reaching out about your SIP Trunking setup! You can find step-by-step troubleshooting help here: 👉 [Vapi SIP Trunking Guide](https://docs.vapi.ai/advanced/sip/sip-trunk) If that doesn’t resolve it, please reply with: • Your Call ID • The exact error message or behavior (e.g. 401 Unauthorized, timeout, etc.) • Whether it’s happening on inbound, outbound, or both trunks • Any recent configuration changes Once we have that info, we can help pinpoint the issue faster.

Suggestion: To address the codec mismatch, go to your Telnyx SIP trunk's Inbound Settings in the VAPI dashboard and ensure only G711A (PCMA) is checked and G711U (PCMU) is unchecked. This should force VAPI to negotiate PCMA for calls:

Inbound Settings → Codecs:
[✔] G711A (PCMA)
[ ] G711U (PCMU)

Save your changes and test an outbound call to verify two-way audio. For more details, see the [VAPI Telnyx SIP integration guide](https://docs.vapi.ai/advanced/sip/telnyx). Source: - [VAPI Telnyx SIP integration guide](https://docs.vapi.ai/advanced/sip/telnyx)

This looks like a codec mismatch causing the one-way audio Telnyx is negotiating PCMA while VAPI is forcing PCMU, so the RTP stream isn’t decoded properly on the PSTN leg. You’ll need to align the codecs, either by forcing PCMU on Telnyx or adjusting SIP settings if possible. Since RTP is flowing, it’s a negotiation issue, not transport are you using BYOC and can you control codec priority on your Telnyx side? @RyanG

configure your telnyx number as a BYO SIP trunk instead of the native integration and run some test calls. let us know if you continue to experience this codec issue