New Features in PRTG 7.2: The QoS Sensor - Our take on "VoIP Monitoring"

Published by Dirk Paessler
Last updated on March 03, 2022 • 7 minute read

During the beta test of version 7.2 of PRTG Network Monitor I am posting a few posts about new features that we have built into this new version.
new features in prtg 72 the qos sensor our take on voip monitoring
Today's post is about our new "QoS Sensor" which is used to monitor the quality of a network connection by looking at "quality of service" parameters like jitter, packet loss, packet delay variation, and other readings. Slight variations of these parameters usually have only little effect on TCP-based services (e.g. HTTP, SMTP, etc.). But for UDP-based services like VoIP and video streaming a steady stream of data packets is crucial. The sound quality of a VoIP call drops dramatically when UDP packets are not received in a timely fashion, if packets are lost or reordered.

Our new QoS sensor measures the following network connectivity parameters:

  • Jitter in ms according to RFC 3550
  • Packet delay variation (PDV) in ms according to RFC 3393
  • Lost packets in %
  • Reordered packets in %
  • Duplicated packets in %
The measurements are taken by sending UDP packets between two remote probes. This means that you can test any network connection in your network by simply placing a remote probe on (or near) each "end" of the connection and measuring the connection quality between them. This is the perfect tool to find network issues that can affect VoIP sound quality or video streaming hickups.

Sample Charts

Look at the following three charts which compare three network connections:
 
All show the results of our QoS sensor for network connections from the Amazon EC2 cloud in Europe to the clouds of Softlayer (Dallas TX), Flexiscale (UK) and newservers (Miami FL) on August 26th 2009.
  • Chart 1 - EC2 EU to Softlayer: Jitter is very good (around 10 ms), packet delay variation a little high with 50ms. And there were two short moments where reordered packets occured (at 3:30 and 18:45).
  • Chart 2 - EC2 EU to Flexiscale: Jitter is ok, PDV shows some variation during the day. But there is a notable and steady packet loss (up to 4%) which tells us that the quality of this connection is not very good.
  • Chart 3 - EC2 EU to newservers.com: Jitter (~2 ms) and PDV (~10ms) are very low and there is only one short period of packets loss at 8:45.
For a good quality we would want low measurements for jitter (<20-50ms) and PDV (<100 ms) and "zero" measurements for packet loss, duplicated and reordered packets. And the measurements should not dependent on the hour of day. In summary for our samples the connection from Amazon EC2 to Flexiscale has the lowest quality. 4% packet loss on a WAN connection is simply too much - especially since this is the shortest distance of the three samples (from Ireland to Scotland). The other two look fine.

How To Set Up Qos Sensors

Measurement takes place between two probes. So the first step is to place two PCs running a remote probe on (or near) both ends of the connection that you want to monitor (the local probe on the PC running the PRTG Core can also be used). If any firewalls, packet filters or NAT systems are en-route you must configure them as necessary so that the UDP packets can reach the target probe. In PRTG new QoS sensors must be created with a "probe device" as the parent device. The UDP packets will be sent from this probe to the target probe. During the creation of the sensor you are going to choose the target probe that the UDP packets shall be sent to for measurement. To get started right click a probe device, choose "Add Sensor" and then choose "QoS sensor" from the "Infrastructure" group. On the next web page you can configure the sensor:
 
 
Please choose a probe from the list. The list shows the probes with the IP adress that is currently used by each probe to connect to the core. Nevertheless you must enter the IP address manually because the target probe's IP from the perspective of the sending probe may be different (e.g. due to NAT). You also have to choose a UDP portnumber (please use one port number per QoS sensor). With the settings for number and for size of the packets you can configure the test data stream, 100 packets of 100 bytes is good for a start, but if your applications use larger packets you may want to enter other values here. Try to confgure this test stream with parameters similar to that of the UDP services you are using across this connection.

Why Not a VoIP Sensor

Some monitoring tool vendors call this kind of sensor a “VoIP Sensor”. VoIP has a lot to do with QoS, but also other network services are affected by bad QoS. So we call it our "QoS sensor".