PRTG Manual: Monitoring Quality of Service and VoIP

PRTG can monitor the Quality of Service in a network with dedicated QoS sensors, as well as Cisco IP Service Level Agreement (SLA) and Cisco Class Based Quality of Service (CBQoS). Slight variations of network parameters like jitter, packet loss, or packet delay variation (PDV) usually have only little effect on TCP based services (e.g. HTTP, SMTP, etc.). But for UDP based services like Voice over IP (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, or if packets are lost or out-of-order. As a rule of thumb for good quality of service (in a VoIP perspective) you would want low measurements for jitter (less than 20 to 50 ms) and PDV (less than 100 ms) and preferably zero measurements for packet loss, duplicated packets, or packets in wrong order.

For Quality of Service measurements, four sensors are available:

QoS (Quality of Service) Sensor

The QoS Sensor is used to monitor the quality of a network connection by measuring the following parameters:

  • Jitter in ms according to RFC 3550
  • Packet delay variation (PDV) in ms according to RFC 3393
  • Lost packets in %
  • Out-of-order packets in %
  • Duplicated packets in %

The measurements are taken by sending UDP packets between two 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 'hiccups'.

Monitoring Quality of Service with PRTG

Monitoring Quality of Service with PRTG

As mentioned before, measurements are taken 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. As an alternative, the local probe on the PC running the PRTG core can also be used as one end. If any firewalls, packet filters or Network Address Translation (NAT) systems are en route, you must configure them as necessary so that the UDP packets can reach the target probe.

In PRTG, create a new QoS sensor on a Probe Device. Please find details about settings in the QoS (Quality of Service) Sensor section. With the settings for number and for size of the packets you can configure the test data stream. 1,000 packets of 172 bytes each is a good start, but if your applications use larger packets you may want to enter other values here. Try to configure the test streams with parameters similar to that of the UDP services you are using across this connection.

Cisco IP SLA Sensor

Wikipedia describes IP SLA as a feature included in the Cisco IOS Software that can allow administrators the ability to Analyze IP Service Levels for IP applications and services. IP SLA uses active traffic-monitoring technology to monitor continuous traffic on the network. This is a reliable method in measuring over head network performance. IP-SLA is mostly used to monitor the sound quality of VoIP traffic.

If you haven't done so already, please add a device in PRTG for the Cisco device that you want to monitor. Then create a new Cisco IP SLA sensor on this device. Please find details about settings in the Cisco IP SLA Sensor section.

This feature is only available in the more expensive Cisco devices. If you don't have IP SLA capable routers/switches you can still get similar information with PRTG's QoS sensor (see above) which does not require any special hardware—just two PCs running Windows. If you do own hardware which supports IP SLA then PRTG brings you probably the least-cost monitoring solution for IP SLA. Most vendors charge extra for IP SLA support (a thousand bucks and more). Following Paessler's long term policy we simply include this as one of our sensor types. With PRTG you can even use the Freeware Edition to monitor IP SLA!

PRTG monitors the following parameters: Calculated Planning Impairment Factor (ICPIF), Mean Opinion Score (MOS), Average Jitter, Packets Lost, Packets Out Of Sequence, Packets Late, Average Round Trip Time (RTT), DNS RTT, TCP RTT, Transaction RTT. Especially two of these parameters are interesting for VoIP: Mean Opinion Score (MOS) and Calculated Planning Impairment Factor (ICPIF).

SNMP Cisco CBQoS Sensor

Cisco Class Based Quality of Service (CBQoS) provides information about QoS of Cisco network devices which support the Modular QoS command line interface (MQC). With Classed Based QoS, you can obtain monitoring data that includes summary counts and rates by traffic class before and after the enforcement of QoS policies, according to Cisco's CBQoS Management Information Base (MIB) definition. PRTG determines CBQoS data via Simple Network Management Protocol (SNMP). The corresponding sensor type is available out-of-the-box in PRTG version 13.x.5 or later. CBQoS is available in Cisco IOS by default as of version 12.4(4)T.

In order to monitor CBQoS, add a device to PRTG for the Cisco device that you want to monitor. Then create a new SNMP Cisco CBQoS sensor on this device. Please see section SNMP Cisco CBQoS Sensor for more details.

This sensor type supports the following CBQoS classes:

  • Class Map: statistical data about class maps, such as pre- and post-policy packets and sizes, drop packets and size, as well as no-buffer drop packets
  • Match Statement: statistical data about match statement specific information, such as pre-policy packets and size
  • Queueing: statistical data about queuing actions, such as current and maximum queue depth, drop packets, and drop size

You can select the desired CBQoS entries which you want to monitor while creating the sensor in PRTG. The available entries are given with their particular connections, their descriptions, and class types.

Voice over IP

For Mean Opinion Score (MOS) measurements, Cisco conducted a panel test where a wide range of listeners judged the quality of voice samples sent using particular codecs, on a scale of 1 (poor quality) to 5 (excellent quality). The Cisco device calculated the corresponding value for the current network connection based on the network parameter measurements like jitter and packet loss. The values and their meanings are:



Expected Quality Impairment






Perceptible, but not annoying



Slightly annoying






Very annoying

The second interesting parameter ICPIF is the sum of measured impairment factors minus a user-defined access Advantage Factor that is intended to represent the user's expectations, based on how the call was placed (for example, a mobile call versus a land-line call) (quoted from Cisco's website).

Upper Limit for ICPIF

VoIP Call Communication Quality


Very good






Limiting case


Exceptional limiting case


Customers likely to react strongly (complaints, change of network operator)


Paessler Knowledge Base: Where can I find more information about Cisco IP SLAs, VoIP, and QoS?



Sensor Technologies—Topics


Keywords: VoIP,VoIP Technology