Call quality metrics and MOS estimation
Verified 2026-09-24 · 60 sources · tier 1–2
Also known as MOS.
Call quality estimation relies on statistical models and transport-layer measurements to quantify speech transmission across real-time networks 1843. Standardised frameworks define computational algorithms for transmission planning and objective testing, while call platforms implement varied subsets of these metrics in production monitoring 1832489.
ITU-T standards for voice quality and MOS
ITU-T P.800 (08/96), formerly numbered P.80, serves as the in-force Recommendation for subjective determination of transmission quality 29. To eliminate ambiguity in reported values, ITU-T P.800.1 (07/16), approved on 2016-07-29, governs mean opinion score (MOS) terminology, superseding the 03/03, 07/06, and 02/16 editions 26. P.800.1 requires any MOS figure to state whether it reflects listening, talking, or conversational quality, as well as whether the value originates from subjective testing, an objective computational model, or network planning 27. P.800.1 (07/16) provides separate terminology clauses for listening-only (clause 7.1), conversational (clause 7.2), and talking (clause 7.3) situations, and also specifies terms for video (MOS-VQS, MOS-VQO, MOS-VQE) and audiovisual (MOS-AVQS, MOS-AVQO, MOS-AVQE) scores 2528.
For objective algorithmic assessment, ITU-T P.863 (POLQA) predicts overall listening speech quality from narrowband to fullband scenarios against the baseline results of P.800 or P.830 ACR listening evaluations 32. P.863 remains in force as the 03/18 edition with Amendment 1 (04/20), superseding its 2011, 2014, and 2016 editions 30. Edition 3 (03/18) removed the earlier 14 kHz low-pass filter and widened its evaluation scope to fullband codecs such as Opus and EVS 31.
The E-model and transmission planning
ITU-T positions the G.107 E-model as a transmission rating model for transmission planners, producing a scalar rating of transmission quality as its primary output 18. The current version in force is G.107 (06/15), titled 'The E-model: a computational model for use in transmission planning', superseding all editions prior to 06/15 from 12/98 through 02/14, including amendments in 2006 and 2012 1517. The E-model constructs quality estimates using transmission impairment factors designed to capture the behavior of modern signal processing hardware 16.
Over successive iterations, the E-model expanded its impairment representations:
- The 2002 edition introduced impairment caused by random packet loss, parameterised for individual codecs 12.
- The 2005 edition enhanced prediction for codecs subject to short-term dependent (bursty) packet loss 13.
- G.107 (06/15) introduced delay-sensitivity parameters, mandating default parameters for carrier-grade or enterprise-grade telephony while permitting non-default configurations for systems with low or very low interactivity requirements 14.
- G.107 (06/15) includes a reference implementation in Appendix III 19.
While G.107 provided a provisional wideband impairment structure in a 2009 Appendix II, that framework was replaced in 2011 by ITU-T G.107.1 20. In force as the 06/19 edition with Corrigendum 1 (01/20), G.107.1 supersedes the 12/11 and 06/15 releases and applies the E-model to wideband speech across 50 to 7000 Hz 1011. WarmTransfer's reading of the sources is that an R value derived from the narrowband G.107 model should not be applied unchanged to wideband codec calls, because ITU-T handles wideband in a separate Recommendation (G.107.1) 24.
For delay planning, ITU-T G.114 ('One-way transmission time') is in force as the 05/03 edition with Amendment 1 (09/03) and Amendment 2 (11/09) 22. G.114 applies an evaluation curve derived from the G.107 E-model to assess delay impacts on conversational voice 23. It advises that one-way delay should not exceed 400 ms for general network planning, noting that conversational degradation occurs at substantially lower delays 21.
Protocol-level metrics: RTP, RTCP XR, and SIP
RTP interarrival jitter is a running estimate updated per packet as J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16, where D is the difference in relative transit time between consecutive packets 43. In RTCP, this interarrival jitter field is expressed in RTP timestamp units, not milliseconds, so converting it to time requires the payload's clock rate 44. RTCP cumulative packet loss is structured as a 24-bit signed field that can be negative when more packets arrive than expected, for example because of duplicates 41. In contrast, the RTCP fraction lost field is an 8-bit fixed-point value giving the proportion of packets lost since the previous report, not since the start of the call 42.
RFC 3611 carries per-call voice quality in the VoIP Metrics Report Block, block type 7 40. RTCP XR loss rate and discard rate are 8-bit fixed-point fractions (binary point at the left edge), computed as lost or discarded packets over expected packets times 256, capped at 255 35. End system delay is a 16-bit value in milliseconds covering encoding, jitter buffer, decoding and playout delay, while round trip delay is a separate 16-bit millisecond field 34.
In RTCP XR, the R factor is an integer from 0 to 100, where 94 corresponds to toll quality, 50 or less is regarded as unusable, and 127 means unavailable 39. RTCP XR encodes MOS-LQ and MOS-CQ as integers from 10 to 50 equal to MOS times 10, with 127 meaning unavailable 38. In RFC 3611, MOS-LQ is an estimated listening-quality MOS on a 1 to 5 scale that excludes the effects of delay, whereas MOS-CQ is an estimated conversational-quality MOS that includes the effects of delay and other factors affecting conversation 3736.
For SIP architectures, RFC 6035 defines the SIP event package vq-rtcpxr with media type application/vq-rtcpxr, specifying that it SHOULD be used with SUBSCRIBE/NOTIFY and MAY be used with PUBLISH for backward compatibility 45. RFC 6035 defines three voice quality report types: VQSessionReport, VQIntervalReport and VQAlertReport 47. In RFC 6035 QualityEst, the RLQ and RCQ R-factors range 0 to 120 and MOSLQ and MOSCQ are decimal values from 0.0 to 4.9 46. WarmTransfer's reading of the sources is that a collector that ingests both RTCP XR blocks and SIP vq-rtcpxr reports cannot assume one R-factor range, because RFC 3611 bounds R at 0 to 100 and RFC 6035 allows 0 to 120 33.
Platform call quality metrics
Cisco Unified Communications Manager (CUCM)
CUCM generates CMRs according to the Call Diagnostics Enabled service parameter, whose values are Disabled, Enabled Only When CDR Enabled Flag is True, and Enabled Regardless of CDR Enabled Flag 1. CUCM writes one CMR for each IP phone involved in a call or for each MGCP gateway 2. For hold and resume on SCCP devices, CUCM generates multiple CMRs, one set per hold, so a call can carry more CMRs than one per endpoint 3. CUCM stores end-of-call audio and video metrics in CMRs for incoming and outgoing SIP trunk calls through CUBE or SIP IOS gateways 4.
CUCM CMR jitter and latency fields are expressed in milliseconds, unlike the raw RTCP jitter field, which uses timestamp units 6. CUCM CMRs do not show latency for every phone load; Cisco cites SIP phone loads 9.2.1 and 9.2.2 as not implementing it 8.
Within the varVQMetrics section of the CMR, CUCM CMR concealment metrics are CCR (cumulative concealment over speech time), ICR (concealment rate over the last 3 seconds of active speech), ICRmx (maximum), CS (concealment seconds) and SCS (severely concealed seconds) 5. CUCM documents K-factor scores as ranging from 1 (poor voice quality) to 5 (very good voice quality) 7. In CUCM CMR varVQMetrics, MLQK (MOS Listening Quality K-factor) estimates the MOS of the last 8 seconds of speech on the receive path; MLQKav, MLQKmn and MLQKmx are the running average, minimum and maximum since call start 9.
Webex Calling
Webex Calling troubleshooting in Control Hub takes jitter, packet loss and latency from each registered Webex Calling endpoint and from the media relay point in the Webex Calling cloud 58. Accessing Webex Calling troubleshooting in Control Hub requires the full admin, read-only admin or support admin role 54. Control Hub Webex Calling troubleshooting lets you view calls for the past 21 days 53. The Control Hub minute-by-minute view shows latency, packet loss, jitter and media bitrate for Webex clients and RoomOS endpoints only; PhoneOS support is described as planned 59.
In Control Hub Webex Calling troubleshooting, endpoint media quality is good when packet loss is under 5 percent, latency or RTT is under 400 ms, and jitter is under 150 ms 55. For a hop at a Webex Calling cloud media relay point, Control Hub grades quality good when packet loss is under 2.5 percent, latency or RTT under 200 ms, and jitter under 75 ms 56. WarmTransfer's reading of the sources is that the Webex Calling troubleshooting article grades quality on loss, latency and jitter thresholds and does not document a MOS value for Webex Calling calls 60.
Microsoft Teams Call Quality Dashboard (CQD)
The metrics CQD uses for classification come from a QoE report sent at the end of a call, and some third-party endpoints may not send QoE 51. Teams CQD marks an audio stream Poor when packet utilization exceeds 500 packets and any one of these holds: average round trip over 500 ms, average packet loss rate over 0.1, or average jitter over 30 ms 49. The current Teams CQD audio classifier uses only three network metrics (round trip, packet loss rate, jitter) and lists no MOS or concealment metric 48.
Microsoft states that a Poor audio classification in CQD does not mean the stream was actually poor or that the user perceived a quality problem, because the Teams media stack can mitigate degradation beyond the thresholds 50. CQD marks a stream Unclassified when ICE connectivity fails or when required metrics are missing, for example no QoE report, a short call, or low packet utilization such as a muted microphone 52.
See also
- See also Teams call quality dashboard and analytics.
- See also Webex Calling call quality troubleshooting in Control Hub.
- See also The Webex Calling Detailed Call History API.
Applicability
Applies to: ITU-T G.107, ITU-T G.107.1, ITU-T P.800, ITU-T P.800.1, ITU-T G.114, ITU-T P.863, IETF RTP, IETF RTCP XR, IETF SIP vq-rtcpxr, Microsoft Teams Call Quality Dashboard, Cisco Webex Calling (Control Hub troubleshooting), and Cisco Unified Communications Manager. Deployments: on-premises, multi-tenant, and any. Sources checked 2026-09-24. Control Hub does not provide Webex Calling media quality metrics for analog phones, IPv6 endpoints, or customers based in India 57.
What remains uncertain
Whether RFC 6035 defines unavailable or missing indicators for RLQ, RCQ, MOSLQ, or MOSCQ is not covered by the sources below. Why some third-party endpoints do not send QoE reports at the end of a call is not covered by the sources below. The schedule for PhoneOS support in the Control Hub minute-by-minute view is not covered by the sources below.
See also
Supports
- QoS marking and queuing for voice — Inbound: qos-marking supports call-quality-metrics. Marking failures show up as quality degradation
Uses
- Webex Calling call quality troubleshooting in Control Hub — Inbound: webex-calling-troubleshooting uses call-quality-metrics. Loss jitter and latency drive the quality view
Referenced by
- RingCentral call quality reportsstub — Queued 2026-10-15; Call quality metrics and MOS estimation is the nearest existing coverage
- SD-WAN considerations for voice — SD-WAN application-aware routing SLA classes use loss/latency/jitter thresholds; Webex server-side metrics feed SD-WAN Analytics
- Troubleshooting audio delay and talk-over on voice calls — Vendor RTT/jitter thresholds that grade calls
- Twilio Voice Insights call quality datastub — Queued 2026-10-14; Call quality metrics and MOS estimation is the nearest existing coverage
- WebRTC in modern contact centers — Browser agent clients expose media statistics through the W3C getStats API; Cisco documents chrome://webrtc-internals for Webex Contact Center Agent Desktop.
- Zoom Phone call quality dashboardstub — Queued 2026-10-15; Call quality metrics and MOS estimation is the nearest existing coverage
- QoS marking and queuing for voice — Marking failures show up as quality degradation
- Webex Calling call quality troubleshooting in Control Hub — Loss jitter and latency drive the quality view
Sources
- 1CUCM generates CMRs according to the Call Diagnostics Enabled service parameter, whose values are Disabled, Enabled Only When CDR Enabled Flag is True, and Enabled Regardless of CDR Enabled Flag.Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Call Management Records · Set Up CMRs · Checked 2026-09-24
- 2CUCM writes one CMR for each IP phone involved in a call or for each MGCP gateway.Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Call Management Records · CMR Processing · Checked 2026-09-24
- 3For hold and resume on SCCP devices, CUCM generates multiple CMRs, one set per hold, so a call can carry more CMRs than one per endpoint.Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Call Management Records · CMR Processing · Checked 2026-09-24
- 4CUCM stores end-of-call audio and video metrics in CMRs for incoming and outgoing SIP trunk calls through CUBE or SIP IOS gateways.Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Call Management Records · CMRs for SIP Trunks · Checked 2026-09-24
- 5CUCM CMR concealment metrics are CCR (cumulative concealment over speech time), ICR (concealment rate over the last 3 seconds of active speech), ICRmx (maximum), CS (concealment seconds) and SCS (severely concealed seconds).Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - CMR Field Descriptions · CMR field table, varVQMetrics rows CCR, ICR, ICRmx, CS, SCS · Checked 2026-09-24
- 6CUCM CMR jitter and latency fields are expressed in milliseconds, unlike the raw RTCP jitter field, which uses timestamp units.Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - CMR Field Descriptions · CMR field table, jitter and latency rows · Checked 2026-09-24
- 7CUCM documents K-factor scores as ranging from 1 (poor voice quality) to 5 (very good voice quality).Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - CMR Field Descriptions · CMR field table, varVQMetrics description · Checked 2026-09-24
- 8CUCM CMRs do not show latency for every phone load; Cisco cites SIP phone loads 9.2.1 and 9.2.2 as not implementing it.Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - CMR Field Descriptions · CMR field table, latency row note · Checked 2026-09-24
- 9In CUCM CMR varVQMetrics, MLQK (MOS Listening Quality K-factor) estimates the MOS of the last 8 seconds of speech on the receive path; MLQKav, MLQKmn and MLQKmx are the running average, minimum and maximum since call start.Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - CMR Field Descriptions · CMR field table, varVQMetrics rows MLQK, MLQKav, MLQKmn, MLQKmx · Checked 2026-09-24
- 10The wideband E-model, ITU-T G.107.1, is in force as the 06/19 edition with Corrigendum 1 (01/20); the 12/11 and 06/15 editions are superseded.G.107.1 : Wideband E-model · Recommendation listing, in-force and superseded rows · Checked 2026-09-24
- 11G.107.1 applies the E-model to wideband speech transmission covering 50 to 7000 Hz.ITU-T G.107.1 (06/2019) Summary · Summary, paragraph 1 · Checked 2026-09-24
- 12Impairment from random packet loss was added to G.107 in the 2002 edition, parameterised per codec.ITU-T G.107 (06/2015) Summary · Summary, paragraph 2, sentence on the 2002 version · Checked 2026-09-24
- 13The 2005 edition of G.107 improved quality prediction for codecs under short-term dependent (bursty) packet loss.ITU-T G.107 (06/2015) Summary · Summary, paragraph 2, sentence on the 2005 version · Checked 2026-09-24
- 14G.107 (06/15) adds delay-sensitivity parameters: carrier-grade or enterprise-grade telephony must use the defaults, while systems with low or very low interactivity requirements may use different values.ITU-T G.107 (06/2015) Summary · Summary, paragraph 2, sentences on the current version · Checked 2026-09-24
- 15The ITU-T G.107 edition in force is G.107 (06/15), titled 'The E-model: a computational model for use in transmission planning'.G.107: The E-model: a computational model for use in transmission planning (recommendation page) · Recommendation listing, in-force row G.107 (06/15) · Checked 2026-09-24
- 16The E-model is built on transmission impairment factors intended to reflect the effects of modern signal processing devices.ITU-T G.107 (06/2015) Summary · Summary, paragraph 1, last sentence · Checked 2026-09-24
- 17All G.107 editions before 06/15, from 12/98 through 02/14 including the 2006 and 2012 amendments, are marked superseded by ITU-T.G.107: The E-model: a computational model for use in transmission planning (recommendation page) · Recommendation listing, superseded rows · Checked 2026-09-24
- 18ITU-T positions the G.107 E-model as a transmission rating model for transmission planners, whose primary output is a scalar rating of transmission quality.ITU-T G.107 (06/2015) Summary · Summary, paragraph 1 · Checked 2026-09-24
- 19G.107 (06/15) includes a reference implementation of the E-model in Appendix III.ITU-T G.107 (06/2015) Summary · Summary, final sentence · Checked 2026-09-24
- 20G.107 carried a provisional wideband impairment framework in a 2009 Appendix II, which was replaced in 2011 by the separate Recommendation ITU-T G.107.1.ITU-T G.107 (06/2015) Summary · Summary, paragraph 2, sentences on the 2009 and 2011 versions · Checked 2026-09-24
- 21G.114 says one-way delay of 400 ms should not be exceeded for general network planning, while noting that interactive voice degrades at much lower delays.ITU-T G.114 (05/2003) Summary · Summary · Checked 2026-09-24
- 22ITU-T G.114 'One-way transmission time' is in force as the 05/03 edition with Amendment 1 (09/03) and Amendment 2 (11/09).G.114: One-way transmission time (recommendation page) · Recommendation listing, in-force rows · Checked 2026-09-24
- 23G.114 estimates the effect of delay on conversational speech using a curve derived from the G.107 E-model.ITU-T G.114 (05/2003) Summary · Summary · Checked 2026-09-24
- 24An R value from the narrowband G.107 model should not be applied unchanged to wideband codec calls, because ITU-T handles wideband in a separate Recommendation (G.107.1).inferredITU-T G.107 (06/2015) Summary · Summary, paragraph 2 (wideband moved to G.107.1); read with G.107.1 summary · Checked 2026-09-24
- 25P.800.1 (07/16) has separate audio MOS terminology clauses for listening-only (7.1), conversational (7.2) and talking (7.3) situations.ITU-T P.800.1 (07/2016) Table of contents · Table of contents, clause 7.1 to 7.4 · Checked 2026-09-24
- 26ITU-T P.800.1 'Mean opinion score (MOS) terminology' is in force as the 07/16 edition, approved 2016-07-29; the 03/03, 07/06 and 02/16 editions are superseded.P.800.1: Mean opinion score (MOS) terminology (recommendation page) · Recommendation listing, in-force and superseded rows · Checked 2026-09-24
- 27P.800.1 requires a MOS value to state whether it concerns listening, talking or conversational quality and whether it comes from subjective testing, an objective model or network planning.ITU-T P.800.1 (07/2016) Summary · Summary, paragraph 2 · Checked 2026-09-24
- 28P.800.1 (07/16) also defines MOS terminology for video (MOS-VQS, MOS-VQO, MOS-VQE) and audiovisual (MOS-AVQS, MOS-AVQO, MOS-AVQE) quality.ITU-T P.800.1 (07/2016) Table of contents · Table of contents, clauses 8.1 to 8.3 and 9.1 to 9.3 · Checked 2026-09-24
- 29ITU-T P.800 (08/96), 'Methods for subjective determination of transmission quality', is the in-force Recommendation for subjective testing and was formerly numbered P.80.P.800 : Methods for subjective determination of transmission quality · Recommendation listing, in-force row P.800 (08/96) · Checked 2026-09-24
- 30ITU-T P.863 'Perceptual objective listening quality prediction' (POLQA) is in force as the 03/18 edition with Amendment 1 (04/20); the 2011, 2014 and 2016 editions are superseded.P.863 : Perceptual objective listening quality prediction · Recommendation listing, in-force and superseded rows · Checked 2026-09-24
- 31P.863 edition 3 (03/18) extended scope to fullband codecs such as Opus and EVS and removed the initial 14 kHz low-pass filter.ITU-T P.863 (03/2018) Summary · Summary, edition 3 changes · Checked 2026-09-24
- 32P.863 is an objective method that predicts overall listening speech quality for narrowband through fullband scenarios, targeting the results of P.800 or P.830 ACR listening tests.ITU-T P.863 (03/2018) Summary · Summary, paragraph 1 · Checked 2026-09-24
- 33A collector that ingests both RTCP XR blocks and SIP vq-rtcpxr reports cannot assume one R-factor range, because RFC 3611 bounds R at 0 to 100 and RFC 6035 allows 0 to 120.inferredSession Initiation Protocol Event Package for Voice Quality Reporting · Section 4.6.1 ABNF, compared with RFC 3611 section 4.7.5 · Checked 2026-09-24
- 34RTCP XR end system delay is a 16-bit value in milliseconds covering encoding, jitter buffer, decoding and playout delay; round trip delay is a separate 16-bit millisecond field.RTP Control Protocol Extended Reports (RTCP XR) · Section 4.7.3, round trip delay and end system delay · Checked 2026-09-24
- 35RTCP XR loss rate and discard rate are 8-bit fixed-point fractions (binary point at the left edge), computed as lost or discarded packets over expected packets times 256, capped at 255.RTP Control Protocol Extended Reports (RTCP XR) · Section 4.7.1, loss rate and discard rate · Checked 2026-09-24
- 36RTCP XR MOS-CQ is an estimated conversational-quality MOS that includes the effects of delay and other factors affecting conversation.RTP Control Protocol Extended Reports (RTCP XR) · Section 4.7.5, MOS-CQ · Checked 2026-09-24
- 37RTCP XR MOS-LQ is an estimated listening-quality MOS on a 1 to 5 scale that excludes the effects of delay.RTP Control Protocol Extended Reports (RTCP XR) · Section 4.7.5, MOS-LQ · Checked 2026-09-24
- 38RTCP XR encodes MOS-LQ and MOS-CQ as integers from 10 to 50 equal to MOS times 10, with 127 meaning unavailable.RTP Control Protocol Extended Reports (RTCP XR) · Section 4.7.5, MOS-LQ and MOS-CQ · Checked 2026-09-24
- 39In the RTCP XR VoIP Metrics block the R factor is an integer from 0 to 100, where 94 corresponds to toll quality, 50 or less is regarded as unusable, and 127 means unavailable.RTP Control Protocol Extended Reports (RTCP XR) · Section 4.7.5, R factor · Checked 2026-09-24
- 40RTCP XR carries per-call voice quality in the VoIP Metrics Report Block, block type 7.RTP Control Protocol Extended Reports (RTCP XR) · Section 4.7 · Checked 2026-09-24
- 41The RTCP cumulative number of packets lost is a 24-bit signed field that can be negative when more packets arrive than expected, for example because of duplicates.RTP: A Transport Protocol for Real-Time Applications · Section 6.4.1, cumulative number of packets lost · Checked 2026-09-24
- 42The RTCP fraction lost field is an 8-bit fixed-point value giving the proportion of packets lost since the previous report, not since the start of the call.RTP: A Transport Protocol for Real-Time Applications · Section 6.4.1, fraction lost · Checked 2026-09-24
- 43RTP interarrival jitter is a running estimate updated per packet as J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16, where D is the difference in relative transit time between consecutive packets.RTP: A Transport Protocol for Real-Time Applications · Section 6.4.1, interarrival jitter · Checked 2026-09-24
- 44The RTCP interarrival jitter field is expressed in RTP timestamp units, not milliseconds, so converting it to time requires the payload's clock rate.RTP: A Transport Protocol for Real-Time Applications · Section 6.4.1, interarrival jitter · Checked 2026-09-24
- 45RFC 6035 defines the SIP event package vq-rtcpxr with media type application/vq-rtcpxr; it SHOULD be used with SUBSCRIBE/NOTIFY and MAY be used with PUBLISH for backward compatibility.Session Initiation Protocol Event Package for Voice Quality Reporting · Section 4 (event package definition) · Checked 2026-09-24
- 46In RFC 6035 QualityEst, the RLQ and RCQ R-factors range 0 to 120 and MOSLQ and MOSCQ are decimal values from 0.0 to 4.9.Session Initiation Protocol Event Package for Voice Quality Reporting · Section 4.6.1, ABNF ListeningQualityR, ConversationalQualityR, MOS-LQ, MOS-CQ · Checked 2026-09-24
- 47RFC 6035 defines three voice quality report types: VQSessionReport, VQIntervalReport and VQAlertReport.Session Initiation Protocol Event Package for Voice Quality Reporting · Section 4.6.1, ABNF report type names · Checked 2026-09-24
- 48The current Teams CQD audio classifier uses only three network metrics (round trip, packet loss rate, jitter) and lists no MOS or concealment metric.Stream classification in Call Quality Dashboard (CQD) · Classifier Definitions > Audio Classifier, table and note · Checked 2026-09-24
- 49Teams CQD marks an audio stream Poor when packet utilization exceeds 500 packets and any one of these holds: average round trip over 500 ms, average packet loss rate over 0.1, or average jitter over 30 ms.Stream classification in Call Quality Dashboard (CQD) · Classifier Definitions > Audio Classifier, table · Checked 2026-09-24
- 50Microsoft states that a Poor audio classification in CQD does not mean the stream was actually poor or that the user perceived a quality problem, because the Teams media stack can mitigate degradation beyond the thresholds.Stream classification in Call Quality Dashboard (CQD) · Classifier Definitions > Audio Classifier, Note · Checked 2026-09-24
- 51The metrics CQD uses for classification come from a QoE report sent at the end of a call, and some third-party endpoints may not send QoE.Stream classification in Call Quality Dashboard (CQD) · Unclassified Streams > QoE reports weren't received · Checked 2026-09-24
- 52CQD marks a stream Unclassified when ICE connectivity fails or when required metrics are missing, for example no QoE report, a short call, or low packet utilization such as a muted microphone.Stream classification in Call Quality Dashboard (CQD) · Unclassified Streams · Checked 2026-09-24
- 53Control Hub Webex Calling troubleshooting lets you view calls for the past 21 days.Troubleshoot Webex Calling calls in Control Hub · Search view / Access the Webex Calling troubleshooting view · Checked 2026-09-24
- 54Accessing Webex Calling troubleshooting in Control Hub requires the full admin, read-only admin or support admin role.Troubleshoot Webex Calling calls in Control Hub · Access the Webex Calling troubleshooting view · Checked 2026-09-24
- 55In Control Hub Webex Calling troubleshooting, endpoint media quality is good when packet loss is under 5 percent, latency or RTT is under 400 ms, and jitter is under 150 ms.Troubleshoot Webex Calling calls in Control Hub · Troubleshooting media quality issues (endpoint thresholds) · Checked 2026-09-24
- 56For a hop at a Webex Calling cloud media relay point, Control Hub grades quality good when packet loss is under 2.5 percent, latency or RTT under 200 ms, and jitter under 75 ms.Troubleshoot Webex Calling calls in Control Hub · Troubleshooting media quality issues (media relay point / hop thresholds) · Checked 2026-09-24
- 57Control Hub does not provide Webex Calling media quality metrics for analog phones, IPv6 endpoints, or customers based in India.Troubleshoot Webex Calling calls in Control Hub · Limitations · Checked 2026-09-24
- 58Webex Calling troubleshooting in Control Hub takes jitter, packet loss and latency from each registered Webex Calling endpoint and from the media relay point in the Webex Calling cloud.Troubleshoot Webex Calling calls in Control Hub · Troubleshooting media quality issues · Checked 2026-09-24
- 59The Control Hub minute-by-minute view shows latency, packet loss, jitter and media bitrate for Webex clients and RoomOS endpoints only; PhoneOS support is described as planned.Troubleshoot Webex Calling calls in Control Hub · Minute-by-minute view · Checked 2026-09-24
- 60The Webex Calling troubleshooting article grades quality on loss, latency and jitter thresholds and does not document a MOS value for Webex Calling calls.inferredTroubleshoot Webex Calling calls in Control Hub · Whole article (absence of MOS) · Checked 2026-09-24
Documents
G.107: The E-model: a computational model for use in transmission planning (recommendation page)
G.107.1 : Wideband E-model
G.114: One-way transmission time (recommendation page)
ITU-T G.107 (06/2015) Summary
ITU-T G.107.1 (06/2019) Summary
ITU-T G.114 (05/2003) Summary
ITU-T P.800.1 (07/2016) Summary
ITU-T P.800.1 (07/2016) Table of contents
ITU-T P.863 (03/2018) Summary
P.800 : Methods for subjective determination of transmission quality
P.800.1: Mean opinion score (MOS) terminology (recommendation page)
P.863 : Perceptual objective listening quality prediction
RTP Control Protocol Extended Reports (RTCP XR)
RTP: A Transport Protocol for Real-Time Applications
Session Initiation Protocol Event Package for Voice Quality Reporting
Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Call Management Records
Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - CMR Field Descriptions
Stream classification in Call Quality Dashboard (CQD)
Troubleshoot Webex Calling calls in Control Hub
Cite this page
APA
WarmTransfer. (2026, September 24). Call quality metrics and MOS estimation. WarmTransfer. https://warmtransfer.net/knowledge/call-quality-metrics
BibTeX
@misc{warmtransfer-call-quality-metrics,
title = {Call quality metrics and MOS estimation},
author = {{WarmTransfer}},
year = {2026},
url = {https://warmtransfer.net/knowledge/call-quality-metrics},
note = {Verified 2026-09-24}
}