Hello Vapi team, We’re currently using Vapi for our AI voice agent that handles inbound and outbound phone calls. Our telephony provider has detected an issue with the RTP path: the audio stream is being sent from a different IP address than the SIP signaling/registration IP. Here’s what we found: SIP signaling (REGISTER / INVITE) comes from 44.229.228.186 RTP (audio media) is being sent from 35.89.67.171 As a result, our provider’s NAT/firewall doesn’t close the audio correctly — the call is established, but the audio path breaks because it’s coming from an unexpected IP. The provider explained that the connection should ideally be closed using the same IP where the SIP registration originated, or we should explicitly allow the RTP IP range used by the Vapi system. Could you please clarify: What are the official IP addresses or ranges used by Vapi for SIP signaling and RTP media? Is there a way to force the RTP to be anchored or relayed through the same IP as the SIP signaling (e.g. via a media relay or configuration flag)? If that’s not possible, can you provide the list of RTP/media servers we should whitelist on our provider’s firewall? Our goal is simply to make sure the audio stays consistent and passes through the correct IPs. Thanks a lot for your help! For reference, the telephony technician confirmed that RTP packets are currently coming from 35.89.67.171 while SIP registration occurs at 44.229.228.186. The NAT is not closing because the audio and signaling are on separate IPs. Call ID: 019a1677-7eb8-7227-a7cb-e5ba774acf0b Telephone ID: ca252ede-3d52-4900-aa2a-cb2938e0e72a

To ensure proper SIP signaling and RTP media flow with Vapi, you should allowlist the following official IP addresses on your provider's firewall:

44.229.228.186/32
44.238.177.138/32

These IPs are used exclusively for SIP traffic (signaling and media). There is no documented way to force RTP to use the same IP as SIP signaling; please ensure both IPs are whitelisted for reliable operation. Source: [Vapi SIP Trunking Guide](https://docs.vapi.ai/advanced/sip/sip-trunk)

"Could you please run these two telnet tests from your side and let me know the results? I'm getting the exact same behavior." telnet 44.238.177.138 5060 (Should CONNECT ✅) telnet 44.229.228.186 5060 (Should FAIL or TIMEOUT ❌) "I need to confirm if the second IP is unreachable for you too, which would indicate a routing issue outside of my local network."

That might be cause the BYO SIP. @User

@Teru I'm not a VAPI employee - but I will explain what's going on here. SIP as a signalling protocol doesn't "force" the fact that signalling and media should be tied to the same IP number, in fact, in most cases (around 95% of cases) it is not. VAPI uses a load balancing scheme which "bounces" the singalling and media between server, causing signalling to start on one server - then move to a completely "random" server. I say "random" because it's a part of their cluster and infrastructure, but it may go up and down as they scale their network. If your telephony provider can't handle this kind of signalling - you will need to install an SBC or use an SBC type service like Cloudonix.com - in order to "pin down" your signalling and media to a single access IP numbers. You may DM me for more detailed information on the above.

Thank you, @User — that makes perfect sense. I understand now that the issue. I’ll bring this forward to our telephony provider to check if they can handle this type of SIP routing or if we’ll need an SBC solution.