How to troubleshoot problems arising from blocked ports, ACLs, firewalls, NAT, and more
For networking professionals, one of the most difficult things to deal with is troubleshooting VoIP issues, because the troubleshooting process for VoIP is not always intuitive. Answers to the questions, “What could be wrong?” and “What should I check first?” are not always readily apparent.
To aid your troubleshooting and allow you to take some meaningful actions before reaching out to your telco or vendor help desk, we’ve listed the most common VoIP problems you may face, as well as their causes and solutions.
Voice and data are different
Although it uses the same infrastructure as conventional data communications, voice over IP behaves differently on the network and has very different requirements. This is why it is often challenging for those accustomed to troubleshooting data network faults to pinpoint problems that may arise with voice services, even though the network seems to be working “just fine.”
The good news is that today, VoIP is a mature and dependable technology whose kinks have largely been ironed out and dealt with. Chances are that any problems you may face have already been faced and solved by other networking professionals in the past.
Some of the most common VoIP issues involve the blocking of TCP and UDP ports. Ports are the addresses employed on the Transport Layer of the OSI model that are used on a device to distinguish between applications and services. Various voice services use specific ports to function. If these ports are blocked at any point between the communicating devices, voice services may fail partially or completely. Depending on what ports are blocked, different functionalities of VoIP will be affected.
The location on the network where ports are most commonly blocked is at the network edge; that is, the point where the enterprise network meets the ISP (internet service provider) and the internet. At this location, there may be several mechanisms being employed such as access lists, firewall rules, or network address translation (NAT) that may be responsible for blocking ports. These services are all vital to the functionality and security of a network; however, they can also be the cause of VoIP failure.
Access lists (ACLs) – ACLs are rules found on the edge device of an enterprise network (a router or a firewall) that block or allow packets based on their source and destination IP addresses and ports. If ports that VoIP services require are blocked, then calls or registration may fail.
Firewall rules – Firewall rules go one or more steps beyond simple ACLs. Firewalls are able to inspect each packet that attempts to enter the enterprise network and to decide, based on specific security policies, which packets will be allowed, and which won’t. Other than source and destination IP addresses and ports, firewalls can look deeper into a packet and determine if it is safe to let the packet through or not. If a firewall is not configured to allow voice services to pass, a failure can occur.
Network address translation (NAT) – NAT has been the great deliverer when it comes to delaying the inevitable exhaustion of IPv4 addresses. By providing a translation from internal private IP addresses to external public IP addresses, it allows for the reuse of IP addresses within enterprise networks without any danger of conflict, thus giving several more years of life to the IPv4 addressing scheme. At the same time, it can be a nightmare for VoIP as it often causes problems with voice calls, especially those that are initiated from the outside. Elaborate best practices have been devised and have even been written up in an RFC to define NAT traversal practices for SIP-based voice communications.
Voice services affected by blocked ports
Different ports being blocked may impact voice services in different ways. This depends on what part of a voice service is being blocked.
Signaling - VoIP most commonly uses the Session Initiation Protocol (SIP) for signaling. What is often misunderstood is the fact that SIP does not carry any voice packets. It is used to initiate a call, send ringtone, provision bandwidth, and to establish services like conferencing, call waiting and call park, to name a few. If SIP ports are blocked, no calls can be initiated, the IP PBX cannot register with the SIP trunk, and telephony endpoints cannot register with the IP PBX. The default ports that SIP uses are 5060 and 5061.
Voice traffic – IP telephony traffic is carried by Real-time Transfer Protocol (RTP) and is monitored by RTP Control Protocol (RTCP). RTP and RTCP typically use UDP ports somewhere between 1024 and 65535. The specific ports that are used depend on the configuration of each IP PBX, IP phone and SIP trunk, and are largely defined by each individual vendor and telco in their own systems. If these ports are blocked, a call may actually connect successfully using SIP, but may experience one-way or no-way audio.
Trunk provider ports – Ports must be forwarded correctly both on the network edge and on the SIP trunk provider’s end of the link. Whenever a VoIP dysfunctionality is detected, the correct forwarding of ports should also be checked.
Quality of Service
Another set of voice-related malfunctions are linked to the amount of traffic on the network. A converged network is one where both voice and data traffic share the same infrastructure. Initially, voice services may function with an acceptable level of quality, but as data patterns and data applications change on the network, degradation can occur. This can result in delays in voice transmission, intermittent interruptions, the introduction of jitter and a general decrease in call quality. This is most likely due to either the lack of Quality of Service (QoS) mechanisms on the network, or their inadequate or faulty configuration.
Finally, many issues with VoIP are related to how the operating systems and firmware of VoIP devices and servers operate. Vendors continually update their firmware and provide free access to the most up-to-date versions online. IT professionals should upgrade and update device firmware regularly to make sure that any bugs or faults discovered by other users can be proactively dealt with and resolved.
If you still have to call tech support…
Even if you do proceed with troubleshooting, there are times when reaching out to the vendor or the telco is necessary. Keep in mind that if you have done the proper preliminary steps and you have gathered the appropriate information, you can substantially cut down on the time it will take the trained techs to solve your issues. When making the call, be sure to have the following information ready:
- If a user is complaining about faulty behavior of the telephony system, try to reproduce the fault so you have firsthand experience with it, verify that it is not user error, and be able to better articulate the issue to tech support.
- Have the firmware and/or software version numbers of the IP PBX, gateways and any other network equipment handy.
- Have the telephone or softphone model numbers or versions along with their configuration and setup on hand.
- Depending on the policies of the help desk you are contacting, be ready to provide some supervised access to your system via a remote desktop application.
Even though IP telephony shares the same infrastructure as conventional IP data networks, its behavior and troubleshooting methodology is far from similar. For this reason, it is important to be able to identify the problems related to VoIP and to determine more precisely where the fault exists, so it can be pinpointed and resolved more efficiently.
You may also like: