Call quality monitoring

Link copied to clipboard

Administrators can monitor the quality of customers’ calls by using a set of metrics. In so doing, they can identify and fix network issues (e.g., congestion) and analyze how network configuration changes influence call quality. This helps CSPs and resellers meet their customers’ expectations about the quality of service according to the SLA (Service License Agreement).

Call quality is determined by these metrics:

  • Latency – the delay in voice packet delivery from source to destination;
  • Jitter – the variability in time it takes for voice packets to reach their destination;
  • Packet loss – the number of voice packets not received by the destination;
  • MOS (Mean Opinion Score) – the average rating of voice quality on a scale from 1 to 5, where 5 indicates the highest quality.

PortaSIP collects metrics during or at the end of customers’ calls. This depends on their phone configurations. PortaBilling analyzes the collected data and determines the call status: good, fair or poor. An administrator sees the call status in the customer’s xDRs. Call quality details for the call participants are available in the xDR details.

Let’s have a closer look at how it works.

Metrics collection

Link copied to clipboard

Call quality values are sent in RTCP (Real-Time Transport Control Protocol) messages:

  • receiver reports (RTCP RR), and
  • extended reports (RTCP XR).

RTCP XR reports contain a wider set of quality parameters (e.g., packet loss rate, delay, MOS, etc.). However, user phones must support RTCP XR reports according to RFC 3611 and be configured to send them.

RTCP collection flow

After a call is established, user phones exchange the media stream via the RTPProxy. They also send RTCP RR/RTCP XR reports to the RTPProxy, which passes them on to the Call quality tracker. The Call quality tracker is the PortaSIP component that retrieves metrics values from the RTCP RR/RTCP XR messages, aggregates them and records them in the database.

User phones can also send aggregated call quality values at the end of the call if they support call quality summary reports according to RFC 6035.  At the end of the call, PortaSIP receives these summary reports in PUBLISH messages and passes them to the Call quality tracker. The Call quality tracker processes them in the same way: extracts the metrics and records them in the database. The metrics from the summary reports take precedence over those collected from the RTCP RR/RTCP XR reports.

Call status identification

Link copied to clipboard

A call can have a status of good, fair or poor. The criteria for call statuses are defined in call quality profiles. A call quality profile includes thresholds for call quality metrics that describe each call status. An administrator configures a call quality profile and assigns it to customers/customer sites whose call quality they wish to monitor (e.g., business or premium customers). PortaBilling sets call statuses only for customers who have assigned call quality profiles.

quality thresholds definition

To determine the status of calls, PortaBilling retrieves metrics values from the Call quality tracker every 10 minutes. PortaBilling matches the metrics values against the thresholds in a customer’s call quality profile and then sets the call status based on the worst metric value. The resulting call status is identified by the color indicator in the customer’s xDRs:

  • Green for good quality Green for good quality;
  • Yellow for fair quality Yellow for fair quality;
  • Red for poor quality Red for poor quality.
  • No indicator means that either there is not yet a call quality status or a call quality profile is not assigned to the customer.

call quality details

The administrator can view metrics values for call participants in the xDR details. They can also filter xDRs by call quality status for further analysis.

Resellers can configure call quality profiles and receive call quality details for their customers via the API.

Call quality monitoring is supported for calls made within the network, to/from external numbers and “complex calls” such as those that involve forwarding, call transfer, call pickup, etc.

With this ability to monitor call quality, administrators can:

  • Analyze current quality and take actions to improve it;
  • Identify network issues and fix them;
  • Analyze how network configuration changes influence call quality;
  • Retrieve call quality statistics via the API to create reports in external systems.

End users receive better service quality due to proactive administrators.

Implementation specifics:

Link copied to clipboard
  1. To process call quality metrics from RTCP RR/RTCP XR reports, the media stream between the phones must pass through the RTPProxy. This is not required if the phones send call quality summary reports in SIP PUBLISH messages. PortaSIP receives these summary reports through the Subscription manager.
  2. The Call quality tracker instance is required to process RTCP RR/RTCP XR and call quality summary reports. You can deploy it on any SIP server. The Call quality tracker must reside on the private IP. Only one instance of call quality tracker per PortaSIP is allowed.
  3. PortaBilling retrieves metrics from the Call quality tracker every 10 minutes. Therefore, call status is not displayed immediately after call termination.
  4. PortaBilling queries the replica database to show the metrics in the xDR browser. This imposes an additional load on the database.
  5. A change of metrics thresholds in call quality profiles, as well as profile changes for customers, is not recorded. Thus, if such a change takes place before PortaBilling retrieves the metrics, PortaBilling uses the new settings to determine the call statuses.

Known limitations

Link copied to clipboard

The xDRs for inter-site calls and for complex calls such as call forwarding, call transfer, etc. provide call quality details for one call participant only – the one whose xDR you are viewing. Therefore, to obtain full quality information about a call, you must view call quality details in the xDRs for each call participant.

On this page