Not sure what I broke, but suddenly my SkyeTel trunks don’t work. I’ve now changed it so many times that I doubt I have anything close to what it is supposed to look like. Is there someone that would be willing to provide a “redacted” screenshot of what your PJSIP SkyeTel trunk settings look like?
Thanks!
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
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.
Hi @PitzKey,
You are astutely correct! Something DID change. And the frustrating thing is, I have no idea what specific setting it was.
The answer is, we upgraded our firewalls in Boston over the weekend, which are in a High Availability cluster. When we upgraded the secondary one to the new version (doing that one first so we could test), it wiped out some settings on the primary firewall. Settings that were supposed to be in sync all the time. So, somewhere along the way I probably did find a workaround to this problem at the firewall level, but I’ve changed everything back to what I remember, and it still doesn’t work.
The firewalls are a custom version of BSD using the pf daemon running on Dell server hardware. When I started out it was m0n0wall; then (2009?) I went to an entirely custom pf.conf script on a vanilla OpenBSD box; then pfSense (2012-2016); and now OpnSense (2016-Present). Unfortunately you can’t go off OpnSense settings directly – we have a customized product for that, because we’re also OpnSense partners, and there are some things they do that we don’t do. About 95% of the settings are the same, but there’s 5% of settings that are tweaked to prevent certain foreign cameras from allowing bad actors in or out over certain types of packets. But we’ve made certain that all the IPS/IDS functions are disabled until we can figure out the SkyeTel issue, because the last thing I needed was the IDS blocking some of their traffic. I’ve got full pf logging enabled at the moment, so I’m watching for invalid state / state violation udp packets.
Screen captures: I’ll upload them as soon as I’m finished with this response (and I figure out how that works in this forum).
I’m curious what you mean about the last statement regarding SkyeTel and anchoring RTP? I’ve seen all sorts of source ports from SIP trunk providers, but I usually can define what ports we have open for them for RTP and they will respect that and send the RTP traffic on those ports, usually 2 ports per phone call. Skyetel’s destination ports are like putting a blindfold on and firing a shotgun. They have no rhyme reason as to what destination port the RTP traffic is coming in on. This makes it very difficult to configure a firewall to accept and pass that traffic.
I’ve been doing SIP trunking on this firewall platform for 10 years now, and I’ve never had this level of problems with a SIP trunking vendor. 
Thank you for your help!
Couple of things:
In the Trunk:
out.skyetel.com since it uses SRV.In the Skyetel PJSIP profile:
There are more RTP settings that can be tweaked if you have audio issues, but first lets get SIP working.
I suspect that your firewall is dropping the OPTIONS. Are the issues both with incoming and outgoing calls?
I’d like to start with doing a packet monitor within the firewall to try to understand why your firewall is dropping it.
If we cannot overcome that, then you may want to try lowering the expiration time.
SkyeTel does not handle the RTP of your calls. Do you have any audio issues?
OK, changes made. The trunk states that it’s online. I can make calls inbound. I could not make calls outbound from my desk phone (Grandstream 2170), but I rebooted the PBX and then it worked.
Audio issues - believe it or not, no - none! The only issue is whether the call completes or does not complete. Assuming the call completes, we get two-way audio. If it does not complete, we get the SkyeTel “This number is experiencing temporary difficulties” message. From the desktop phone side, we get a fast busy. However…
When making outbound calls from my desk phone, it’s now taking an obnoxiously long amount of time to actually reach SkyeTel and complete the call. Like, in sngrep, it’s now taking 10 rings before I see “INVITE (SDP)” and “100 trying – your call is”. But it does eventually connect.
I’m happy to dump my firewall logs, but I might suggest that I do it to a PM for you to review. I don’t know that I can redact enough for a public forum. 
As an update: At the moment SkyeTel is showing all of Regions 2.0 in the green. The Classic regions are all down except for SouthEast, which shows as being up. This is better than it’s been all week!
Here’s the answer, I believe…
Do all the above as suggested by @PitzKey
Also, look on your firewall and see if you can find a setting like this one, which is in opnSense:
REBOOT YOUR FIREWALL. No, Really. Reboot it. It’s necessary.
Lastly, a question for @PitzKey: Will VitalPBX support/resolve SRV records into IPs in the Match section of the Trunk Setup, by any chance? With all these IP addresses, if there was a way to pool them together into a single SRV record or 5, that could be very helpful.
Reference: Reddit - Dive into anything
That indicates that there may be some network issues.
As mentioned, audio is not going through the SkyeTel network. So there shouldn’t be any issues.
Do you still have the pcap?
Asterisk (PJSIP) will try to do SRV records. However, SkyeTel’s SRV records for the mentioned domain does not resolve to IP addresses, rather to other domains.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.