Hi Vapi team, We’re facing a recurring RTP media issue in a SIP integration with Vapi (AI call center project with GO Telecom + Bevatel). What’s happening SIP signaling completes successfully: INVITE → 200 OK → ACK Call is answered normally RTP media is sourced from unexpected IPs, causing media loss and call drops Technical details PBX (Bevatel): 10.10.11.181 Vapi SIP endpoint: 44.238.177.138 SDP advertises media: c=IN IP4 185.139.121.21 m=audio 13394 Actual RTP source IPs observed: e.g. 34.223.48.167 These RTP IPs: Are not documented Are not allowlisted on the firewall/SBC Do not match SDP c= address Impact One-way audio / no audio RTP inactivity timeout PBX sends BYE and drops the call despite valid SIP setup Need clarification from Vapi Could you please confirm: The full list of IPs that may source RTP media Whether Vapi uses: Media relays Dynamic RTP IPs Load-balanced / cloud media servers Whether RTP source IP is expected to differ from: SIP signaling IP SDP connection address Goal We need to properly allowlist all RTP IPs to prevent call drops and ensure production stability. SIP ladder + RTP traces available if needed. This is impacting live calls, so any guidance would be appreciated 🙏 Thanks!

I see the issue, calls can drop when RTP comes from unexpected IPs even if SIP signaling succeeds. Vapi often uses dynamic/load-balanced media servers or relays, which can differ from SDP or signaling IPs. I can help identify all potential RTP sources, validate firewall allowlisting, and suggest configuration adjustments to prevent one-way audio or BYE triggers. Could you share the SIP ladder and RTP traces so we can pinpoint the exact flow and ensure stable production calls? @yoru

Thanks for the clarification, that makes sense. Given that Vapi may use dynamic or load-balanced media servers, could you please confirm: Whether RTP source IPs are expected to differ from the SIP signaling IP and the SDP c= address Whether there is an official list or IP range for RTP media that should be allowlisted Or if there is a recommended SBC / firewall configuration to handle this behavior safely in production Our current SBC expects RTP to originate from documented IPs, so having official guidance from Vapi will help us align the configuration and avoid call drops. We can share SIP ladder diagrams and RTP traces if that would help with validation. Thanks, looking forward to your guidance.

Hi Yoru, The IPs you're seeing (like 34.223.48.167) are expected. Vapi's SIP signaling and RTP media run on separate infrastructure. SIP signaling uses two static IPs: • 44.229.228.186/32 • 44.238.177.138/32 RTP media uses dynamically assigned AWS media servers, so there's no fixed IP list. The RTP source will differ from both the signaling IP and the SDP c= address. We recently updated our docs to clarify this, since the previous wording implied the signaling IPs covered media too. For your SBC/firewall, the most reliable fix is to enable symmetric RTP (or "RTP latching") on your Bevatel PBX. This tells the SBC to accept media from whatever IP sends the first packet, regardless of what's in the SDP. Most production SIP setups with cloud providers work this way. If your SBC requires explicit IP allowlisting, you can allowlist the AWS us-west-2 CIDR ranges from https://ip-ranges.amazonaws.com/ip-ranges.json (filter for region "us-west-2", service "EC2"). These can change over time though, so latching is the better long-term solution. RTP port range on our side is UDP 40000-60000. Next step: check if your SBC supports symmetric RTP/latching and enable it. That should stop the call drops without needing to maintain an IP allowlist.