RTP statistics

The RTP statistics shows the complete list of all RTP traffic and a distribution of the used codecs.

Meaning of measured values

• Packet loss: This is the number of RTP packets that have not been seen, according to the RTP sequence counter.
• Double packet: The number of duplicate packets for which the RTP sequence counter is identical.
• Jitter: This value models the difference of seen arrival time vs. expected arrival time based on the RTP timestamp. It is calculated according to the RTP RFC 3550.
• Jitter buffer exceeded: This the amount of packets within time windows for which the jitter is above a configured jitter buffer threshold. The threshold can be configured in SIP module settings.
• Packet time delta: The is the arrival time delta value between two consecutive packets. Large value does not necessarily indicate a problem as there could be a silence or no video changes. In other cases, like constant video or audio streams, large values might indicate network delays.
• Clock skew: The clock skew is the difference of arrival time of two packets minus the difference of RTP timestamp (in relation to the clock rate). This value is taken into account for jitter calculation, but also gives indication about possible problem as an isolated value. A large clock skew can happen because of an unstable source clock which can result in dropped audio or video frames. A large clock skew can also happen by a network delay. The arrival time difference will be much higher than the initial send time difference. The former type of error can often be detected by checking if the skew remains positive or negative. If so, the clock is unstable. If not, it could be more likely a network delay. In this case, the clock skew "heals" shortly afterwards when delayed packets arrive in bursts faster than initially sent. Be aware, that the calculation assume a correct clock rate. For many codecs, the clock rate is fixed, for others the clock rate is estimated based on the timing of the packets at the beginning of the connection. If the clock rate is estimated wrongly, there will always be a positive or negative clock skew. But individual events of large clock skew changes are still detectable.
• Max video frame duration: This value measures the duration of video frames sent by multiple packets. It is the arrival time between the first frame fragment and the last frame fragment. Usually the frame data is given to the operating system to send out individual UDP packets as fast as possible. So large frame durations indicate possible network delays or bottlenecks.

IP addresses

This tab provides an overview of all IP addresses with RTP traffic.

RTP overview

For each IP (see Common table columns - IP) traffic counters are displayed for receive and transmit direction of that IP. Packet loss counters, jitter and packet time delta are also shown.

The available statistics of the graph column (see Common table columns - Graph) are:

• traffic as bit rate or packet rate
• lost and overhead packets
• jitter, jitter buffer exceeded
• packet time delta
• clock skew
• video frame duration

By clicking on RTP statistics, the RTP statistics tab of the IP detail page is shown.

IP groups

This tab shows similar information as the IP addresses tab, but for IP groups instead.

RTP connections

This tab shows statistics (if available) of all RTP connections.

RTP connections

A list shows all connections with client and server IP addresses and ports. The RTP payload type is shown as well as timing information and counters, jitter, packet time delta, MOS and R values and SSRC (synchronization source) of both client and server. The min and max audio levels (decibel relative to full scale, dBFS) per direction are shown if G.711 A-Law or μ-Law is used. For calculation, raw A-Law or μ-Law values are converted to 16 bit PCM values. Those values are then converted to dbFS:

 value_dBFS = 20 * log10(abs(pcm_value) / 32768)
 Values range from 0 dBFS (loudest) to -96 dBFS (absolute silence).

Graphs per connection can show packets, packet loss and packet duplication, bit rate, jitter, packet time delta, MOS and the max audio level of client and server over time. A PCAP button allows for PCAP capturing. If a proper codec is used, audio capture buttons for both directions are available allowing downloads in MP3 format. Following codecs are supported for audio extraction:

• G.711 A-Law and μ-Law
• G.722
• G.729

RTP codecs

The RTP codecs tab shows the distribution of the used codecs.

RTP codecs

For each codec, the table contains the following information:

• Codec

The Codec name describes the format of the RTP payload.

• Packets and Bytes

This is the number of packets and bytes for that codec. It includes both sent and received bytes.

• Packets/s and Bits/s

These both numbers describe the current throughput for that codec.

• Graph

The graph column shows the history graph of the traffic for that codec. It shows the timestamp on the x-axis and the bytes on the y-axis. The resolution can be changed by using the control buttons on the top of the web page.

• PCAP

It is possible to download the traffic for that codec by clicking on the download button.

The captured packets are not stored on the system but they are directly sent over the HTTP connection to your computer.

To stop capture, click on the same button again (which turned to a STOP symbol), or go to the capture traffic.

RTP overall quality

The RTP overall quality tab provides graphs about the jitter and packet loss.

RTP overall quality

There one graph for the overall jitter and packet loss. Additionally, there is a separate graph per network interface. The jitter is calculated according to RFC 3550 Appendix A.8 (https://tools.ietf.org/html/rfc3550#appendix-A.8). The packet loss graph displays the percentage of lost packets to expected packets based on the sequence number in the RTP packets. If, for a given RTP flow, 40 packets were received, but the last sequence number (relative to the start of the flow) is 50, 10 packets were lost. This means there is a packet loss of 20%.

Incidents

The incidents tab allows to configure and display custom events. Configuration is done on a separate page, which can be accessed by clicking on the Configure incidents button. A list of already triggered incidents is shown in a table, providing information on severity of the incident, the time of first occurrence and the reason for triggering. Filters can be used to show only incidents of certain severity levels (low, medium, high) or incident trigger type.