Complete VoIP Visibility with SIP and RTP

Posted by on June 21st, 2017
July 13th, 2017

Unified communications (UC) is an integral part of enterprise service delivery. Despite its importance, troubleshooting and maintaining a reliable voice network and end-user experience remains challenging. Irrespective of the type of voice deployment (on-premises, hybrid or cloud), the impact of the underlying network on voice performance is undeniable. Packet loss, jitter and latency influence voice quality and the sometimes transient nature of these issues makes VoIP troubleshooting tricky. As enterprises migrate towards cloud-based voice solutions or Unified-Communications-as-a-service (UCaaS), it adds another layer of complexity to troubleshooting. Traditional voice monitoring techniques that rely on packet capture and CDRs are often reactive and fall short when it comes to managing complex cloud-based voice solutions. This blog post will discuss why a proactive approach to managing voice solutions is critical and how our most recent product enhancements, SIP Server Tests and Voice Call Tests, will take you one step closer to maintaining a successful voice strategy.

One Problem, Many Approaches

Monitoring a complex application like voice requires a combination of data sets, each providing varying levels of visibility to isolate issues and streamline troubleshooting:

Active monitoring solutions provide insights into the health and availability of voice applications. You can also understand voice quality metrics like Mean Opinion Score (MOS) through simulated voice streams.

Call detail records (CDRs) provide more specific information about an actual voice call including call duration, information on the calling parties and call quality data (e.g., MOS scores). CDRs are critical for billing, auditing and provide a perspective of end-user experience as they track real voice calls.

Packet capture and protocol analysis can be useful if voice playback and granular inspection of voice packets is necessary.

While the insights garnered through CDRs and packet inspection are valuable, they reflect a reactive approach to voice monitoring. These techniques are also limited to on-premises or managed voice solutions where the operation teams have control over both the voice infrastructure and underlying transit. As enterprises slowly transition to a cloud-based model, CDRs and packet captures do not address pre-deployment benchmarking and visibility into voice performance outside the enterprise network. Enterprises moving to UCaaS deployment struggle with a lack of data on service availability and managing call quality.

Voice Monitoring for On-Premises and Cloud-Based UC

ThousandEyes combines availability monitoring and end-user experience by actively simulating voice calls across both internal and external networks. By continuously validating the complete lifecycle of a voice call from SIP transactions to RTP call quality, you can baseline voice performance. Baselining performance not only gives you an understanding of expected behaviour to identify anomalies but also helps with pre-deployment scenarios when migrating to newer UCaaS deployment models. Data collected at every layer is correlated and visually represented to quickly identify problem areas. You’ll get network topology transparency using our Path Visualization that pinpoints the source of the problem across any network infrastructure or provider.

Introducing SIP Server and Voice Call Tests

Today, we announced two new test types: SIP Server Tests and Voice Call Test to existing RTP Stream Tests. These new features provide complete visibility into all stages of establishing and maintaining a voice call.

Session Initiation Protocol (SIP) is the first step towards establishing a voice call. It is a multi-step signaling process where both the caller and callee (endpoints) have to establish the rules of engagement for the call. Commonly known as the “call setup” phase, it involves the endpoints registering with an intermediate authority (or SIP server). They negotiate and mutually agree on media capabilities for the call, like the voice codec. Once the endpoints have successfully navigated the call setup phase, they can start talking to each other directly through another Layer 7 protocol called Real-Time Transport Protocol (RTP). Both of these stages are equally important for a voice call, and it is key to keep an eye on both SIP signaling and RTP audio streams. The network path to a SIP server is independent to that of the RTP stream, hence understanding the network topology in each of these stages will provide contextual data for troubleshooting a voice call.

Troubleshooting SIP

With SIP Server Tests, you can validate the availability and responsiveness of your SIP server or proxy from branch offices or external locations. Verify every transaction in the SIP signaling phase, from user authentication through SIP REGISTER to call initiation through SIP INVITE.

In the following example (Figure 1) we notice a dip in SIP server availability from Paris and Amsterdam to a Cisco Call Manager located in San Francisco. Based on the error type, it is evident that each of these locations are experiencing two unique issues: Paris complaining of service unavailability in the Options stage while SIP signaling messages from Amsterdam don’t even make it to the SIP server due to a timeout.

Figure 1
Figure 1: SIP Server Tests indicate two distinct error types in different phases of SIP signaling.

Let’s address the unavailability issue first by taking a deeper look into the SIP message headers from Paris. The SIP OPTIONS Response headers, shown in Figure 2, seems to indicate a problem with the SIP server.

Figure 2
Figure 2: Identify errors in SIP headers.

However, calls from Amsterdam were experiencing a completely different issue. SIP messages were not even reaching the Cisco CUCM server. Network metrics, as shown in Figure 3, indicate an elevated packet loss from Amsterdam. Corresponding Path Visualization data pinpoints the packet loss to an outage in an upstream ISP, Cogent. Very clearly, these are two separate issues and need very different call to action. While it is important to identify issues, it is equally important to identify when, where and what is t these issues.

Figure 3
Figure 3: SIP signaling from Amsterdam fails due to an upstream outage on Cogent.

Combine SIP and RTP with Voice Call Test

As critical as SIP is to the success of a voice call, it is only one part of it. With RTP Stream Tests, we replicate audio streams at regular intervals and build a continual baseline of voice metrics like MOS, jitter and latency. You can visualize the path taken by a voice call and also understand the impact of QoS and DSCP on voice quality. Voice Call Tests combine both SIP signaling and RTP streams to give you a unified, correlated view of end-to-end voice delivery.

Finally, VoIP Monitoring Without The Jitters

Irrespective of your VoIP vendor or deployment model (on-premises, hybrid, UCaaS), ThousandEyes Voice monitoring can reduce those troubleshooting headaches. Interested in learning more about our enhanced voice capabilities? Try out the SIP Server Tests from Cloud Agents and Voice Call Tests from Enterprise Agents or watch this 30-minute webinar to learn more.

Processing...