CallTure SIP Troubleshooting Basics


Common Issues and Related Troubleshooting Steps

For each of the issues listed below, corresponding troubleshooting steps have been listed in the order in which they should be checked and addressed.  Each sub-item refers to a section of this document, or the Callture VoIP Basics document.


Phones not registering

  • Check Phone Credentials
  • SIP Ports / Port Forwarding
  • Double-NAT
  • Incompatible Firewall


Phones register successfully, but then de-register after a certain amount of time

  • SIP ALG / UDP Timeout
  • Double-NAT
  • Incompatible Firewall


Poor voice quality

  • CallTure VoIP Basics (separate document)
  • Double-NAT
  • Incompatible Firewall


Check Phone Credentials

The most common cause of a phone not registering is incorrect or mis-entered credentials.  There are three pieces of information needed for successful SIP registration:

SIP Server - Also known as Domain. This is the IP address or FQDN of the CallTure Clout-hosted phone server.

SIP Username - The SIP Username is typically in the format [Pilot_number]_[Extension_number].

SIP Password - The password assigned to the SIP extension.


Desk phones

For desk phones such as the Polycom IP331, the SIP information is entered automatically by the provisioning server. Ensure that the MAC address for the extension has been entered correctly in the ‘Setup Devices’ section of the CallTure portal.

If the MAC address is correct, ensure that the provisioning server ‘’ has been entered correctly in the phone, and that the provisioning server type has been set to ‘HTTP.’  If ‘HTTP’ is unavailable, the provisioning server type should be set to ‘TFTP.’  The phone’s provisioning server information can be entered via an Internet browser using the phone’s graphical user interface (GUI), or directly on the phone using the phone’s built in display menu.  Where to input the provisioning server information varies from phone to phone.

If all of the above seems correct, but the phone is still not downloading its configuration, the phone should be reset to factory defaults.  The process for resetting a phone to factory default varies from phone to phone.  Once the phone has been reset to factory defaults, enter the provisioning server information again, and reboot the phone to see if it downloads its configuration.



Since the provisioning server depends on DNS to resolve the FQDN ‘,’ it is a good idea to ensure that DNS is working properly in the network where the phone is plugged in.  This can be done by plugging a computer into the same network, allowing it to get its IP address automatically, and then testing whether or not it can access Internet web pages.



The SIP information for softphones has to be entered manually. CallTure Support will send an email including the soft phone’s domain, username, and password.

Ensure that all information has been entered correctly. The username should be entered for both User ID and Authorization Name.

Example softphone settings for the Counterpath X-Lite softphone:




SIP ALG (Application Layer Gateway) (also known as SIP Transformation or SIP Fixup) is a common feature of commercial firewalls that is meant to improve VoIP communication by inspecting and (if necessary) modifying VoIP data that traverses the firewall. Many firewalls have SIP ALG turned on by default. Unfortunately however, SIP ALG tends to cause more problems that it solves, and it is always recommended that VoIP users disable this feature.

The process for disabling SIP ALG varies from firewall to firewall, however it is usually a checkbox that can be enabled or disabled. To figure out whether or not a firewall has a SIP ALG option that can be disabled, perform an Internet search for ‘[firewall model number] disable SIP ALG.’


NetGear Firewall SIP ALG example:


SonicWall SIP ALG example:


UDP Timeout

Some firewalls/NAT/Router have UDP timeout values that are set too low for VoIP communication. Check to see if there is a UDP and/or TCP timeout setting in the firewall, and set this to large value like 24-hrs or “never” for UDP. TCP values can be left default because VoIP communication does not utilize TCP.



Network Address Translation (or NAT) is the process by which a firewall translates traffic from internal IP addresses (LAN, or Local Area Network) to external IP addresses (WAN, or Wide Area Network).  This process should only happen once when VoIP traffic traverses the firewall.  Often times however, the communication between the modem provided by an ISP (Internet Service Provider) and a customer’s firewall is configured to perform NAT twice, creating what is known as Double-NAT.




