Managing VoIP quality is a constant headache for engineers. Here are some ways to avoid some common problems.
While VoIP has been considered mainstream in the enterprise for the past couple of years, network engineers still face a challenge to ensure consistent VoIP quality. Unplanned or surprise changes to the network can leave end users unhappy and administrators scratching their heads. Even the smallest configuration and setting changes have the potential to immediately and adversely impact applications. One way to guard against performance issues is to use retrospective analysis -- long-term packet capture for troubleshooting sporadic network issues -- to identify and fix common VoIP quality problems more quickly. Here are some steps to follow:
Assess quality of service. Quality of service (QoS) settings are often the first step to manage VoIP. If QoS settings are not set correctly, the VoIP call doesn't get passed at the priority it should. That can really affect call quality. Since network devices take care of setting the priority, incorrect QoS tagging can cause the quality of the calls to deteriorate. Customers will call in to figure out why they have one side of a phone conversation that sounds perfect and has a good mean opinion score while the other side is bad. Not having QoS tags properly configured can cause backups in the VoIP traffic, which can cause high jitter. If packets aren't arriving when they're supposed to arrive, there will be delays and the call will start sounding choppy.
To pinpoint the source of the problem, it is often necessary to begin at the packet level, using a retrospective network analyzer. A network recorder or advanced probe appliances placed at different points on the network, such as in front of different switches or routers, can collect a massive amount of data. Using different tools within the network analysis application, you can assess the QoS tag settings to determine if they are the same on both ends. If they're not, this method can help you identify the offending hardware device. If QoS settings have already been checked and there are still VoIP quality issues, there are a few other culprits that are likely to interfere with service delivery.
Changing codecs. The next item on the list is to check whether codecs are changing. When calls are established, phone systems communicate which codecs are supported. Typically, phones will use the highest-quality codec when the call starts. But if something happens during the call, and the phone senses high jitter or data loss, the codecs will get changed. By looking at which codecs were used inside a Real-Time Transport Protocol stream, you can actually see, for example, that a call may have started off at the G.711 codec, which is 64 Kbps sampling, then changed to G.729, which is only 8 Kbps sampling. This makes for a less choppy-sounding audio, but causes a drastic drop in quality. Typically, codec changes happen due to network congestion.
High network utilization and network congestion. Another way to reduce the time it takes to troubleshoot VoIP issues is to establish accurate baselines. In larger enterprise environments, this can mean several network probes collecting data. In other words, what is "normal" on the network? What is the normal utilization? What are the normal protocols that are running? Baselines let you know when things get out of whack, because network utilization can affect VoIP quality.
While monitoring packets, it is important you pay close attention to network use. Tracking timestamps during instances of high jitter or packet loss and comparing this data to the intervals of higher network traffic can provide valuable insights.
One enterprise VoIP user, the global finance company Santander, reported solving a VoIP quality issue in this way: An Adobe update to Acrobat caused significant problems to the company's network -- calls suddenly began to drop off across its call centers. By looking at the high spike in traffic compared to when calls started dropping, network administrators were able to identify high utilization as the cause of the problem. They then evaluated post-event capture data and discovered a surge of Internet traffic flowing to Adobe IP addresses. The fix, as it turned out, was rather simple: Santander IT set up Adobe Reader to access local servers for updates instead of going out to the Internet. Problem solved.
By following these steps to avoid VoIP quality killers, troubleshooting time can be reduced and service delivery improved. A retrospective network analyzer can also help engineers spot future trends and allow them to resolve issues before they become problems.
Thanks to Tech Target for the article.