Troubleshooting a Direct Remote Extension

This step by step guide will help you troubleshoot a direct remote extension setup at home or at a remote office. Direct remote extensions can work but correct functionality cannot be guaranteed as there are many factors at play (such as: Network Topology, Router configuration, Firewall settings, etc.) and you may not have control over all the devices involved to make the proper changes necessary for a direct remote extension to function as expected (such as, for example, when using a Hotel’s Internet connection or some other public WiFi).

Is your Extension Allowed to Connect Remotely?

Troubleshooting a Direct Remote Extension

You must start by checking two important settings relating to remote connectivity, located in the “Extension Details -> Other” tab of the 3CX Management Console:

  • You must disable the “Disallow use of extension outside the LAN” option if you plan on using this extension as a remote extension.
  • You must disable the “Block Remote Tunnel Connections” option if you plan on using this extension as a remote extension using the 3CX Tunnel Protocol or the 3CX SIP Proxy Manager.

Server-Side Port Forwarding

The only sure-fire way of resolving or reducing issues is to remove as many variables from the situation as possible. Where this reaps the greatest benefit is on the WAN-to-LAN device that connects your 3CX Phone System to the Internet.

Putting proper port forwarding in place is your most effective tool towards removing a large number of potential NAT/PAT issues. You need to make sure that you have a firewall/router that supports and is configured to use static port mapping. Static port mapping is, in most cases, a requirement for audio and video streams to be delivered correctly via the RTP protocol. 3CX provides a guide and more information regarding static port mapping here, while a more comprehensive list of the ports used by 3CX Phone System can be found here. However, the most important ports to keep in mind for Remote Extensions are the following:

  • UDP: 5060 3CX Phone System SIP (default).
  • UDP: 9000-9049: RTP Audio/Video Exchange with remote extensions (default).
  • UDP & TCP 5090: 3CX Tunnel Protocol Service (default).

Supported Phone Devices with a Complete Set of NAT Traversal Features

If you want to setup a remote extension (without using the 3CX Tunnel Protocol or the 3CX SIP Proxy Manager) you need to be sure you select a supported phone that has all the necessary features. These features include:

  • Rport Functionality
  • STUN Functionality
  • Keep – Alive Functionality

Most supported phones will support the necessary functionality listed above. For more detailed information about these functionalities please see this document.

Once you select a supported device for your Direct Remote Extension, you can configure it by following this guide: Configuring a Direct Remote Extension

When you have configured your device you need to confirm that it registers successfully.

Now you can attempt to make a call into 3CX Phone System. You can call some extension’s voicemail, and next attempt to listen to the voicemail message to ensure that audio is working both ways. If you run into Audio issues and you have previously completed implementing the recommendations in the previous section, then this means that the issue most probably lies with the WAN-to-LAN device that connects the remote extension to the internet. One way to almost completely confirm this is to attempt connecting your remote extension using the 3CX Tunnel Protocol, or using the 3CX SIP Proxy Manager.

Using the 3CX Tunnel Protocol or the 3CX SIP Proxy Manager

Install 3CX Phone for Windows in the remote LAN and connect to 3CX Phone System using the 3CX Tunnel Protocol.  Now repeat the test you attempted in the previous section – call some extension’s voicemail, and next attempt to listen to the voicemail message to ensure that audio is working both ways.

This configuration should give you two-way audio, confirming that there are no issues connecting remotely via the 3CX Tunnel Protocol or the 3CX SIP Proxy Manager (which uses the 3CX Tunnel Protocol) to connect remote locations to 3CX Phone System over port 5090 for both Audio and SIP messaging.

It is recommended at this point that you continue using the remote extension with the 3CX Tunnel Protocol (if using 3CXPhone for Windows / Android / iPhone) or use the 3CX SIP Proxy Manager to Proxy your calls via the 3CX Tunnel Protocol to 3CX Phone System remotely. If you need help configuring the 3CX Phone for Windows with the Tunnel you can follow the guide here or setting up the SIP Proxy Manager guide here.

If you would prefer to continue with troubleshooting the Direct Remote Extension you can continue to the next step.

Firewall Checker

Run the 3CX Firewall Checker from the 3CX Management Console. The 3CX Firewall Checker checks whether the ports needed to communicate with your remote extension/VoIP Provider are open and configured properly with Static port mapping. Common symptoms that can be linked to incorrect firewall configurations are:

  • Failed registration.
  • One-way audio.
  • Stun problems, or incorrect resolution.

For a more in depth look into the firewall checker please read the firewall checker article here.

Depending on the outcome of the firewall checker, you can go back to the Port Forwarding section above once Firewall configurations have been fixed. If the issue is not yet resolved you can continue to the next step.

SIP ALGs or Helpers

Some Routers have a feature called “SIP ALG” (sometimes called “SIP Helper”). This feature modifies the SIP header fields in an attempt to facilitate NAT/PAT traversal.  As SIP devices and the SIP standard have evolved, more robust mechanisms have been introduced – for example, the addition of the “Rport” field to the “VIA” SIP Headers. Leaving the SIP ALG enabled on your WAN-to-LAN device is very often likely to break SIP functionality for your remote extension due to its negative interference with the SIP “VIA” Header fields and its “Rport” extensions. Be sure this feature is disabled on your Router.

