We are having a problem with dead air on some of our BYO-SIP-TRUNK calls. The media path (RTP) is being corrupted as it traverses the Vapi-managed gateway (44.229.228.186). This results in an intermittent dead air problem Please see attached detailed explanation and images Thanks for your attention on this urgent matter. @User https://cdn.discordapp.com/attachments/1451837890672857202/1451837890899345408/Sansay_VSXI_is_advertising_the_Public_IP.png?ex=69883a67&is=6986e8e7&hm=3dc5a651b6db99b99c24e8e6c63e912c8f4625e26652d216747643c60ef633d3& https://cdn.discordapp.com/attachments/1451837890672857202/1451837896968638464/Shows_Carrier_Public_IP_is_getting_remapped.png?ex=69883a68&is=6986e8e8&hm=a78e9edeaa5de8ff18832efc886afa43c7a1b72f3a0eec81f99dbaa525fd8178& https://cdn.discordapp.com/attachments/1451837890672857202/1451837897304051722/Vapi_Detailed_Explanation.txt?ex=69883a68&is=6986e8e8&hm=6dfd033e1bc8bf1593985c056dabb337d1c5f68e0d0bd79048f5c6584cfbe7d7&

@Ade I've tried looking at your PCAP images, I'm missing some context of the signalling. can you send the actual pcap files ?

Hi Nir, thanks for looking in on this problem. Pcap file from Vapi attached for you. https://cdn.discordapp.com/attachments/1451837890672857202/1452355974189809754/File_B_019b336c-b549-7bb4-a2cb-f0a5ae0e0257-1766094363251-e897d319-700d-4c29-98cc-6d2928cd12e9-sip_2.pcap?ex=69498367&is=694831e7&hm=cce5d8509af92b60f17bb853447abeb532368e0c73b23c67df176144081bc170&

The switching of the IP addresses in the trace is completely normal. It is basically the "translation" between the outside world and the inside world. The call starts at media IP 172.30.0.43, then passes via the external gateway, which as an SBC does - will change the media address, in our case to, 35.91.190.204 - again, completely normal. When the response comes back, the rewrite is performed the other way around. If you are experiencing dead-air, it may be related to something else along the path.

Thanks, Nir, we understand that NAT translation for outbound legs is standard. However, the issue we are identifying is specifically with the Inbound SDP rewrite on the response from the carrier. In the provided trace, our carrier explicitly sends a public media IP (192.104.111.94) in the 200 OK. Your gateway at 44.229.228.186 is rewriting that public address into a private address (172.30.31.14) before passing it to our internal server. This is not 'normal' translation; it is a Topology Hiding error that misdirects our media server to send RTP to a non-existent internal destination. We have verified that on working calls via other systems, the carrier's public media IP is preserved in the SDP, allowing for a successful path. We request that you please disable the inbound SDP rewrite to ensure our media server can reach the carrier's public IP directly.

It's not "my" gateway. I don't work for VAPI.

Ah, Ok, Nir, I thought you were connected. Thanks for taking the time to look into.

@Ade I'm flagging this for my team, will send an update to your issue here soon! @Nir Simionovich (CEO@Cloudonix) appreciate you chiming in 🙇

@Evadora (Vapi) Hi Vapi Team, We have received the analysis from our carrier regarding another issue - intermittent dead air on transfers also. Their engineers have confirmed that the issue lies on the (Vapi/Jambonz) side of the call path. Engineer Findings: IP Discrepancy: They confirmed that the Signaling IPs and Media IPs are different during the transfer. Merge Delay: They noted that because the media is being moved between different server IPs, it is taking too long to merge the audio, resulting in dead air. Signaling Success: The engineers confirmed that the calls are signaling correctly, but the audio path is breaking during the server handoff. This confirms our analysis showing that the SBC is leaking a private 172.30.x.x IP during the transfer leg instead of maintaining the public IP used in the first leg. The Request: Please enable anchorMedia: true for our account immediately. We need the media to remain anchored on the initial public-facing gateway throughout the entire call to ensure the audio merge is instantaneous and stable. Thank you,

@Ade Your carrier is assuming that VAPI is a telephony platform - but it isn't. To enable Media Anchoring on VAPI would mean that when a session occurs on a specific server, it can't be moved to another - based on functionality or scaling. The idea of "Media Anchoring" is affectively the opposite of working in a cloud environment. To acheive Media Anchoring yourself, you can do one of the following: 1. Maintain your own SBC to anchor your media to a fixed IP, which will allow your carrier to anchor to your SBC - and VAPI to remain dynamic. 2. Use a cloud service like Cloudonix (or similar ones) that will provide a similar functionality, without the need to maintain your own SBC infrastructure.

Hi Ade, Thanks for the detailed context — this is very helpful. One quick thing we want to double-check: have the required Vapi SIP IP addresses been fully whitelisted on your side (and with your carrier/SBC)? If any of the SIP signaling or media IPs are not allowlisted, it can result in intermittent media issues like dead air or failed RTP paths, especially during transfers. You can find the full list of SIP IPs that need to be whitelisted here: https://docs.vapi.ai/advanced/sip/sip-trunk Please let us know once you’ve confirmed this, or if you’d like us to review the allowlist together. Best regards, Kyle Vapi Support

Thanks Kyle, but both IP's have been whitelisted since day one.

Hi Ade, Thanks for the confirmation. We’re currently investigating this issue internally and have identified a couple of areas we’re actively checking with the team. At this point, we’re gathering more details and validating our findings to make sure we fully understand the behavior you’re seeing. We’ll provide a concrete update as soon as we hear back from the team and have next steps to share. Thanks for your patience, and we’ll be in touch shortly. Best regards, Kyle Vapi Support

OK, Kyle - time is of the essence due to reporting this back on the 20th with you.

Hi Ade, Thanks for checking in. We’re continuing to actively investigate this issue with the team, and we understand the urgency on your side. We should have a clearer update and next steps for you within the next day or two. Thanks for your patience — we’ll follow up as soon as we have more to share. Best regards, Kyle Vapi Support

Kyle, I received this 10 days ago and nothing since??

hey ade, sorry for the delay. we are receiving some support requests that are similar and we are escalating this further. thank you for your patience while we work to resolve this

What are your thoughts on time scale?