Skyetel is proud to be a certified and preferred provider for 3CX. This makes configuring Skyetel for your 3CX PBX very easy - simply select us from the drop down list and.. boom.. your done!
3CX has provided their own support document for using Skyetel for 3CX. You may view that here:
Things To Know
You Need Good DNS Servers
SRV records are advanced technologies and rely on strong DNS resolvers. Please make sure you specify a well known and reputable public DNS server explicitly on your PBX to insure DNS resolution does not fail. We recommend 126.96.36.199 and 188.8.131.52
3CX Routes on E.164 Format
By default, Skyetel routes all calls to the PBX using 11 digits. We do this in the SIP URI (the first line in the SIP INVITE packet). For example, when you call our number, this is what the SIP URI looks like:
INVITE sip:email@example.com:5060 SIP/2.0
However, in order to organize our traffic, we send all Caller ID information in E.164 format. Therefore, the TO in a Skyetel INVITE looks like this:
This discrepancy confuses 3CX - it would prefer that the To and the URI are identical.
As part of our interconnection, 3CX is configured to route using the TO in E.164 instead of 11 digits. This means you should add phone numbers to 3CX like this: +13609865200
However - in our legacy 3CX guide, we recommended using a wildcard:
In order to accommodate this, we recommend you use a wildcard for your Skyetel numbers. Per 3CX documentation:
3CX will match the number inserted in this field with the “to” header, starting from the last part of the received string, thus avoiding any differences in the format of the number. For example, if you are based in the UK and your DID number is 0845-2304024, then you can enter the number *2304024. This will match any DID number inserted in the “to” field ending with these numbers, including +448452304024, 08452304024, 00448452304024, and, of course, *2304024.
This means that we would recommend that you configure your DIDs in this format: *3609865200
This method is still supported and will work correctly. However, you will not be able to route using 11 digits using the certified interconnection with 3CX.
You only need 1 Skyetel Gateway
Because 3CX natively supports DNS SRV lookups, you do not need all the gateways we listed in our legacy guide. The single Skyetel gateway will route and balance traffic as intended across all of our regions.
Skyetel was certified on version 16 and 15
Skyetel was tested and certified with 3CX using version 15 and 16 and will be certified for all future version. Previous versions are not supported and you will need to use our Legacy 3CX configuration in order to get Skyetel to work on those PBXs.
3CX.skyetel.com Uses Port "0"
This is normal - 3cx.skyetel.com is an SRV DNS record that is purpose built for 3CX (if you are not using 3CX, please use srv.skyetel.com instead). SRV records contain the port and protocol information in the SRV lookup:
flags QR RD RA
_sip._udp.srv.skyetel.com. IN SRV
_sip._udp.srv.skyetel.com. 299 IN SRV 10 10 5060 va1.skyetel.com.
_sip._udp.srv.skyetel.com. 299 IN SRV 10 10 5060 ca1.skyetel.com.
_sip._udp.srv.skyetel.com. 299 IN SRV 10 10 5060 or1.skyetel.com.
Because SRV records contain all of the relevant information about port, priority and source IPs, you can safely trust in 3cx.skyetel.com or srv.skyetel.com
Don't Add anything to the Outbound Proxy
When you are troubleshooting issues, make sure you leave "Outbound Proxy" blank
Keep Your Phone Numbers Unique
The most common issue 3CX has when receiving calls from our network is that Administrators forget to keep their Trunk phone numbers unique per trunk. Duplicate phone numbers across multiple trunks will cause 3CX to reject any attempt for us to send inbound calls.
Main Trunk Number
You can use any number you would like for this, but please make sure that it is unique per trunk.
408 Request Timeout
On occasion, 3CX will fail to place outbound calls and give this error:
SIP Server/Call Manager ID: 12294
Call or Registration to ###########@(Ln.10000@Skyetel) has failed. 0.0.0.0 replied: 408 Request Timeout; internal
This is caused by the TCP protocol timing out when communicating with our routers. This is not a 3CX bug, but it is a bug with some operating system's underlying networking stack. In order to resolve this issue, simply switch from TCP to UDP in the SIP Trunk Options. You can read more about this issue on the 3CX forums here: https://www.3cx.com/community/threads/3cx-dns-srv-resolution-issues.67708/