VoIP Quality Still an Issue
With the adoption of cloud-based UC and telephony comes a need to rethink network monitoring.
You would think by now that voice quality issues were a thing of the past, given that we've known how latency, jitter, and packet loss can impair VoIP quality for a couple of decades. But as network infrastructure and traffic change, so too can voice quality. Are you sending voice over the Internet? Are you using cloud-based communications? You need to measure again -- and again -- to ensure voice quality remains acceptable and consistent. The question remains, do you want to own the technology or use a cloud service for voice quality testing?
For fresh perspective on this topic, I interviewed Nick Kephart, senior director of product management at ThousandEyes, which makes tools for monitoring network infrastructure, troubleshooting application delivery, and mapping Internet performance, all from a SaaS-based platform, as seen in the graphic below.
Why do we still have VoIP voice quality problems?
Kephart: Voice traffic is especially susceptible to latency and jitter, given the real-time nature of a conversation. Voice is a highly visible, critical service [on which] employees, customers, and executives are quick to notice performance problems. Yet, most monitoring products focus only on end-to-end call detail records [CDRs]. They overlook network details at a level sufficient to locate capacity issues, jitter, loss, latency, and DSCP (QoS) remarking. And as cloud-based UC and VoIP are adopted, the reliance on the Internet for end-to-end connectivity and service delivery will only make the shift in monitoring approach more critical.
What are the issues when testing VoIP call quality?
Kephart: Traditional VoIP monitoring techniques that rely on CDRs and packet capture are often reactive, highlighting issues when it's too late. They also provide little to no visibility outside of the corporate network. These techniques can be supplemented with active monitoring of voice traffic that tests both the setup of a VoIP call and quality of the voice stream. This means actively monitoring all parts of the voice call, from SIP signaling to RTP streams.
Every network segment is critical. Troubleshooting can be accelerated with the ability to correlate SIP transactions, voice quality, and QoS measurements to underlying network performance for a better understanding of end-to-end service experience.
Are there specific issues when testing a SIP trunk?
Kephart: SIP-to-analog PSTN phone systems, from private to public domains, can add another layer of complexity because they require interconnection gateways that translate VoIP streams into an analog signal. However, there is less and less of that occurring, with most public and private deployments shifting to IP-based systems.
Are there common server issues -- customer vs. provider?
Kephart: With UCaaS deployments, a large portion of the network that voice traffic traverses is outside the enterprise. Our customers frequently run into ISP (service provider) outages that impact voice quality and delivery. It is also common to run into QoS issues, due to DSCP remarking within both customer and ISP networks. Customer networks can have a variety of issues, from DNS resolution to congestion to poor inline device performance.
Do the UCaaS providers share performance data?
Kephart: Some UCaaS providers provide an API for performance data; however these focus on post-call metric collection. End-user [organizations] will want to be proactive, gaining real-time insights into the performance of cloud-based UC and VoIP services to evaluate vendors, properly determine SLA performance, and resolve problems.
What is and isn't covered in cloud VoIP performance SLAs?
Kephart: Typically, when cloud-based VoIP traffic traverses the Internet, all bets are off. This is because the Internet is a public "best effort" network consisting of others' third-party infrastructures. Most UCaaS vendors have SLAs on their data centers and the availability of services within, not connectivity from customer locations. [For related No Jitter post, see "Voice & Video Performance SLAs: Do Yours Deliver?"]
If the voice quality performance is not acceptable, what are the recourses?
Kephart: When traffic traverses corporate networks or the Internet, understanding the cause of issues and where they are occurring will help remediate problems more quickly. Recourses can include making routing and connectivity changes, opening tickets with service providers or, in the long term, considering changes to architectures or the choice of service providers.
The lessons we learn from testing and improving VoIP quality can be applied to video transmissions. The major difference is that video consumes more bandwidth than voice. Therefore, video transmissions are more susceptible to impairments and problems are visible immediately. Sometimes we can still understand impaired voice because we know about the subject or know the speaker but when video is disrupted; it is hard to imagine what was happening on the screen.