Troubleshooting

Troubleshooting and network issues

Common Issues and Related Troubleshooting

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

TeliWorx 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 TeliWorx 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 TeliWorx portal.
If the MAC address is correct, ensure that the provisioning server ‘phone.fibrehub.com’ 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.

DNS

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.

Softphones

The SIP information for softphones has to be entered manually. TeliWorx 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

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 than 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.’

continued

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.

Sometimes SPI can also cause an issue but should only be turned off if necessary.

Double-NAT

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 www.whatismyip.com. 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 TeliWorx 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 TeliWorx 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-12,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 TeliWorx Cloud-hosted phone system, there may have been firewall rules that opened SIP ports inbound to the old premise-based server. This would affect TeliWorx phones because the TeliWorx phones would send a registration request outbound, it would be received by the TeliWorx 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 TeliWorx 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 indicative 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.

ALL OTHER ISSUES CONCERNING SIP ROUTING AND ISSUES

What is NAT?
NAT (Network Address Translation) is a technology most commonly used by firewalls and routers to allow multiple devices on a LAN with ‘private’ IP addresses to share a single public IP address.

What is “Firewall and NAT traversal”?
One of the technical challenges to implementing a SIP based VoIP solution is making everything work when a firewall and/or NAT is deployed between devices exchanging data. TeliWorx Hosted PBX service utilizes a remote “server side” solution to this technical issue.

Should I set NAT traversal technologies such as STUN and ICE on my phones?
No.

While there are some perfectly valid circumstances where configuring NAT traversal technologies on your local device is desired, unless you have a concrete reason to do so and clearly understand what you are doing, we strongly recommend that you disable all NAT traversal technologies including, but not limited to, STUN, ICE, and hard coding external addresses.

Should I configure SIP or NAT traversal technologies on my firewall?
No.

Well, maybe.

If you are using a Cisco ASA Router which is known to have a quality SIP ALG implementation that works well generally then enabling the SIP ALG will generally work and not cause any issues.

Unfortunately many of today’s lower end commercial routers implement SIP ALG (Application Layer Gateway), coming with this feature enabled by default. While ALG could help in solving NAT related problems, the fact is that many routers’ ALG implementations are wrong and break SIP.

An ALG understands the protocol used by the specific applications that it supports (in this case SIP) and does a protocol stateful packet inspection (SPI) of traffic through it. A NAT router with a built-in SIP ALG can re-write information within the SIP messages (SIP headers and SDP body) making signaling and audio traffic between the client behind NAT and the SIP endpoint possible.

So unless you know the SIP ALG on your router/firewall works (the SIP ALG on a Cisco router for example), we recommend that you disable it and all NAT traversal technologies including, but not limited to, SIP ALG (ALG), and SIP Stateful Packet Inspection (SPI), and SIP Transformations.

Why do you recommend I turn these features off?
TeliWorx utilizes a complete “server side” solution to NAT traversal. This solution operates under the assumption that the end user is not employing any “client side” NAT traversal technologies on their devices or firewalls. In some cases, our server side solution can be confused by changes made by client side technologies – the net effect being that NAT traversal fails.

Problems typically arise when client side NAT traversal technologies are either a) successful enough that they convince our server side solution that the end user device is not behind a NAT, but otherwise fail to work correctly or completely, or b) fail to work to the extent that our server side solution still recognizes that the end user device is behind a NAT but does not function correctly because the original SIP packet has been modified on the client side in some manner.

Furthermore, our server side solution optimizes call routing by making use of the IP packet header in conjunction with the internal IP address information inside the SIP packet body. For example, if we determine that both the caller and callee are behind the same NAT, the media will be routed directly between phones such that it never leaves the internal LAN (for example, extension to extension calls within the same office). Client side NAT traversal technologies which modify SIP packets can interfere with this process and in some cases can cause calls that could stay on the internal LAN to routed across the Internet.

That said, there are completely valid and workable circumstances where a network administrator may require local NAT traversal technologies to be deployed on their router/firewall. For example, the SIP ALG on Cisco routers is known to work well with our service and we recommend it (our server side system will not be engaged at all in this scenario). However, the only configuration that we currently support is our server side solution.

How will multiple internal NATs affect my service?
Using multiple internal NATs may be alright in some circumstances but not others depending on your LAN’s configuration. If you are using phones on multiple internal LANs you will experience problems calling across LANs unless your network administrator has previously configured internal network traffic to route appropriately. For instance a phone on the 192.168.1/24 network will not be able to reach a host in the 192.168.2/24 network unless steps have been taken to ensure this kind of routing behavior.

In other words, the best way to ensure a simple seamless experience is to put all of your IP phones that are located behind a single public IP address on the same LAN.

Firewall Settings
You should not have to “open up” any ports or IP address ranges for TeliWorx. The phone, the device behind the firewall makes the connection from inside the network out to TeliWorx. We simply respond to those packets. As long as nothing is specifically being blocked, this conversation should happen just like any normal network traffic and should not be an issue.

If you are forced to specifically open ports, it will be a difficult task. SIP uses one port for call setup – easy to open – but for the call media, the phone uses any of a range of ports, and it’s a different range for each phone manufacturer.

“General” Firewall Rules
Not all firewalls will support these settings, but as a general rule, if you are having firewall issues, these settings should clear those issues:

UDP Port Timeout:
Increase UDP timeout to 120 seconds

SIP uses UDP (as opposed to TCP) and our keep alive messages arrive every 25 seconds. A very short UDP port timeout will cause phones to be unable to receive inbound calls because the port we are sending the call to will have timed out. Setting the UDP port timeout to anything between 45 and 120 seconds will alleviate that issue.

VOIP => Settings:

Turn on Consistent NAT.
Disable SIP ALG
Consistent NAT helps the device to have the same external port opened every time it connects. In this way, if the UDP port does timeout, the next time the phone makes an outbound call, that original port is re-opened thereby allowing the next inbound call to successfully arrive.