This document will provide an overview of the most common concepts which need to be kept in mind when configuring 3CX Phone System inside your network infrastructure, including the following topics:
- NAT Configuration.
- STUN Resolution.
- DNS Resolution in a VoIP environment.
- Custom Configuration for particular network layouts.
- Different types of VoIP Provider Accounts.
- Custom Source Identification for VoIP Provider SIP message exchange.
NAT Configuration
The first thing on the VoIP provider configuration check list is the Port forwarding (also known as port publishing) on your NAT device.
If your PBX is operating in a network connected to the internet through a single router, your PBX is behind NAT. The NAT device has to be instructed to forward the right inbound packets (from internet) to the PBX server. The UDP port ranges that need to be forwarded are related to SIP (call signaling) and RTP (Voice data). If you are running the PBX on the standard SIP port 5060 then all packets to UDP port 5060 need to be forwarded to the PBX. For the second port range (audio) you must forward ports 9000-9255 UDP to the PBX. This only applies if you are using the standard range. You can find out the exact port range that your PBX uses in the 3CX Phone System Management Console under “Settings” > “Network”. On the other hand the PBX in reverse must also be allowed to send out SIP traffic (source and destination port 5060), RTP traffic (in this case traffic with source ports 9000-9255 UDP) and STUN requests (destination port 3478). It is highly recommended that you test with an open access, i.e. allow ALL outgoing traffic from the PBX.
STUN resolution
In order to work properly the PBX needs to know its public (internet) IP address and what kind of NAT it is behind. It needs this information so it knows how it is seen from the VoIP providers point of view. This is achieved via STUN resolution. Successful log entries will reflect proper STUN resolution and will appear in the server status page on PBX at startup. These entries will look like the following:
14:40:27.703 StunClient::process [CM506002]: Resolved SIP external IP:port (64.233.167.99:5060) on Transport 192.168.0.1:5060
14:40:27.265 StunClient::onInitTests [CM506001]: STUN request to resolve SIP external IP:port mapping is sent to STUN server 64.69.76.23:3478 over Transport 192.168.0.1:5060
If there is no answer from the STUN server the PBX will log a failure, the message will look as follows:
11:14:38.687 StunClient::onTestTout [CM506004]: STUN request to STUN server 64.69.76.23 has timed out; used Transport: 10.172.0.132:5060
Note: There are cases that STUN resolution is not required. For example, when a server has a public IP and no firewall in front of it. To tun off STUN resolution, from the 3CX Management Console, navigate to “Settings” > “Network” > “STUN server” tab. Check the “Turn off STUN requests” check box, enter the “Static Public IP” of the server and “Select Network card Interface”. For additional information regarding working without STUN resolution read our “How and when can I switch off STUN Resolution?” article.
From the successful logs one can notice that the “Resolved SIP external IP:port” contains a correct public IP. This can be cross checked on the NAT device. Every NAT device will have a status monitor where its IP can be reviewed. If the port forwarding rules have been set correctly then (depending on the type of NAT implemented) no PAT (Port Address Translation) will occur. This means that the source port will not change when the PBX contacts the STUN server, the reported source port by the STUN server will remain 5060 – unchanged. If the NAT device does not have the SIP port 5060 forwarding rules set, it would be very likely that the NAT device would change the source port – along with the source IP – when the request traverses the device. The log entry in this case would look something like the following. Notice that the report reflects a changed – translated – port:
14:40:27.703 StunClient::process [CM506002]: Resolved SIP external IP:port (64.233.167.99:24842) on Transport 192.168.0.1:5060
14:40:27.265 StunClient::onInitTests [CM506001]: STUN request to resolve SIP external IP:port mapping is sent to STUN server 64.69.76.23:3478 over Transport 192.168.0.1:5060
Note: This setup may still work but it is not as reliable as the scenario described earlier (no PAT), therefore it is not recommended.
The resolved public IP and Port will be used by the PBX for all external (internet) communications. If your internet connection has a frequently changing IP address your PBX is running in what can be considered a hostile environment. This type of environment is highly discouraged as it will most likely lead to intermittent service. To see if you have a frequently changing IP by either reviewing the status monitor of your NAT device (WAN IP) or by reviewing the “Resolved external IP” in STUN server responses logged by the PBX in its status monitor page. If you choose to operate in such an environment make sure to have a short interval between external IP checks. From the 3CX Management Console, go to, “Settings” > “Network” > “STUN server” tab. In the “Query STUN server every (sec)” entry field, enter the time that the server will check for its external IP address.
DNS resolution
Before being able to communicate with a VoIP provider the PBX must resolve the IP of the server it has to speak with. The PBX will send SIP traffic to the specified “Registrar/Proxy” found in the VoIP provider’s configuration. If this is an FQDN (as opposed to an IP) the PBX will need to resolve it. It will first try to resolve the FQDN as an SRV record, and then (on failure) as an “A” record. “A” records are normal DNS records and these will be resolved normally. The PBX will ask it’s host OS to resolve the FQDN to an IP. The OS will ask the root servers for the DNS server in charge of the zone (example.com), and then ask for the particular record (A) at the zone’s DNS server. SRV records on the other hand have an extra step. “SRV” records are described in RFC2782 – these work much alike MX records. If the configured “Registrar/Proxy” of a VoIP provider is “example.com” the PBX will query for the “_sip._udp.example.com” “SRV” record. The initial steps for resolution are normal: i.e. the OS will query for the authorative server of example.com and then query for the SRV record _sip._udp at that server. The result however is not a single IP but a list of A records with a priority. e.g.:
_sip._udp.example.com. 86400 IN SRV 10 60 5060 bigbox.example.com.
_sip._udp.example.com. 86400 IN SRV 10 20 5060 smallbox1.example.com.
_sip._udp.example.com. 86400 IN SRV 10 10 5060 smallbox2.example.com.
_sip._udp.example.com. 86400 IN SRV 10 10 5066 smallbox3.example.com.
_sip._udp.example.com. 86400 IN SRV 20 0 5060 backupbox.example.com.
The PBX will then go ahead and query the returned A records. The record with highest priority (this is indicated as the one with the lowest number in the column directly after the SRV column) will be the server that the PBX sends the SIP traffic to.
Using NSlookup to check records
You can manually check what SRV records are available for a particular provider using windows nslookup. This allows you to easily check if the provider has correct SRV and A records setup. For example:
Nslookup –q=srv _sip._udp.3cx.com
This queries the 3cx DNS server for a SIP server.
This returns sip.3cx.com
3CX Phone System will then query the A record for this host. The resulting IP will be used by 3CX Phone System. Likewise, you can check what SRV records and IPs for A records will be returned by your VOIP provider.
Which interface is used for outgoing traffic
3CX Phone System uses Windows routing to decide which Network Interface it should use to do routing. Therefore, if you have multiple network cards in your machine, you will have to ensure that you have routing configured correctly. Use the windows route print command to find out traffic routes and priority.
Additional routable subnets
By default, 3CX Phone System will assume all devices on IPs of private networks as defined by RFC 3330 are local: 10.0.0.0/8,169.254.0.0/16,172.16.0.0/12,192.168.0.0/16
If you have additional local subnets that should be considered internal, then you can configure these in the 3CXPhoneSystem.ini file by setting the “localSubnets” option in the “[Network]” section. This option should be specified as a comma-separated list of IP Address ranges in the form “a.b.c.d/maskLen”. If the option is specified it completely overrides default ranges specified above, so you must add ALL local ranges, including those that are by default considered local.
Example 1:
[Network]
localSubnets=
; IP will be treated as local only if it is directly accessible (residing in the same network as PBX host).
Example 2:
[Network]
localSubnets=172.99.95.0/24,45.23.68.0/24
; IP will be treated as local if it is directly accessible (IP Address in same subnet as PBX)
; or has IP in range 172.99.95.0/24 or 45.23.68.0/24
REGISTER
Registration-Based VoIP Provider Accounts
The PBX will attempt to REGISTER its VoIP provider lines on startup. SIP registration is a method for a SIP device to inform its registrar (in this case the VoIP provider) where it is located. Once this is established the VoIP provider will know where to forward incoming calls. REGISTER requests are usually challenged for authentication; this is a handy way to find out if the credentials set up in the VoIP provider line configuration are correct.
If STUN resolution does not work then the PBX will NOT try to REGISTER. Registration attempts will show up in the server status page.
12:35:31.675 ClientRegs::Register [CM504003]: Sent registration request for 10000@sipgate
If no response is received then the VoIP provider’s server may have never received the request, the VoIP provider’s server did not send a response, or the response was lost on the way. Check that:
- STUN resolution is working – reviewed in status log.
- The host part of the SIP URI in the Contact Header in the REGISTER request is truly your NAT device’s public IP (and port).
- Port forwarding on the NAT device is indeed set correctly.
The VoIP provider’s response to a REGISTER request is usually a challenge (407). The subsequent REGISTER request to the provider will contain a Proxy-Authorization Header with the challenge response (a hash calculated using the nonce which was sent in the challenge) and an incremented Call Sequence Header. If the calculated hash matches the calculation done on the VoIP provider’s end, the VoIP provider will know that the PBX has a matching copy of the authentication ID and authentication password. The response from the provider should be either a failure, or a success. One of the following two logs will appear:
13:40:08.953 ClientRegs::onFailure [CM504005]: Registration failed for: 10000@sipgate
13:41:53.328 ClientRegs::onSuccess [CM504004]: Registration succeeded for: 10000@sipgate
If the REGISTER fails it is very likely that the credentials are set incorrectly. It is best to verify the credentials that are being used in the PBX’s configuration by cross checking using a SIP phone. Check your account details.
SIP Trunk (Non-Registration-based) VoIP Provider Accounts
SIP Trunk accounts do not go through the REGISTER process. The VoIP provider does not need to discover the client’s whereabouts because the client’s IP is fixed in a “hard coded” configuration in the VoIP provider’s server. Usually this can be set in a SIP Trunk account’s web portal. Apart from skipping the REGISTER process, SIP Trunks also skip the Authorization (challenge / response) process. This can be done because calls are automatically trusted by their source IP. i.e. calls coming from the configured IP address are identified by their source IP. When a SIP Trunk is configured in the PBX, the interface will still ask for an Authentication ID and Password (this is the way the 3CX VoIP Provider creation interface is designed), but they will be ignored when communicating with the VoIP Provider (since passwords are not used in this model) – the PBX will not try to REGISTER but a successful registered state will be assumed and a normal log entry will appear;
13:41:53.328 ClientRegs::onSuccess [CM504004]: Registration succeeded for: user@siptrunkprovider
Receiving INVITES
A successful registration means the VoIP provider knows the correct public address where it can reach the PBX. When the VoIP provider receives a call placed to a number assigned to your VoIP provider account it will send an INVITE to the address registered by the PBX. If you wish to review the registration, some providers will display the registration status in your VoIP provider account page. This internet address is the public IP of the NAT device, if forwarding rules are set correctly the INVITE will reach the PBX. The following is a sample INVITE;
INVITE sip:8632606@72.14.207.99:5060;rinstance=7303026702615448 SIP/2.0
Record-Route: <sip:217.10.79.23;lr=on;ftag=as21013b10>
Record-Route: <sip:172.20.40.4;lr=on>
Record-Route: <sip:217.10.79.23;lr=on;ftag=as21013b10>
Via: SIP/2.0/UDP 217.10.79.23:5060;branch=z9hG4bK11d4.8a4bf394.0
Via: SIP/2.0/UDP 172.20.40.4;branch=z9hG4bK11d4.8a4bf394.0
Via: SIP/2.0/UDP 217.10.79.23:5060;received=217.10.68.6;branch=z9hG4bK7d2a0377
Via: SIP/2.0/UDP 217.10.66.71:5060;branch=z9hG4bK7d2a0377;rport=5060
From: “0015552368” <sip: 0015552368@sipgate.co.uk>;tag=as21013b10
To: <sip: 8632606@sipgate.co.uk>
Contact: <sip: 0015552368@217.10.66.71>
Call-ID: 38b34a2512c9c1903d5d5940348c18f4@sipgate.co.uk
CSeq: 102 INVITE
Max-Forwards: 67
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces
Content-Type: application/sdp
Content-Length: 446
Source Identification – Default behavior
When the PBX receives an INVITE it will check its source. This checking is called “Source Identification” and the purpose of this process is to see if the call is a valid request, is from a trusted domain, and hence should be let through. If a call source is not identified (trusted) the PBX will ask for authorization. The default behavior for source identification is to check the “user part” of an INVITE’s Request Line against the authentication IDs configured in the PBX. Once a match is made the call is trusted and forwarded according to the configuration of the matched line.
In order to illustrate this process take for example the below INVITE which is coming from a VoIP provider with standard behavior. The VoIP provider line is configured with the following details:
External Number : 415551234
Authentication ID : 8632606
Authentication Pass : $ecret_W0rd
The received Request Line in an INVITE from this VoIP provider is as per below:
INVITE sip:8632606@72.14.207.99:5060;rinstance=7303026702615448 SIP/2.0
The user part in the request line is “8632606”, this matches the “Authentication ID” (8632606) of the configured line.
Latest source identification rules:
For PSTN providers: Match any of following:
- LineID is in Contact OR RequestLine (user part).
- Gateway host/port is in Contact.
For VoIP providers: Match any of following:
- AuthID is in Contact OR RequestLine (user part).
- External number is in To OR RequestLine (user part).
Source Identification – Custom behavior
Unfortunately not all VoIP Providers act the same and some VoIP providers will not INVITE with the SIP identity in the Request-Line URI. For these cases the source identification strategy can be altered in order to match any VoIP provider. In the “Edit gateway” page of a VoIP provider under “Source Identification” a custom matching strategy can be constructed. On the left there is a list of SIP fields and on the right there is a list of values against which the PBX will attempt a match. A call’s source will be considered successfully identified if a set pair matches (i.e. if they are equal when compared). The list of pairs can be set to match ANY, or match ALL. The latter means that if a single pair does not match, the PBX will assume a failure. An INVITE coming from the provider must be reviewed in order to plan a suitable strategy. Fields that do not change from call to call must be identified. Unidentified incoming INVITEs can be collected from the server status page. Advisable identifiers (constant fields) would normally be the Authentication ID or the External number (DID). In extreme cases you can fall back to identifying the source by locating the VoIP provider’s domain in some field or by the VoIP provider’s Proxy IP (if they are using a single IP).
Example:
-
“Request Line URI: User Part” can be matched against the “LineNumber external number of line”. This kind of strategy would suit cases where a VoIP provider inserts the DID number or external number of a line in the Request Line instead of the account’s Authentication
IDINVITE sip: 0015552368@ 72.14.207.99:5060;rinstance=800f2f60c40d1d10 SIP/2.0
-
“TO: User Part” can be matched against the “LineNumber external number of line”. This strategy would look for a line’s external number e.g. “0015552368” in the user part of the “To” header of the SIP URI in an INVITE from the VoIP provider in question.
To: <sip: 00495552368@myexampleprovider.de>
-
“From: Host Part” can be matched against the “GWHostPort gateway/provider host/port”. This strategy would look for the VoIP provider’s Proxy address and port (myexamplprovider.nl) in the host part of the SIP URI in an INVITE from the VoIP provider in question.
From: “00315552368” <sip: 00315552368@myexamplprovider.nl>;tag=as33577b1c
Via and record route
Via and record route
The Via header will show up in sip packets and basically indicates the “SIP hops” via which the packet has travelled. Last hops are inserted at the top. Responses to these sip packets are then sent to the back over the same path – starting with the top entry.
The Record route header is similar to the Via header, however it is used to instruct the receiving end point over which path to send any REQUESTS (as opposed to responses). A record route command is inserted by the proxy if it wants to remain in the loop for future communications.
The record route command will be used by the 3CX SIP bridge, which tunnels all traffic. The VoIP client, seeing the record route command, will send all traffic via the bridge (which inserted itself as a hop and therefore wants to remain in the loop), rather than directly.
Note: When the 3CX Phone uses the record route header to send a request back, it will insert “route” and not “record route”.