...

Overview

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. 

Getting Started

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:

Image Removed

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

Best Practises

Firewall Settings

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.

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:

FreePBX: https://wiki.freepbx.org/display/FPG/NAT+Configuration+FreePBX+12

Incredible PBX: https://pbxinaflash.com/community/threads/cant-get-audio-with-skyetel-trunks.23300/

FusionPBX: https://docs.fusionpbx.com/en/latest/additional_information/nat.html#

Stock FreeSwitch: https://freeswitch.org/confluence/display/FREESWITCH/Configuring+FreeSWITCH & https://freeswitch.org/confluence/display/FREESWITCH/local_ip_v4

Specific Scenarios

Dropped Calls

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:

1. Make sure your Firewall has our IP Addresses configured correctly
2. Check to make sure you have Constant NAT enabled and UDP Timeouts are set above 90 seconds. 
3. 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

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:

FreePBX: https://wiki.freepbx.org/display/FPG/NAT+Configuration+FreePBX+12

Incredible PBX: https://pbxinaflash.com/community/threads/cant-get-audio-with-skyetel-trunks.23300/

FusionPBX: https://docs.fusionpbx.com/en/latest/additional_information/nat.html#

Stock FreeSwitch: https://freeswitch.org/confluence/display/FREESWITCH/Configuring+FreeSWITCH & https://freeswitch.org/confluence/display/FREESWITCH/local_ip_v4

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.

SIP Endpoints "Unreachable"

Image Removed

The Skyetel Network is currently only using Skyetel NW, SE and SW for routing. EU and NE are reserved for future growth and failover. If you see that your PBX is showing that our Europe and North East regions are unreachable, you may safely ignore this message. 

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: 

1. 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. 
2. 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/
3. 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. 

FusionPBX

...

Fusion PBX

1. Enable the Jitter Buffer: https://community.freepbx.org/t/jitter-buffer-significantly-improved-call-response/33647
2. 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 .

...