Course Content - Intermediate 3.1
Remote IP Phone Extensions (STUN)
Welcome to the online training series from 3CX. This module will guide you through the configuration of Remote Extensions using the STUN protocol.
Todays training will focus on the correct implementation of IP Phones in a remote location, using STUN.
We will see what configuration is required at the remote site, on the firewall, router or border device.
We will then see how a remote extension, using STUN, is provisioned.
And we will also see the use of the IP Phone vendors’ RPS services and explain the process behind their use.
This module assumes that the configuration of the local firewall at the PBX site has been configured in accordance to the Basic module 1.3, Configuring the Firewall.
A supported phone should be used to provision a remote extension, and this phone should be running the minimum firmware version, which should include the SSL certificates of 3CX as trusted. Older firmware will cause phones not to provision. If you are using your own SSL certificates, ensure the firmware of the phones you are using, trust the SSL certificate you are using.
You will need to have a functioning SMTP server defined on the PBX. This is needed to send the welcome email to the end users. The welcome email will contain the relevant information about the extension, which the user will need during the provisioning of the phone.
You will need to have access to the remote firewall, router or gateway device in order to perform port forwarding at the remote location.
The supported desktop IP Phones which are supported for STUN provisioning are models from the 3CX supported brands.
Full details on which models are supported by 3CX can be found at www.3cx.com/support
A remote STUN extension will provide internal call capabilities to a remote user, allowing them to use their phone as if they were in the office.
This also allows the administrator to dropship IP Phones direct from their distribution channel, without the need to have the phones shipped to the administrator to configure these, and then ship them to the end user at the remote location.
Additional hardware is not required at the remote site. The phones will be connecting directly onto the network and will be communicating directly with the PBX, through the internet, without any intermediaries.
This will also allow the phones to auto discover the 3CX PBX, no matter where they are in the world.
The administrator will need to create the extension in the PBX.
This is easily done by entering the Make and Model of the phone, the 12 character MAC Address of the phone, and in the extension’s Provisioning tab, define the ports which will be used by the phone in the remote network.
These ports, are the remote SIP Port and the remote RTP ports which the phone will be communicating on. If you have more than one device at the remote location, these ports will need to be incremented for each subsequent device at each location.
For example, the default Remote SIP Port is 5065. This will need to be incremented by 1 for each additional device at the same location. So the 2nd device will have a SIP port of 5066, the 3rd, 5067 and so on.
The default remote RTP ports are from 14000 to 14019. The Remote RTP ports for each additional device at the location will need to be incremented to 14020 to 14039 for the 2nd device, 14040 to 14059 for the 3rd device and so on.
Going to the “Options” tab of the extension, remove the restriction to “Disallow use of extension outside the LAN”. This will allow the phone to register from the remote network. This restriction is in place for security reasons and should only be disabled when required.
On the remote firewall, perform the port forwarding of the ports you have defined for each of the extensions at this remote site. Please note that the phones at the remote site will need to have static DHCP leases in order to prevent them from changing IP Address, and voiding the port forwarding.
After the configuration of the extension, send the welcome email to the user of this extension.
STUN stands for Session Traversal Utilities for NAT.
In order to explain what STUN is, let me mention something we use every day. DNS. When we want to connect to a website, we enter a URL, in this case www.3cx.com. Your computer will now go and request the IP Address of this URL from it’s DNS server. The IP which the DNS server responds with, will now be the destination, which the computer and every router between your computer and the destination can understand.
Now, back to STUN and how it works. STUN basically works the other way around, where instead of the destination IP, we need to discover our source IP.
A remote phone, when in a remote network, will usually have a private IP Address. This IP Address will not be able to be used by the PBX, as the private IP Address will not be contactable from the PBX directly. The phone will need a way to find out, and communicate the public IP Address of the remote network to the PBX.
This is where STUN comes in. The phone will contact the STUN server, and request its location information. The STUN server will respond with the IP Address and port which the phone is connecting from. The phone will now be able to send requests to the PBX with this information and allow successful communication between the 2 sites.
The STUN server of the phone is the PBX, as it is the PBX which will be accepting the connection requests from the phone. As some networks may be translated in different ways for different destinations, if you have a 3rd party STUN server, the IP Address may be different if contacting a different network.
The end user will need to just reset the phone, if this is not a new device. If it is a new device all they need to do is correctly assemble the phone, with the handset and network cable and power up the phone at the remote location.
The phone will then perform its boot sequence and will then show the user a login screen.
The user will need to enter the username and password of the extension to login. The username is the extension number, and the password is the voicemail PIN number.
They will get this information from the welcome email which they should have received from the PBX.
They will only need to enter this information once, during the provisioning of the phone. If the phone reboots, they will NOT need to login again.
In order to provision a remote extension with STUN, 3CX now utilises the Remote Provisioning Services of the IP Phone manufacturers.
The Remote Provisioning Service is triggered automatically when the Provisioning method of an extension is selected as “Direct SIP (STUN - remote)”. The PBX will send the MAC Address of the phone and the provisioning URL to the RPS server.
This provisioning URL and MAC Address will now be bound to each other for a period of 2 weeks. During those 2 weeks the particular phone will not be able to be assigned to another PBX. The URL/MAC combination will be delisted from the RPS server of the manufacturer after 2 weeks have elapsed from the configuration of the extension.
When the phone is reset and boots it will contact the RPS server of the manufacturer and retrieve any URL which may be assigned to its MAC Address.
The phone, now configured with a provisioning URL will contact the PBX and attempt to connect.
When provisioning a remote STUN extension some of the following symptoms may arise:
- You cannot connect to the server
- You are facing audio issues
- Or you cannot transfer, place a call on hold, or resume a previously held call.
In such a case, you will need to check your remote firewall for the following:
Ensure that SIP ALG is disabled on the remote network firewall, router or gateway device.
Check that the port forwarding has been correctly implemented on the remote firewall device, as we mentioned previously in slide number 6.
Also, if you have configured more than one phone at a particular location, then you will need to have the option “PBX Delivers Audio” enabled on the extensions in order for the audio to come from the PBX.
When two local phones are in a call, the audio, by default will be going directly from one extension to the other without the intervention of the PBX. In a remote STUN environment however, all the negotiation will be performed on the public IP Address of the remote location.
Some firewall devices do not allow local devices to communicate with each other on the public, external IP Address of the firewall. This is called hairpin redirection, and is usually blocked by most firewall devices.
Enabling PBX delivers audio will enable the PBX, which does have access to the extensions, to proxy the audio.
Thank you, and goodbye!