Excellent call quality with any phone system is crucial. While businesses these days do run on email and web, the telephone is STILL the lifeline of the business. Asterisk as a call processing engine for a PBX is well designed and very efficient, so it has many features that can be used to mitigate the most common problems. In this article we’ll briefly discuss the most common call quality issues that occur with IP PBX’s and how Asterisk-based systems can deal with him.
NOTE: These tips primarily deal with Internet-based SIP dial tone, except where noted.
This is arguably the most common issue with any IP-based PBX. It especially occurs at some point on systems with Internet-based SIP trunks for their dial tone. Jitter sounds like one of two things: Either “interruptions” in the audio, or “underwater sounding voices”. The issue is caused by inconsistencies in the delay between data packets between two endpoints. Most people, incorrectly, assume that they don’t have enough Internet bandwidth. This is generally not the source of the problem (unless the Internet is painfully underpowered for the amount of calls going through at the same time – i.e. dialer traffic). It has more to do with the QUALITY of the Internet than the QUANTITY of bandwidth. You can even have this problem on a LAN, where there is NO Internet connection and plenty of available bandwidth, but the LAN is congested or of poor performance.
With a poor quality Internet connection where there are inconsistent delays between packets, there isn’t a lot you can do with the provider. Once it leaves your network for the Internet, its out of your control. HOWEVER, Asterisk (and other IP PBX’s) have a function called a Jitter Buffer. A Jitter Buffer takes a portion of the audio and “buffers” it (stores it in memory briefly) before sending or while receiving. This has the benefit of removing or eliminating the jitter.
Occasionally a possible cause of jitter is processor overload on the firewall or switches. You can use your firewall or switch management tools to see if they are overloaded, then either remove some of the load, or upgrade them and see if the jitter is reduced and call quality improves.
One Way Audio
One way audio is a particular problem that is usually seen when a PBX is first installed. What it sounds like should be pretty obvious, based on the name. Only one party will hear the audio portion of the call. The call will ring, but when the destination party picks up, the receiver hears the call, but can’t talk back to the originator.
This problem is due to a misconfiguration of the Asterisk PBX, the firewall between it and the provider, or both. When a firewall sits between an Asterisk PBX and an Internet SIP provider, all packets go through Network Address Translation (NAT). In other words, the private IP address in the network packet is replaced with the public IP address of the firewall when the packet travels out, and the reverse happens on the return.
The issue specific to SIP is that a SIP packet is unique in that it has TWO places for the IP address, and a firewall typically isn’t smart enough to look for the second IP address (located in the SIP header of the packet). So when a SIP provider tries to send its traffic back to the firewall that sent it – it is going to try to send it to the IP address listed in the SIP header, which is a private LAN address can’t be routed over the Internet.
Some firewalls have a function called an Application Layer Gateway (ALG) – and it goes by different names by different manufacturers (SIP ALG, SIP Fixup, SIP-NAT, and so on), but they all basically do the same thing – look for SIP packets and get involved to do the SECOND IP address NATing.
Unfortunately, most firewalls do this incorrectly with Asterisk-based systems. Asterisk has a function built into its SIP configuration for automatically taking care of this issue. The function uses 3 parameters in it’s sip.conf configuration file (the location and use of which depends on which version and implementation of Asterisk you are using). These parameters are:
- localnet=<local network definition>
- externip=<external NAT’ed IP address of the PBX>
When these three parameters are configured correctly, the PBX automatically takes care of the NAT substitution for packets destined for Internet hosts.
NOTE: Because SIP ALG’s generally aren’t smart enough or often don’t work properly with Asterisk – we highly recommend turning them OFF and properly configuring Asterisk as described
Troubleshooting echo issues isn’t typically an issue with IP PBX systems using SIP providers, it is more commonly seen with systems that use more traditional connections to the telephone company. Connections such as PRI, or more commonly, analog lines.
Echo, as you may guess, is simply a repeat of some portion of the audio back to either speaker. There are two typical causes. The first is easiest to solve. Often, someone will be calling on a speaker phone with the volume turned up significantly and a portion of the audio is “feeding back” into the microphone. The person on the other end of the call will hear a portion of the audio delayed by a few milliseconds. The solution for this issue is straightforward, simply turn down the speaker volume and see if the quality improves (or pickup the handset and see if the problem goes away completely).
The more complicated cause is what is known as a “hot” volume on a trunk. That means that the incoming voltage is too high for the interface card to handle and it must be adjusted down to compensate. If the incoming voltage is too high, the caller from the outside will receive a portion of the signal echoing back. If the outgoing voltage is too high, the caller from the inside will receive a portion of the signal echoing back. If both are too high, both parties may receive echos.
Asterisk has the ability to adjust “gain” settings for its interface cards that can reduce or eliminate this echo if this is truly the source. The parameters are “txgain” and “rxgain” located in the DAHDI or ZAPTEL configuration settings (depending on the technology used).
Some interface cards also have built in hardware to automatically eliminate echo on problematic lines. If you are using interface cards without automatic echo cancelling, consider replacing them with cards with automatic echo cancelling cards. Be warned, however, they are more expensive than their non-echo cancelling counterparts.
It is important to note that the amount of echo is also dependent on the volume of the person speaking. If the echo problem is borderline, and the person speaking starts talking louder, then the echo may begin at that point because it has passed the threshold.
This article should give you a few items to look at when troubleshooting call quality issues on your Asterisk-based system (as well as any IP-PBX for that matter). For assistance with eliminating any of your call quality issues, feel free to contact us or email us at email@example.com