Thank you for your response, @PitzKey.
FYI, I’m running VitalPBX 4.0.3-6 on Debian 11 in our Data Center, which is in Boston, MA. We have a dedicated external IP for the PBX, which is routed to the PBX internally through an enterprise grade firewall. The firewall NAT rules are basically established to say
- If traffic comes from [SkyeTel IPs] and it’s to [External IP], regardless of port number, forward it to [Internal IP of PBX], and
- If traffic comes from [PBX] regardless of the destination IP, route it out on [Dedicated External IP].
- There’s a third rule, but I’ll explain it at the bottom of this reply. It has to do with their RTP traffic.
So, this documentation you referenced is now 4 years old, and a LOT has changed since it was created. I could start documenting every single change, but I think it might be better if VitalPBX reaches out to SkyeTel directly and rebuilds the documentation.
When I reach out to SkyeTel for help, they point to this exact documentation. Then they basically refuse to help further, telling me to reach out to VitalPBX for support. We’re a VitalPBX partner, and so I have no problem putting in a paid support ticket on this, but I suspect everyone is just going to point their fingers back to this documentation… which is out of date.
So, this did not resolve my problem.
I created an entirely new trunk for testing, disabling my other trunks. PJSIP is the only option for trunks in VitalPBX 4 other than IAX (which won’t work with provdiers like SkyeTel), so I didn’t do the port 5062 thing as is shown in the documentation. PJSIP is now on 5060, so that shouldn’t be an issue.
I used only the IPs listed, which correspond to the “Classic” IPs at SkyeTel - they now have a “Regions 2.0” section, which is a block of /27 IPs. So when the “Classic” ones connected but I could see SkyeTel trying to connect using the Regions 2.0 IPs in my firewall logs, I added them - both to the firewall rules and to the PBX Trunk “match” IPs. Also FYI: If I add in all the IPs and IP Blocks they list on their IP addresses page, I “max out” the “match” field and an error appears. They have a lot more IPs that they use than the 8 sets they list at the top. There are also “Emergency” IPs, “High Cost” IPs, “Monitoring” IPs, etc.
The newly created PJSIP Trunk connects and disconnects fairly regularly, so much so that making inbound and outbound calls are hit and miss. According to the SkyeTel IP Health console, it is a rainbow of Red, Orange, and a few Green connections. In the past that has been solid green all the way across.
sngrep shows nothing out of the ordinary. I did see that the internal IP address of the PBX was going out to SkyeTel, which they were rightly rejecting. I fixed this by putting the dedicated external IP address in the “From Domain” field of the Trunk and restarting the PBX. Why the restart? I’ve found with VitalPBX, there are just certain things that magically start working when I restart the PBX. And since the PBX is virtualized, a reboot takes around 2 minutes. We’ve been in a “phones down” state to the outside world for a little over 48 hours now. What’s 2 more minutes if it solves the problem?
Also something to note: SkyeTel does not seem to care what destination ports they use for RTP. So my settings in VitalPBX are set to 10000-30000, but because of their RTP destination ports being all over the place, I’m having to do some NAT port forwards that are like 30000-49999 → 10000:29999 in the firewall. Again, reaching out to SkyeTel for help has been next to worthless. They aren’t changing how they do things on their end.
So, frustrated on all fronts. I have 50+ phone numbers with SkyeTel, so this is pretty much destroying my phone operations.
Again, thank you for your response. But the documentation needs updated pretty badly.