There are a number of reasons why dynamic NAT (and PAT) is insufficient to resolve NAT/PAT traversal issues for VoIP traffic in general and for SIP Signalling more specifically. For a detailed guide with more information about NAT/PAT please refer to this document.

Working Around the Issue

Custom Parameter “ALLOWSOURCEASOUTBOUND”

In the 3CX Management Console, go to the “Settings -> Advanced -> Custom Parameters” page and search for the “ALLOWSOURCEASOUTBOUND” parameter. The default value is “0″ (disabled). When this parameter’s value is set to “1″, 3CX Phone System will use the IP Address and Port inside the “IP” header of the SIP request instead of the values in the “Contact” SIP Header field provided by the remote extension. Also, the 3CX Media Server will use the IP Address and Port in the “IP” header of the incoming RTP (audio) stream to calculate the destination IP Address and Port to send the return outgoing RTP stream.

This parameter may be set when remote extensions cannot provide correct information for some reason, including (but not limited to):

  • Remote extension is behind double/triple NAT.
  • Remote extension does not support SIP extensions for NAT traversal (Rport).
  • Remote extension’s SIP implementation provides inconsistent (buggy) information.
  • Remote extension is inside a LAN which has a SIP ALG somewhere between the remote extension and the internet connection it uses for communication, and the SIP ALG performs incorrect modifications of SIP messages.

Setting this parameter may assist with resolving some issues with remote extensions which have NAT/PAT traversal issues.

Distinct SIP Listening Ports

If you are attempting to configure multiple remote extensions within the same LAN, and you are experiencing issues which persist even after going through all the other points mentioned in this troubleshooting guide, you may try assigning different local SIP ports for each remote extension (one device on port 5060, the next on port 5062, then 5064, and so on) – in some cases this allows you to work around the limitations.

Conclusion

After following these steps to troubleshoot remote extensions, you should have an understanding about the reasons why careful configuration is a pre-requisite for reliable correct functionality.

We mentioned at the start that correct functionality cannot be guaranteed because of the large number of contributing factors. The only method which 3CX can provide full support for is to configure a remote extension to use 3CXPhone for Windows/Android/iPhone with the 3CX Tunnel Protocol, or using some other support SIP Phone configured to pass its traffic through the 3CX SIP Proxy Manager.

However, this guide shows you the proper steps to follow in troubleshooting one way audio issues and registration failures with remote extensions.

  1. Pingback: 3CX VoIP blog » How to Configure External Extensions for 3CX PhoneSystem

  2. Hi, I have successfully configured 3 branch offices using TCP tunnels, and I have a question: what is best-practice in this scenario for “PBX delivers audio,” and “supports reinvites,” and “replaces”? The office tunnels successfully pass calls, and quality is good. I wonder if it could be better, or more rock-solid with a best-practices (e.g. never use “PBX Delievers Audio” with tunnels, etc). The phones on both ends are Yealink T28. Presently I have “Supports Reinvites” and “PBX Delivers Audio.” We are West Coast US, and the longest distance branch office is East coast; that’s the one that has given us the most trouble with packet loss. With the current settings, it is pretty good. There’s some clipping once in a while, but mostly the calls are good between branches. Their outbound calls go out over a patton 4114. Thanks for your reply about “best practices.”

    February 21, 2012 at 6:24 am
  3. Forgot to mention that all branch offices have a licensed 3cx box; every office has a 3cx server that provides a tunnel end.

    February 21, 2012 at 6:26 am
  4. Kevin

    The answer to this depends on the question “Best for what?”. If you disable the “PBX delivers audio” checkbox, your phones will attempt to exchange audio streams directly with the provider across your WAN-to-LAN boundary, potentially giving rise to all manner of NAT traversal issues. The “Supports ReINVITEs” and “Supports Replaces” invoke different mechanisms for performing hold/resume/transfer functions.

    Do keep in mind that most of the in-house testing done by the 3CX testing team is performed with the default settings; changing the settings away from the defaults will not only give you a scenario that has been exposed to much less testing, it will also make your configuration scenario an unsupported one. 3CX may still attempt to offer support on such environments, but ONLY on a best-effort basis.

    February 21, 2012 at 11:47 pm
  5. Michael

    Hi Kevin,

    With the new multi-tenant release being sold as a cloud solution, will 3CX be providing full support for hard extensions and not just 3CX Soft phones?

    I am thinking of those who work from home and will want a hard phone, but unable to use the SIP Proxy.

    February 28, 2012 at 10:05 pm
  6. 3CX fully supports use of IP phones as external extensions. However, the troubleshooting of such extensions is not free of charge. If you need help configuring your network to allow for external extensions, then you will have to pay for the technical support involved in doing that. Its not a case of us not supporting it its a case of having to be paid for the work involved.

    February 29, 2012 at 12:15 am
  7. Larry

    Hi,

    I followed the document to program a Cisco SPA504G as a direct remote extension and installed at home. It registers with 3CX server, and I can call other extensions in my office in the same 3CX server. No audio issues. However, I cannot dial it from any other extension.
    The home ADSL router is configured with static NAT map. I can web browse the phone from the 3CX server, but can not reboot it.

    Any advice?

    Thanks.

    March 11, 2012 at 8:50 am