Hi team this is a production-impacting issue and I urgently need help. I’ve been trying to resolve this via email, but I’m not receiving responses, and this is becoming critical for live traffic. This is affecting real users and we need assistance as soon as possible. We’re seeing ~25–35% intermittent one-way audio on outbound calls using BYO SIP trunk with Telnyx. I performed a full PCAP comparison between a working call and a failed call. Findings below: Working Call • Vapi public IP: 18.246.41.113 • Telnyx IP: 50.114.149.5 • Duration: 44.8s • Codec negotiation: PCMA → PCMU (successful) • Audio: Bidirectional working Problematic Call • Vapi public IP: 44.243.125.254 • Telnyx IP: 50.114.147.45 • Duration: 35.0s (hung up early) • Codec negotiation: PCMA → PCMU (successful, identical to working call) • Audio: One-way (user audio not received) Key Observations Both calls show: • Identical SIP signaling flow (INVITE → 407 → INVITE → 180 → 183 → 200 → ACK) • Successful codec negotiation (PCMU/PCMA @ 8kHz) • Proper SDP exchange • No SIP errors The only meaningful difference is the Vapi edge server public IP. This strongly suggests a firewall / NAT / RTP routing inconsistency across the edge IP pool. Specifically: • Some Vapi IPs correctly allow inbound UDP/RTP • Others (e.g. 44.243.125.254) appear to block inbound RTP from Telnyx Why This Explains the Symptoms • AI audio sometimes appears in recordings → outbound RTP works • Users sometimes don’t hear AI → inbound RTP likely blocked • ~25–35% failure rate → matches percentage of calls routed via problematic edge IPs This does not appear to be a codec issue. It appears to be an RTP media path issue after SIP handshake completes. This is actively impacting production traffic and requires urgent attention. Thank you.

Thanks for sharing this, your breakdown is very solid, and it really points to an RTP routing issue on specific edge IPs, not a codec or SIP problem. We’ve seen similar cases where certain IPs have asymmetric NAT or firewall behavior that blocks inbound media. The next step is to validate RTP reachability and port handling on the affected IPs (like 44.243.125.254) against Telnyx’s media ranges and routing rules. I can help you walk through testing forced routing, symmetric RTP, and port mappings to isolate this quickly. One quick question: are you currently using symmetric RTP/rport, and have you fully whitelisted Telnyx’s media IP ranges? @EmprendeDuro

@James Christopher Thanks for getting back to me. I've done more investigation since my last message and I think I found the actual root cause. I captured PCAPs from 6 more calls (1 successful, 5 failed) and analyzed them in detail. The problem isn't what we initially thought, it's not about the public edge IPs being different. The issue is deeper in Vapi's infrastructure. Here's what I found: The successful call routes through: - VAPI Server: 172.31.57.86 - Media Proxy: 172.30.42.239 - Public IP: 18.246.41.113 - Result: Perfect bidirectional audio All 5 failed calls route through: - VAPI Server: 172.31.9.106 - Media Proxy: 172.31.61.127 ← this is the problem - Public IP: 34.223.48.167 or 18.246.41.113 - Result: One-way audio failures So it's not about which public IP is facing Telnyx, I've seen failures with both 18.246.41.113 and 34.223.48.167. The actual issue is the internal media proxy at 172.31.61.127. This proxy seems to have NAT/firewall/routing problems that prevent RTP from flowing correctly to/from Telnyx source IPs. Looking at the SDP exchanges: Working call: Frame 1 - Telnyx INVITE: c=IN IP4 172.31.14.233, m=audio 38794 Frame 12 - VAPI 183: c=IN IP4 172.30.42.239, m=audio 45544 Frame 15 - VAPI 200 OK: c=IN IP4 172.30.42.239, m=audio 45544 → RTP flows perfectly Failed call (example): Frame 1 - Telnyx INVITE: c=IN IP4 172.31.7.136, m=audio 34162 Frame 12 - VAPI 183: c=IN IP4 172.31.61.127, m=audio 58094 Frame 17 - VAPI 200 OK: c=IN IP4 172.31.61.127, m=audio 58094 → RTP fails https://cdn.discordapp.com/attachments/1471650028727566494/1473086838615834635/019c6728-5b08-7ff7-ae0a-17914e7f779e-1771257276716-deadb5fc-65e8-490f-ad5c-beda951c6d0f-sip.pcap?ex=6994ee86&is=69939d06&hm=57a32a635a9cda35241d1c816e4ed0b99f94958a3d1bca1b88b6936fddecd892& https://cdn.discordapp.com/attachments/1471650028727566494/1473086838850846845/019c6673-5cd9-7444-b733-598e1876c3a2-1771245410730-5eba6d3c-3265-40e6-aac7-007727eee5ab-sip.pcap?ex=6994ee87&is=69939d07&hm=38a8b18b53ad621119c7ab0fd4b9789d17d0516a0a8f035f22d098c1eab9bd12& https://cdn.discordapp.com/attachments/1471650028727566494/1473086839140388864/019c6737-6af9-744e-b6d5-b05b33de9539-1771258250121-8830081d-aaa7-4bb2-91c0-e3364d439a95-sip.pcap?ex=6994ee87&is=69939d07&hm=8aa6424d745dc9311e0973382b2825852f4d1ea6a67a488f167d3de06e1fc77c& https://cdn.discordapp.com/attachments/1471650028727566494/1473086839425597440/019c6695-8166-7cc3-993c-e51532687e15-1771247627552-ebec2aaa-dfa2-487f-8bea-5a1b6b755433-sip.pcap?ex=6994ee87&is=69939d07&hm=a9816bce3a14703d12ee8215ca58a588f0e47a184524906e27e9ddfd646eb8dc& https://cdn.discordapp.com/attachments/1471650028727566494/1473086839723135118/019c6688-4e22-7887-b0ed-31cce3d36927-1771246777089-3e9b54da-e8f3-4546-a169-06c126fa31c5-sip.pcap?ex=6994ee87&is=69939d07&hm=986cf5110072ef10580c602b5b428e45b83adb2a003cf803fc9cc2e9cf3ddb80& https://cdn.discordapp.com/attachments/1471650028727566494/1473086840004149436/worked-call-sip.pcap?ex=6994ee87&is=69939d07&hm=8388266b9a7b39af1495ae27beee12d94c88ce385f3c94d52802182d44b2a237&

Thanks for digging this deep your analysis is exactly what we look for when isolating infrastructure-level media issues like this. Based on what you’ve found, the right next step is to systematically validate RTP flow on 172.31.61.127 against the healthy proxy, audit NAT/firewall rules, and run controlled routing tests to confirm and eliminate the failing path. I’ve helped teams resolve similar intermittent media failures by tracing each hop and normalizing proxy behavior across regions. If you’d like, we can walk through this together and get it stabilized quickly, feel free to message me privately and I’ll help you set up a focused remediation plan.. @EmprendeDuro