How to Identify Double-NAT

In order to figure out if Double-NAT is occurring, check the ‘Status’ page of the Router/Firewall and try to identify the IP address that is assigned to the WAN interface.  This IP address in most cases should match the IP address (or be very similar to) the IP address that shows up when a computer in the LAN browses to a web page such as  If the IP address assigned to the WAN, or outside interface of the router does not match, and appears to be a LAN IP address (such as 10.x.x.x, 172.16.x.x, or 192.168.x.x), then this means that the WAN IP address is not assigned to the Router/Firewall, and instead lives on the outside interface of the ISP’s modem.  This means that Double-NAT is occurring.


How to Fix Double-NAT

In order to fix Double-NAT, the Technical Support department of the ISP that is providing the Internet connection should be contacted and instructed to put their modem into ‘bridge mode.’  Bridge mode essentially turns the ISP’s modem into a pass-through device so that the WAN IP address can live on the Router/Firewall directly.

If the ISP is supplying a dynamic IP address, you should then set the WAN interface of the Router/Firewall to DHCP, and it will automatically be assigned a WAN IP address.

If the ISP is supplying a static IP address, they will supply the proper IP addressing settings to the customer. The Router/Firewall’s WAN interface will have to be configured manually to match the settings supplied by the ISP.


SIP Ports / Port Forwarding

In order for phones to register to the CallTure Cloud-based phone system, typically no ports need to be open in the firewall.  This is because the majority of firewalls allow for outbound connections on all ports by default, however if phones are unable to register to the CallTure Cloud-based phone system, outbound traffic permissions should be checked (because the UDP protocol is a stateless protocol).

SIP ports to allow outbound:
UDP 5060 (for SIP registration)
UDP 10,000-20,000 (for Real-time Transport Protocol (RTP) traffic)

Sometimes it is possible that registration issues can be caused by older firewall rules that are still in place. For instance, if a customer is transitioning from a premise-based PBX using SIP to the CallTure Cloud-hosted phone system, there may have been firewall rules that opened SIP ports inbound to the old premise-based server. This would affect CallTure phones because the CallTure phones would send a registration request outbound, it would be received by the CallTure servers, but the response would then be re-directed to the old phone system because of the previous firewall rules. If this SIP re-direction is occurring, the CallTure phone will not be able to register.


It should be verified in the Router/Firewall that the same SIP ports listed above are not set up as firewall/port forwarding rules pointing to a different internal IP address.


One-Way or no audio

One-way or no audio on VoIP calls is typically indicitave of a firewall issue.  If phones register, but there is one-way, or no audio, ensure that the following ports are open in the firewall/router for both inbound and outbound traffic:

UDP 10,000-20,000 (for Real-time Transport Protocol (RTP) traffic)


Incompatible Firewalls

Some firewalls (such as Sonicwall firewalls) are notoriously bad at handling VoIP, and no amount of changes or troubleshooting will allow them to pass VoIP traffic successfully.  If all troubleshooting steps have been exhausted, the following tests may point to the firewall as the source of the problem.


Move the Phone to a New Location

By moving the phone to a new location that uses a different ISP and firewall (for instance, taking the phone home to test), the issue can be isolated to the original network that the phone was in.  If the phone functions fine at the new location, then the issue is related to the network or firewall at the original location.  If the phone is still experiencing issues at the new location, then the issue is related to the phone itself (assuming that the ISP and firewall at the new location are different from the original location, and that all previous troubleshooting steps have been accounted for).


Replace the Firewall

This is a fairly drastic troubleshooting step, and should not be attempted unless all other troubleshooting options have been exhausted as it requires a significant amount of effort, IT knowledge, and possibly cost.  That being said however, if the firewall is problematic and not allowing for successful VoIP communication, this step may be necessary.  Replacing the firewall with a firewall that is known to work well for VoIP communication will often times eliminate troublesome VoIP issues.



Have more questions? Submit a request


Powered by Zendesk