Thanks for the tips so far. They’ve been helpful in narrowing my focus.
I was able to perform several packet captures which included RTP (had to choose the correct interface).
Result 1 - from cell phone, soft phone; connected over home wifi and public internet to FreePBX
SIP = good, connection made, phone registered
RTP = soft phone sending RTP to 1.1.2.21, which fails entirely
Result 2 - from remote office phone, Grandstream; connected over our private WAN
SIP = good, connection made, phone registered
RTP = Grandstream sending packets to 1.1.2.21, response from phone system at 10.1.1.227, results in one-way audio
Conclusion - I have a messy config.
But, seriously, these packet captures are clearly pointing at RTP issues and NAT or firewall configurations that need adjustments.
ATT SIP Trunk
Our ATT SIP Trunk is through a local gateway installed on-premise with our firewall and freepbx. It’s physically connected to our firewall because the original plan was to use the fiber installed with the SIP Trunk as a fail-over Internet connection.
The physical connections look like this:
ATT device → pfSense firewall → freePBX
The IP addresses look like:
1.1.2.1 → 1.1.2.21 / 10.1.1.254 → 10.1.1.227
That’s where the 1.1.2.21 SIP NAT External IP comes into play.
And, if I change the NAT External IP to one of our real public IP addresses then we cannot make/receive calls from the ATT SIP trunk properly.
Source NAT?
I’ve read about programming source NAT/outgoing NAT on the pfSense firewall. Anyone have experience with this to resolve a situation like this?
ATT direct to FreePBX?
Should I just connect the ATT equipment to our FreePBX server? We have the physical NIC ports available on the FreePBX server. My security brain cringes at directly connecting an external device directly to an internal server. To me, that would introduce a vulnerability. Though, ATT assured me nothing can breach their network and crawl out to their customers like me. (haha)