I would like to know if there is an specific IP range from where RTP packets comes from when a call is established using a BYO SIP Trunk. I need to whitelist this IP addressess that are different than the ones in docs (those are just for SIP traffic, RTP is comming from different ones): 44.229.228.186/32 44.238.177.138/32 I'd appreciate you for any advice.

Hey, we don't have any specific IP range from where we send the RTP packets, but whitelisting the IP addresses mentioned in the docs should solve the issue.

@Sahil Assuming that @LucasEndev is working in a highly regulated enterprise or a fintech company, your answer basically tells him: "I can't use VAPI, because I won't open our firewall access list for the entire internet". The more accurate response would be the following: - If you are using a proper SBC gateway, you can configure your SBC to dynamically open IPs and Ports in accordance to the content of the SDP offer and its origin. Of course, this requires that your SBC and Firewall and able to fully handle these. - If you are using a Firewall only, such as a FortiGate or Palo-Alto Security - consider enabling your SIP ALG, however, bear in mind that you may run into RTP issues, with sessions perform a media RE-INVITE or SIP REFER may not work properly.

First of all, thank you @Sahil to confirm me that I wasn't wrong, there's no documented IP ranges for RTP packets. Then, @Nir S (CEO/Founder @Cloudonix) Hahahahahaha, thank you so so much for the more complete analysis-response provided, it's on the same way that I'm trying to achieve it. And maybe Vapi support could try to give us more responses like this. Regarding directly to your suggestion, yes, having a SBC gateway would make this way simpler but we are not right now in the moment to adquire one, we are just working over GSM so we don't extremely need a SBC if not for this. Then, the second option is where all started, but to achieve establish the call between the participants I needed to disable SIP ALG. So I think that my only option is to research a bit how to configure it with a dedicated media relaying server. Thank you so much both, I'll provide feedback as soon as I got it

Or you may be able to add cloudonix as your "in between"

I would appreciate more info about it, specifically about costs and data property and storage. I could be restricted due to data collection policies.

Please DM me and provide more details. Your case is interesting.

In order to provide more info to @Sahil. As you can see the IP of the incoming RTP is not the VAPI IPs of the docs, and the weird thing is that I'm receiving just the first packets from vapi and then it get cut. If i check the same call in Vapi I can see the full (both ways) traffic of the call. So it's like that I receive the first packets but then no more or directed anywhere else. I already configured port forwarding for a full range of 10000-60000 (due to that incoming RTP from Vapi is between 40k-60k), and i configured local firewall to allow all incoming RTP traffic (0.0.0.0/0). To achieve security with the firewall but not breaking the thing, I'm just filtering SIP packets to be from Vapi IPs. Could some of you provide some feedback about these? https://cdn.discordapp.com/attachments/1373438173409181707/1373711902705717308/image.png?ex=682b6867&is=682a16e7&hm=3ceeca47155fafbe96bcbfb72b3f0cbb90c981db57d90375398302834c47d539&

@LucasEndev What you are describing is called a

SIP Re-INVITE

Yes, I agree with what you are mention, and I'm also concern that the inconvenience could be due to this Re-INVITE. Since the call is established with the SIP endpoint but routed to a GSM device where it make sense the Re-INVITE. I'm certainly missing the packets on this second step of the call. What thinking on the line, it make sense that the Gateway doesn't receive the packets anymore since it should establish with another media peer (GSM device), but still, I cannot hear the audio, and there is not a codec issue.