This section is intended to help users troubleshoot issues with their PBX on the Skyetel Network. Every PBX is different, so this list of suggestions is not conclusive - but it should serve as a great guide for users who want to take a stab at technical problems before putting in a support ticket.
At this time, Skyetel does not support SIP Registration or Dynamic Public IP Addresses. You will need a static public IP address for your PBX to work with Skyetel.
If you do not have a static public IP address, you can use this tool to update our network every time your IP changes: https://bitbucket.org/skyetel/ip-endpoint-group-update
Before your PBX can place or receive calls on our network, you will need to add It's public IP in our portal. You can learn more about that here: Endpoint Groups. Once you have added the PBX's external IP to our Portal, you can check to make sure we can communicate with it by navigating to https://login.skyetel.com/#endpoints/health and checking to make sure our regions show three green dots. You can read about that here: Endpoint Health. It should look like this:
Once you have added your IP to our portal, you will immediately be able to place calls (provided you have configured your PBX for it). If the dots are red, please make sure you consult our PBX Configurations to make sure your PBX is configured correctly: PBX Configurations
Our network relies on multiple IP Addresses for SIP - so make sure that you whitelist all of our IP Addresses on your firewall. Our list is here: Skyetel IP Addresses. Additionally, the Skyetel Network does not sit in the audio path of the calls. Please make sure you open your PBX's audio ports to everywhere. For example, if you are using an Asterisk Based PBX, please make sure UDP Ports 10000-20000 are open everywhere.
We strongly recommend using a dedicated IP Address instead of attempting to NAT forward to the PBX. If possible, please make sure you use 1:1 NAT instead of port forwarding. Many firewalls do not like negotiating NAT ports when Port Forwarding is enabled. If you are using a SonicWall, please make sure you have Constant NAT enabled and UDP Timeouts set to above 90 seconds.
TCP VS UDP
By default, the Skyetel Network communicates using UDP. This is the preferred method by many PBXs, and it is what we recommend. However, as VoIP has evolved over the last 10 years, the packet sizes supported by UDP have become insufficient. Many networks on the PSTN will provide too much information for a single UDP packet, and when this happens, it becomes fragmented. This usually is resolved by your ISP - they will stitch the broken SIP packet back together again and provide it back to the PBX as if nothing happened. However, there are cases where the ISP does not do this.
In these infrequent cases, the easiest solution is to switch TCP from within our Portal. You can read about this in great detail here: http://www.evaristesys.com/blog/sip-udp-fragmentation-and-kamailio-the-sip-header-diet/
TL:DR - If you are unable to send/receive calls on our network, but the Endpoint is green, please try switching to TCP.
Asterisk requires you to specify the protocol inside each trunk when you are using TCP. If you decide to switch to TCP, please make sure you add tcpenable=yes to your Asterisk trunks
Set your Public IP Address
One of the unique elements about the Skyetel Network is that we do very little NAT correction. Our philosophy here is that instead of attempting to fix NAT issues with our routers, it is better to have the PBX correctly configured. This results in fewer technical issues and a much more reliable connection. This works out great for everyone - but it does require you to configure the PBX to use its Public IP Address in its configurations if it sitting behind a firewall. Each PBX does this differently, but here's a few links where you can read about setting the Public IP address for a few systems:
Dropped Calls are almost always caused by the Firewall. Most modern PBXs are amazing with NAT issues, and generally can successfully handle almost all NAT issues without you realizing there was a problem. Here's a few things to check:
- Make sure your Firewall has our IP Addresses configured correctly
- Check to make sure you have Constant NAT enabled and UDP Timeouts are set above 90 seconds.
- Please try and configure your PBX with 1:1 NAT or put the PBX on the public Internet
You can read a very comprehensive list of resolutions here: https://www.voipmechanic.com/droppedcalls.htm
No Audio are always related to NAT issues. (You can learn more about NAT here: https://whatismyipaddress.com/nat) In general, this means that your PBX is either attempting to communicate using its Internal IP Address, or the Firewall is blocking the audio from reaching the PBX. Please make sure that your PBX is using 1:1 NAT or your firewall is configured to allow all audio from everywhere on the Public Internet.
Additionally, please check to make sure your PBX has its Public IP Address specified in its configurations. You can learn how to do that here:
Can't Receive Inbound Calls
If your PBX is showing up as green in the Endpoint Health section, this is probably being caused by the SIP UDP Fragmentation. Please try switching to TCP.
Call Quality Issues
The Skyetel Network does not sit in the Audio Path of your phone calls. You can read about how we do that here: Our Network Topology. Because of this, it is not possible for our network to create call quality issues for your PBX.
If you are having Call Quality Issues, please check the QOS settings of the endpoint from within the Skyetel Portal. You can read about that here: Endpoint QOS. You can also reference the following:
- Verify from your users that the numbers they are calling are not cell phones. Most cell phones are using VoLTE - this makes call quality issues that are the cell phone's fault sound like they are the VoIP Providers fault. So they confuse the source of the issue.
- We would also suggest setting up a PRTG server in a data center and ping your user's public IP and measure packet loss, jitter, etc. It's not perfect, but it's a really useful way to track down issues that are your customer's responsibility. You can also use this service: https://www.voipspear.com/
- Verify that the user's routers are not overloaded or have high CPUs. In both cases the PING times will look normal, but the audio will suck because the router is congested.
- Check the MOS score of calls within its CDRs. Those are usually pretty representative of call quality issues and are a good place to start. Check to see if your users's complaints correspond with calls with low MOS scores. If they do, then you can pinpoint it pretty quickly to a local ISP issue.
- Verify that FusionPBX is not transcoding the audio or down/upsampling it. If a phone is configured to use G722 but Fusion is only allowing G711, instead of negotiating the phone to use G711, it will simply transcode it. This is a big problem when you virtualize PBXs since the CPU that you are using may be congested from other VMs. If you can, enable delayed negotiation in FusionPBX. Read more here:
(This setting is in SIP Profiles -> Internal and SIP Profiles -> External inside of Fusion's GUI)
- Enable the Jitter Buffer: https://community.freepbx.org/t/jitter-buffer-significantly-improved-call-response/33647
- Verify that FreePBX is not transcoding audio. You can do this by disabling all audio codecs except G711 here: https://wiki.freepbx.org/display/FPG/Asterisk+SIP+Settings+User+Guide
Multiple 0 Second Inbound Calls
On occasion, you may see multiple inbound 0 duration calls when your endpoint is experiencing technical difficulties. This is expected behavior.
When the Skyetel network fails to deliver a call to your PBX from one of its regions, it tries again from a different region. This process will rotate through all of our live regions, and may occur several times. These attempts will show up in our Call Detail Records as 0 Duration calls. There is nothing to be worried about when this happens - it is just us trying really really hard to get the call to your PBX .