Call IDs (all affected): 019d2f85-0fd3-7000-8e19-273752dda39b 019d2f8c-e8c4-755c-aad2-b25b2fd55d59 019d2f8e-df99-777d-b539-7c16530be983 019d2f91-6bd3-7772-b786-e9a69480c10a 019d2f93-c97b-7442-acdb-090d510a5f84 019d2f97-2a9f-7eee-b813-33f42925a33c 019d2f98-d3b1-7000-816c-09c321185956 Timestamp: All calls occurred on 2026-03-27 between 13:39–14:00 UTC. Issue present from the start of every call (00:00). Expected: Full two-way audio — the customer and assistant should hear each other throughout the call. Actually received: One-way audio on every Telnyx call. The first 3 calls explicitly returned the error call.in-progress.error-assistant-did-not-receive-customer-audio. The remaining 4 ended with silence-timed-out or customer-ended-call due to no audio being received. Additional context: Assistant ID: 1dc8d525-2f74-430d-9c4e-4eb9f9f29742 Provider: Telnyx (native VAPI integration) We also attempted a Telnyx BYO SIP trunk as a workaround — credential-type connections failed because VAPI does not send a SIP REGISTER, and IP allowlist-type connections failed because VAPI does not publish fixed SBC IPs to whitelist.

Suggestion: Double-check your Telnyx SIP trunk configuration to ensure you are using IP addresses (not FQDNs) for gateways and that the required codecs (OPUS, G729, G711A, G711U) are enabled. Here’s an example of the correct gateway setup in your Vapi API call:

json
"gateways": [
  { "ip": "192.76.120.10", "inboundEnabled": true },
  { "ip": "64.16.250.10", "inboundEnabled": true }
]

Make sure your firewall allows RTP/UDP traffic from these IPs, and that media encryption is disabled if not supported on both ends. For more details, see the [Telnyx SIP integration guide](https://docs.vapi.ai/advanced/sip/telnyx). Source: - [Telnyx SIP integration](https://docs.vapi.ai/advanced/sip/telnyx)

This looks like a one-way audio issue Telnyx is sending audio but it’s not getting back to Vapi. Since it’s happening from the start, I’d check firewall/NAT and make sure RTP ports and public IP routing are set up right. The SIP attempt failing also points more to a media path issue than auth. Are you running this behind any firewall or cloud setup that could be blocking inbound RTP? @gaurnaik

Hey Matt, thanks for looking into this. No, we're not running behind any custom firewall or NAT setup. VAPI is being used directly via API (cloud-hosted on your end), and Telnyx was configured as the native provider within the VAPI dashboard — no self-hosted infrastructure on our side. We switched to Twilio and it worked immediately with zero config changes on our end, which made us think the issue was specific to how VAPI routes RTP with Telnyx rather than anything on our network.

Got it, that’s a strong signal. Since Twilio worked with zero changes, it points to a Telnyx-specific RTP/media handling issue on Vapi, not your setup. I’ll review the call logs against the media path and compare with Twilio to pinpoint the break. Quick check were you using standard G711U/A on Telnyx with no transcoding enabled? @gaurnaik

We were using Telnyx as the native provider directly within the VAPI dashboard — we didn't configure any SIP trunk or codec settings manually. So whatever codec/transcoding defaults VAPI uses for the native Telnyx integration is what was in effect. We didn't touch G711U/A or transcoding settings at any point.

Hey, thanks for the follow-up I get the urgency. Based on everything you’ve shared, this really looks like a Telnyx ↔ Vapi media handling issue (RTP not flowing back), especially since Twilio worked instantly with no changes. Since you’re using the native integration, codec/transcoding is managed internally, so there’s not much you can tweak on your side. I’ll be honest, this is likely something on Vapi’s side rather than your setup. As a workaround, sticking with Twilio for now is the safest move to hit your deadline. For the SBC IPs, Vapi doesn’t publicly provide fixed IP ranges (they can be dynamic), which is why allowlisting didn’t work in your SIP test. Best approach now: send those call IDs + timestamps to Vapi support and ask them to check RTP routing on Telnyx for your assistant. If you want, I can help you structure that escalation or review their response when they get back. @gaurnaik

yes please, that would be great

Hey gaurnaik, Thank you for sharing call id. After investigation we do see your telnyx phone number's transport configuration is set to

pstn

instead of

rtp

and it matters because when the transport is

pstn

, vapi tells telnyx to stream audio in standard telephony mode. but for the assistant to receive bidirectional audio over the websocket, the transport needs to be

rtp

when you switched to twilio with zero config changes, it worked because twilio handles websocket streaming differently it always sends both directions regardless of transport mode. To Fix it: 1. Update the phone number transport via api, make a PATCH request to update your telnyx phone number's transport to

sip

curl -X PATCH https://api.vapi.ai/phone-number/ec1ef66c-b5a3-45a6-afaf-045c6d886f87 \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "fallbackDestination": null,
    "name": "your-phone-number-name"
  }'

then verify in the vapi dashboard that the phone number shows the correct transport. the key thing is making sure the transport is not stuck on

pstn

if the api doesn't expose a direct transport field, you may need to delete and re-create the phone number with the correct configuration, then re-add it through the vapi dashboard, making sure to select rtp/sip transport when configuring it. 1. delete and re-create the phone number in vapi dashboard 2. or keep using twilio Thank you