VoIP Module
  • 23 Mar 2022
  • 5 Minutes to read
  • Contributors
  • Dark
    Light
  • PDF

VoIP Module

  • Dark
    Light
  • PDF

Article Summary

Overview

A specific reporting for Voice over IP traffic is provided. The aim of this article is to show the volume and quality of service associated with VoIP flows.

Basics of VoIP

Voice over IP relies on three protocols to operate over IP networks:

  • Signalization protocol: the role of this protocol is to establish and control the voice communications. It usually consists of communications between the IP phone and a call manager / IPBX. The two signalization protocols supported are SIP (Session Initiation Protocol) and MGCP (Media Gateway Control Protocol). Please note that SIP may or may not follow the same route as the RTP traffic, while MGCP follows the same route as RTP (Real-Time Protocol).
  • Media protocol: the role of this protocol is to carry the voice signal from one IP phone to another one (it can eventually pass through the call manager / IPBX). RTP is the only media protocol supported by SkyLIGHT sensor: capture Functional Configuration
  • Control protocol: the role of this protocol is to carry quality and control information from one phone to the other. RTCP (Real Time Control Protocol) is the only control protocol supported.

Quality of Service & MOS

Mean Opinion Score (MOS) is a numeric indication of the perceived quality of service of VoIP. It ranges from 1 to 5 with 1 corresponding to the lowest quality and 5 to the highest (close to human voice).

MOS RatingMeaning
5Excellent
4Good
3Fair
2Poor
1Bad

Please note that in a real network, a MOS of over 4.4 is unachievable. A low MOS will translate into an echo and degraded signal. MOS is, in principle, the result of a series of subjective tests; in the context of network analysis, MOS will be estimated using a formula that integrates 3 factors:

  • Network latency (RTT recommended value: <100ms)
  • Jitter (recommended value: <30ms)
  • Packet loss rate (recommended value: <5%)

Prerequisites

To provide MOS values for VoIP traffic, it is necessary to capture the three flows: signalization (SIP or MGCP), media (RTP) and control protocol (RTCP). If one of these flows is absent in the traffic capture brought to the listening interface(s), the MOS value will not be calculated. Other quality-of-service metrics will remain available.

ProtocolMetrics obtained by analysis of the protocol
SIP/MGCP
  • Sign. RTT (network latency between each phone – value in and out interval between a request and the first response (definitive or temporary) from the signalization server)
  • Sign. SRT (signalization server response time)
  • Sign. RD (retransmission delay for the signalization traffic)
  • Sign. RR (retransmission rate for the signalization traffic)
  • Code (indicates how the VoIP call ended – e.g., error or not; please note that the code depends on the protocol used)
RTP
  • Jitter (standard deviation of latency for the media traffic going from one IP phone to the other)
  • Packet loss (percentage of packets lost in the conversation at the point of capture of the probe - based on RTP sequence numbers)
RTCPRTT (network latency between the two IP phones – based on the timestamps provided by both IP phones)


Note: RTT and MOS values depend on, to some extent, the quality of the measurement provided by RTCP. Please note that MOS is not very sensitive to “normal” latency values. When referring to voice or media, we refer to the RTP traffic, which may correspond to different things (human voice, prerecorded message, ringback tone, busy line tone, etc.) The VoIP module discards the jitter and packet loss data present in the RTCP flow and replaces them with equivalent values computed internally. This is so for several reasons:

  • It was observed that many softphones do not place accurate (or even credible) values in these fields;
  • RTCP stream is more often missing than present, probably because it is firewalled and of little use to the VoIP client software.

For the VoIP module to remain passive, there is no other option than to compute these values for every RTP stream to generate jitter and packet loss values which will be a good estimate of the real jitter and loss experienced by both users. This is how, even in the absence of RTCP stream, we can display a jitter and packet loss count (and no RTT, and, thus, no MOS).


VoIP Views

MOS Over Time

This view shows the evolution of the Mean Opinion Score through time. A second graph shows the evolution of the number of calls to help you evaluate how many were impacted by a MOS degradation.

  • By hovering over a specific point in time on the graph, you can display the exact value for each metric on the right side of the graph.
  • By clicking on a specific point in time, you are directed to the VoIP conversations for that time interval.

Jitter / Packet Loss

This view shows the evolution through time of the jitter and the packet loss. This view can help you understand MOS variations and see which metric is impacting the MOS.

  • By pointing a specific point of time on the graph, you can display the exact value for each metric on the right side of the graph.
  • By clicking on a specific point of time, you are directed to the VoIP conversations for this point of time.

VoIP Bandwidth & Call Volume

These views show charts for:

  • the bandwidth used for voice and signalization.

18.png

  • the evolution of the volume of calls through time. Calls are distributed between successful and unsuccessful calls. Successful calls are conversations where some voice was exchanged; unsuccessful calls are conversations without any voice exchanged.
    19.png

VoIP Conversations & Details

The last two views show each call individually with some usage metrics for VoIP Conversations. The VoIP Flow Details view is the same table with the addition of performance metrics.


Note: The “caller” value corresponds to the metric for the RTP/RTCP traffic from the caller to the callee, while the “callee” value corresponds to the metric for the RTP/RTCP traffic from the callee to the caller.

© 2024 Accedian Networks Inc. All rights reserved. Accedian®, Accedian Networks®,  the Accedian logo™, Skylight™, Skylight Interceptor™ and per-packet intel™, are trademarks or registered trademarks of Accedian Networks Inc. To view a list of Accedian trademarks visit: http://accedian.com/legal/trademarks/. 


Was this article helpful?

Changing your password will log you out immediately. Use the new password to log back in.
First name must have atleast 2 characters. Numbers and special characters are not allowed.
Last name must have atleast 1 characters. Numbers and special characters are not allowed.
Enter a valid email
Enter a valid password
Your profile has been successfully updated.