RouterFreak Reviews, Tips and Tools for Network Engineers
Voice Over IP (VoIP) is a ubiquitous service in today’s enterprises. This poses challenges on the network due to the specific requirements for voice packets, not to mention the immediate user complaints when the voice system does not perform close to perfection. Troubleshooting a voice issue is a completely different story if compared to core traffic. Metrics such as latency and jitter becomes paramount, while the usually dreaded packet loss is often neglected up to a certain threshold. In addition, most voice applications are now moving to the Cloud, and that’s not great news for the average network engineer! In fact, this adds another layer of complexity to the troubleshooting, also because traditional monitoring tools do not have visibility inside the Cloud.
Voice is such a visible system for any business, which makes it very critical at the same time. No one can afford to call customers and business partners with poor voice quality. Bad communication equals waste of time and, generally speaking, a LOT of frustration that would quickly take over the conversation.
In order to cope with all the aforementioned challenges, it’s crucial to have a voice monitoring system able to tackle the modern applications troubleshooting. This is what ThousandEyes VoIP Performance Monitoring solution is supposedly doing!
Disclaimer: This is a sponsored review. However, the content and opinions stated here are independently written by RouterFreak’s team. As always, we provide honest product reviews, unedited.
ThousandEyes VoIP Performance Monitoring Solution
ThousandEyes VoIP monitoring solution allows to create three types of tests:
- SIP Server: performs a VoIP call session initiation with the target server using Session Initiation Protocol (SIP) over TCP or UDP.
- RTP Stream: creates a simulated voice data stream between two ThousandEyes Agents acting as the VoIP endpoints.
- Voice Call: simulates a full VoIP call, including the session initiation using the Session Initiation Protocol (SIP) and then the voice data transmission using the Real-time Transport Protocol (RTP) between call endpoints.
Now let’s see these tests in more detail, focusing on how they can be used to pinpoint voice issues that normally affect different segments of an Enterprise network.
SIP Server Test View
A SIP Server test is used to monitor the Session Initiation Protocol (SIP) phase that is necessary to setup a voice call between two endpoints. A SIP Server test performs a VoIP call session initiation with the target server using SIP over TCP or UDP. The ThousandEyes Agent sends the SIP OPTIONS (i.e., SIP Ping) command and optionally the SIP REGISTER command to verify server availability, authentication and to obtain a response code. Additionally, the SIP Server test supports loose routing through a SIP proxy to the destination SIP server.
The metrics supported by the SIP Server test are the following:
- Availability: percentage of time that the server responds to a request.
- Response Time: also known as time-to-first-byte, this is the time elapsed from the beginning of the request (before any DNS resolution) until the Agent receives the first byte of the response from the server.
- Total Time: time to perform the test, including DNS, Connect (when using TCP protocol), Redirects (if any), Register and Options phases of the test.
In the following image, we see a typical (faulty) voice test in which the agents located in Australia and Europe are struggling in connecting to the target SIP server. 
As we can see, the availability score dropped from the expected 100% value, and errors are reported in red from some agents. Switching to the Table tab allows us to have a first glimpse of the problem, as illustrated in the following image. 
Two out of four agents are not receiving a response code. In addition, they are seeing an “option” error with “Timeout while performing SIP options”. This already gives a strong indication of where the problem lies, and further data to work on is provided when clicking on the “Headers” link in which we can see the full request header sent by the agent. 
We keep looking for the truth, so we go down to the Network layer of data to check what is going on there. Not surprisingly, we immediately see connectivity issues from the agents to the SIP servers, in the form of packet loss.
The test data timeline is indicating heavy packet loss, peaking, and staying at 100% for several data rounds. In the data shown we picked in the above image, only two agents are showing an error, so let’s switch to the Map tab to know more. 
The packet loss is happening on the second to last node before the target SIP server, as we see it highlighted in red. This is particularly impacting Sydney and the “thousandeyes-va” agents. If we mouse over the lossy node, we can get an additional set of rich information about the outage. 
RTP Stream Test View
An RTP Stream test creates a simulated voice data stream between two ThousandEyes Agents acting as the VoIP endpoints. RTP packets are sent between the source agents and the target Agent, using UDP as the transport protocol. The RTP Stream test allows configuring the server port, call duration, de-jitter buffer size, and audio codec configuration options. The metrics produced by the test are one-way (source to target), and they include:
- Mean Opinion Score (MOS): a measurement of perceived voice quality, ranging from 1 (poor) to 5 (excellent).
- Loss: a stream of UDP packets with RTP as payload is sent to the target agent and packet loss is calculated from the number of packets received by the target.
- Discards: packets that are discarded when they reach the destination due to delay variations greater than the size of the de-jitter buffer setting, expressed as a percentage of packets sent.
- Latency: the average of time for each packet in the stream to travel from sender to receiver.
- Packet Delay Variation (PDV): the variation in delay from sender to receiver.
The following picture is showing an RTP Stream test from an Enterprise Agent called “thousandeyes-va” and the San Francisco Cloud Agent. The timeline displayed metric is the MOS score. In the bottom table, we can see a summary of other metrics including the received DSCP value. 
VoIP has very specific requirements such as discard, latency, and delay variations that need to be below a certain threshold in order to allow a good voice communication over the stream of data. In the following picture, we see the Packet Delay Variation (PDV) that spikes in a particular data round. 
Along with the peak of PDV, we can also appreciate discards if we switch to that metric view. When the PDV spike occurred, discards were also recorded at the same time. Again, here is the power of the layered approach of the ThousandEyes tool. 
The above picture is also showing additional information when hovering on the Path Visualization node. For instance, we can see the DSCP value flagged in red on the agent node, probably because at destination another value was received: this is an indication of QoS remarking along the path from source to destination.
Voice Call Test View
A ThousandEyes Voice Call test simulates a full VoIP call. First, the session initiation using the Session Initiation Protocol (SIP) and then voice data transmission using real-time Transport Protocol (RTP). The call can be simulated using several agents acting as source endpoints and sending voice streams to one target endpoint. Call registration with SIP servers is performed for all endpoints. Separate SIP proxies can be configured for one or both user agents. Simulated voice data is then sent via RTP between one or more agents and a target agent, using UDP or TCP as the transport protocol. As we can see in the following image, the ThousandEyes Voice Call test is a combination of:
- SIP Server layer
- RTP Stream layer
Basically, it embeds the two types of tests explained earlier in this article so we won’t cover them again here. It’s important to note that the two aforementioned tests are performed in sequence: first the SIP Server, and only if that one is successful, the RTP stream will be executed.
The metrics available are the same as the SIP Server and RTP Stream, so please refer to those. 
As usual, with ThousandEyes, we see that along the voice layer comes the Network and Routing layers that allow to dig down for more data when troubleshooting.
RouterFreak’s Verdict
In the past, we have reviewed ThousandEyes solution so we are pretty familiar with the layered approach of collecting data. Once again, we found this technique amazingly handy during the troubleshooting. When a problem occurs, ThousandEyes provides a bird-eye’s view of the issue from the top layers, allowing to dig down as needed.
The new VoIP feature does not make an exception. We tested the tool for monitoring SIP Servers and RTP streams, finding the usual easy-to-ease interface along with rich and detailed information when needed.
What we really liked was the ability to split SIP Server and RTP Stream in different tests. Similarly to DNS name resolution, it’s nice to see the path taken by SIP and RTP streams in order to optimize them for best performances.
Setting up the full voice call could be challenging at times because it requires having working SIP Serves for all agents, including specific credentials for authentication. It’s a pity that ThousandEyes doesn’t provide a ready to use SIP server. That is something that can definitely help enterprises while testing the solution, without having to setup their own SIP servers. Hopefully, something that ThousandEyes can include in the future.
The reality is that Thousandeyes can be used for strategic decisions. Let’s say an Enterprise is considering Office365 as a cloud solution. Before signing an expensive purchase contract, a savvy IT manager would require some in-house testing in order to ensure the app performs well when used in his offices. A similar scenario can be found when implementing a VoIP solution: before buying, better do some real testing in order to verify quality and performance of the voice tool.
In summary, we were pretty happy with this voice extension to the testing capability of ThousandEyes. The voice feature is clearly not a breakthrough such as ThousandEyes Endpoint Agents, but it’s definitely a nice to have, seeing how common VoIP solutions are in the modern enterprises. 
Another thing we really liked is the segmentation of the generated data. Using the Path Visualization, it’s possible to see if the problem lays on the source network, on the transit Internet, or on the destination segment of the path. This is key in today’s cloud-centric applications in which is really hard to predict where the traffic will end up. In a similar way, the Path Visualization allows exploring the path hop by hop, identifying interfaces that remark the DSCP value, regardless of the networks segment in which that occurs, private or public Internet. In this way, you can easily spot and pinpoint ISPs playing with your QoS marking. Once again, another blade added to the Swiss Army knife (i.e., ThousandEyes) of monitoring tools. Alerting on a specific threshold and reporting tools for in-depth data analysis are obviously available, as usual, as an integral part of the ThousandEyes solution. For more details about that, please refer to this review.
Conclusions
The VoIP Monitoring Solution is a great addition to the already wide testing capabilities of ThousandEyes. Little by little, these guys are expanding the visibility to all the dark and hidden corners of modern networks. Their goal is pretty clear: becoming the definitive tool for networks and applications monitoring in the Enterprise space.
ThousandEyes VoIP Monitoring can be tried for free by creating a Trial account. This will give you access to the full features for 14 days. You heard us until here, now it’s time to get your own opinion!
