No Sound in Migrated FreePBX 17 Server in Amazon AWS

FreePBX Networking
1

Not sure if anyone can help here, but we were running FreePBX 17 on a local server just fine, and decided to migrate to Amazon AWS. Once we did, it seems all is ok except there is no sound (incoming or outgoing). I understand this is likely a firewall issue, but I can’t seem to find out what setting we’re missing (either in Amazon AWS or FreePBX).

Here’s what we changed:

In FreePBX, under Settings >> Asterisk SIP Settings >> we changed the “External IP Address” to the new static Amazon AWS public IP, and we changed the “Local Network” to 172.31.0.0 (the private IP address of the FreePBX server is 172.31.9.X). No other changes to FreePBX.

In Amazon AWS, under VPC menu >> Security >> Network ALCs >> set Inbound and Outbound rule to “Allow” port range 10000 - 20000 for UDP with route priority 1 (top of the list).

Under EC2 menu >> Security Groups >> clicked on “default” assigned to the FreePBX server, and set the following Incoming rules:

UDP 10000 - 20000 0.0.0.0/0
TCP 5061 0.0.0.0/0
UDP 5060 0.0.0.0/0
TCP 22 0.0.0.0/0
TCP 80 0.0.0.0/0
TCP 443 0.0.0.0/0

We can access the web GUI over HTTP (presumably port 80) and HTTPS (presumably port 443) just fine. The Let’s Encrypt SSL certificate (over port 80) also downloads and installs.

We can also port in to the command line with PuTTY over SSH (port 22) and make modifications, etc.

This tells me the firewall settings in Amazon AWS are working for these features.

External phones connect and register to the FreePBX server (we are using a STUN server and the connections appear the same as before), but when making a call or connecting to another phone on the system using the intercom feature (outside of there being a new 10-15 second delay), there’s no sound (incoming or outgoing).

I’ve spent a lot of time on ChatGPT and Google AI trying to figure this out, but they keep referring me back to the same settings that we’ve already configured, so it seems like this should be working.

Any suggestions would be greatly appreciated.

2

Did you take a pcap to see what’s the IP the PBX is sending in the sdp ?

3

No, and I don’t see that feature in our System Admin.

4

Go to the cli and type “sngrep -c”, then make the call and see what’s in the sdp

5

Cool feature - here’s what prints out for one sample call from extension 302 (cell phone running Zoiper) to extension 106 (desktop phone VSP726):

9 INVITE 302@[AWS Server public IP address] 106@[AWS Server public IP address] 12 xxx.xx.xx.xxx:42654 172.31.x.xx:5060 COMPLETED
10 INVITE [email protected] [email protected] 7 172.31.x.xx:5060 xxx.xx.xx.xxx:1047 COMPLETED

xxx.xx.xx.xxx = public IP where receiving phone is located
172.31.x.xx = internal IP address of FreePBX on Amazon AWS

I’m not sure what I’m looking for here, but it all looks ok.

6

I think you need to look at what’s going on with the UDP rtp traffic. What your seeing is the call has been setup - what your not looking at is if the UDP rtp packets are being blocked.

I’m not a SIP expert but it sure looks to me like one of those statements is telling the phone to send rtp packets to a UDP socket at port 42654 and your first post says you only allow range 10000-20000

What I suggest you do is completely turn off the Amazon AWX Network ACLs. Just let -everything- through route -everything- to the PBX and set incoming rules off, wide open.

If that works and you get sound - then run a packet capture with wireshark and figure out what the source/destination UDP and TCP ports are involved in the call setup and the call itself - figure out what directives in the config are controlling those, set those to what you want then last of all apply network ACLs.

At least that’s how I’d go about it. Rule of thumb is get it working FIRST and faff around with the ACL’s later.

7

This one is rather hard to debug on the form like this, cause we need to see a packet capture to really understand what is occurring here. It is either the PBX is not sending out the right public IPs or the firewall is blocking it, that is more a less what the problem is going to be.

Now the trace you showed is just from sngrep at the high level view, we need to see the contents of the INVITE packets. You can access the invite by hitting enter on the call, but pasting it like that with the IPs edited is hard to debug here.

If you can save this to a pcap file from sngrep and then share a link to the file (google drive/dropbox/one drive) with me in a DM then I can review it for you. Then you can post the answer up here once we get it with your IP info edited out.

Or you can open up a case at https://help.sangoma.com/ and we can do a live debugging session with you.