# Call quality metrics and MOS estimation

Canonical: https://warmtransfer.net/knowledge/call-quality-metrics

Last verified: 2026-09-24

Call quality estimation relies on statistical models and transport-layer measurements to quantify speech transmission across real-time networks[^18][^43]. Standardised frameworks define computational algorithms for transmission planning and objective testing, while call platforms implement varied subsets of these metrics in production monitoring[^18][^32][^48][^9].

## 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[^25][^28].

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[^15][^17]. 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[^10][^11]. 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[^37][^36].

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](https://warmtransfer.net/knowledge/teams-call-analytics).
* See also [Webex Calling call quality troubleshooting in Control Hub](https://warmtransfer.net/knowledge/webex-calling-troubleshooting).
* See also [The Webex Calling Detailed Call History API](https://warmtransfer.net/knowledge/webex-calling-cdr).

## 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.

## Sources

[^1]: 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. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Call Management Records](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01100.html), Set Up CMRs. Checked 2026-09-24.
[^2]: CUCM writes one CMR for each IP phone involved in a call or for each MGCP gateway. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Call Management Records](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01100.html), CMR Processing. Checked 2026-09-24.
[^3]: 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. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Call Management Records](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01100.html), CMR Processing. Checked 2026-09-24.
[^4]: CUCM stores end-of-call audio and video metrics in CMRs for incoming and outgoing SIP trunk calls through CUBE or SIP IOS gateways. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - Call Management Records](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01100.html), CMRs for SIP Trunks. Checked 2026-09-24.
[^5]: 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). Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - CMR Field Descriptions](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01101.html), CMR field table, varVQMetrics rows CCR, ICR, ICRmx, CS, SCS. Checked 2026-09-24.
[^6]: CUCM CMR jitter and latency fields are expressed in milliseconds, unlike the raw RTCP jitter field, which uses timestamp units. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - CMR Field Descriptions](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01101.html), CMR field table, jitter and latency rows. Checked 2026-09-24.
[^7]: CUCM documents K-factor scores as ranging from 1 (poor voice quality) to 5 (very good voice quality). Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - CMR Field Descriptions](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01101.html), CMR field table, varVQMetrics description. Checked 2026-09-24.
[^8]: 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. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - CMR Field Descriptions](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01101.html), CMR field table, latency row note. Checked 2026-09-24.
[^9]: 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. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 15 and SUs - CMR Field Descriptions](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/15/cucm_b_reporting-billing-administration-guide-15/cucm_b_reporting-and-billing-administration-guide_chapter_01101.html), CMR field table, varVQMetrics rows MLQK, MLQKav, MLQKmn, MLQKmx. Checked 2026-09-24.
[^10]: The 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. Source: [G.107.1 : Wideband E-model](https://www.itu.int/rec/T-REC-G.107.1), Recommendation listing, in-force and superseded rows. Checked 2026-09-24.
[^11]: G.107.1 applies the E-model to wideband speech transmission covering 50 to 7000 Hz. Source: [ITU-T G.107.1 (06/2019) Summary](https://www.itu.int/dms_pubrec/itu-t/rec/g/T-REC-G.107.1-201906-I!!SUM-HTM-E.htm), Summary, paragraph 1. Checked 2026-09-24.
[^12]: Impairment from random packet loss was added to G.107 in the 2002 edition, parameterised per codec. Source: [ITU-T G.107 (06/2015) Summary](https://www.itu.int/dms_pubrec/itu-t/rec/g/T-REC-G.107-201506-I!!SUM-HTM-E.htm), Summary, paragraph 2, sentence on the 2002 version. Checked 2026-09-24.
[^13]: The 2005 edition of G.107 improved quality prediction for codecs under short-term dependent (bursty) packet loss. Source: [ITU-T G.107 (06/2015) Summary](https://www.itu.int/dms_pubrec/itu-t/rec/g/T-REC-G.107-201506-I!!SUM-HTM-E.htm), Summary, paragraph 2, sentence on the 2005 version. Checked 2026-09-24.
[^14]: G.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. Source: [ITU-T G.107 (06/2015) Summary](https://www.itu.int/dms_pubrec/itu-t/rec/g/T-REC-G.107-201506-I!!SUM-HTM-E.htm), Summary, paragraph 2, sentences on the current version. Checked 2026-09-24.
[^15]: The ITU-T G.107 edition in force is G.107 (06/15), titled 'The E-model: a computational model for use in transmission planning'. Source: [G.107: The E-model: a computational model for use in transmission planning (recommendation page)](https://www.itu.int/rec/T-REC-G.107), Recommendation listing, in-force row G.107 (06/15). Checked 2026-09-24.
[^16]: The E-model is built on transmission impairment factors intended to reflect the effects of modern signal processing devices. Source: [ITU-T G.107 (06/2015) Summary](https://www.itu.int/dms_pubrec/itu-t/rec/g/T-REC-G.107-201506-I!!SUM-HTM-E.htm), Summary, paragraph 1, last sentence. Checked 2026-09-24.
[^17]: All G.107 editions before 06/15, from 12/98 through 02/14 including the 2006 and 2012 amendments, are marked superseded by ITU-T. Source: [G.107: The E-model: a computational model for use in transmission planning (recommendation page)](https://www.itu.int/rec/T-REC-G.107), Recommendation listing, superseded rows. Checked 2026-09-24.
[^18]: ITU-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. Source: [ITU-T G.107 (06/2015) Summary](https://www.itu.int/dms_pubrec/itu-t/rec/g/T-REC-G.107-201506-I!!SUM-HTM-E.htm), Summary, paragraph 1. Checked 2026-09-24.
[^19]: G.107 (06/15) includes a reference implementation of the E-model in Appendix III. Source: [ITU-T G.107 (06/2015) Summary](https://www.itu.int/dms_pubrec/itu-t/rec/g/T-REC-G.107-201506-I!!SUM-HTM-E.htm), Summary, final sentence. Checked 2026-09-24.
[^20]: G.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. Source: [ITU-T G.107 (06/2015) Summary](https://www.itu.int/dms_pubrec/itu-t/rec/g/T-REC-G.107-201506-I!!SUM-HTM-E.htm), Summary, paragraph 2, sentences on the 2009 and 2011 versions. Checked 2026-09-24.
[^21]: G.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. Source: [ITU-T G.114 (05/2003) Summary](https://www.itu.int/dms_pubrec/itu-t/rec/g/T-REC-G.114-200305-I!!SUM-HTM-E.htm), Summary. Checked 2026-09-24.
[^22]: 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). Source: [G.114: One-way transmission time (recommendation page)](https://www.itu.int/rec/T-REC-G.114), Recommendation listing, in-force rows. Checked 2026-09-24.
[^23]: G.114 estimates the effect of delay on conversational speech using a curve derived from the G.107 E-model. Source: [ITU-T G.114 (05/2003) Summary](https://www.itu.int/dms_pubrec/itu-t/rec/g/T-REC-G.114-200305-I!!SUM-HTM-E.htm), Summary. Checked 2026-09-24.
[^24]: An 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) (inferred). Source: [ITU-T G.107 (06/2015) Summary](https://www.itu.int/dms_pubrec/itu-t/rec/g/T-REC-G.107-201506-I!!SUM-HTM-E.htm), Summary, paragraph 2 (wideband moved to G.107.1); read with G.107.1 summary. Checked 2026-09-24.
[^25]: P.800.1 (07/16) has separate audio MOS terminology clauses for listening-only (7.1), conversational (7.2) and talking (7.3) situations. Source: [ITU-T P.800.1 (07/2016) Table of contents](https://www.itu.int/dms_pubrec/itu-t/rec/p/T-REC-P.800.1-201607-I!!TOC-HTM-E.htm), Table of contents, clause 7.1 to 7.4. Checked 2026-09-24.
[^26]: ITU-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. Source: [P.800.1: Mean opinion score (MOS) terminology (recommendation page)](https://www.itu.int/rec/T-REC-P.800.1), Recommendation listing, in-force and superseded rows. Checked 2026-09-24.
[^27]: P.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. Source: [ITU-T P.800.1 (07/2016) Summary](https://www.itu.int/dms_pubrec/itu-t/rec/p/T-REC-P.800.1-201607-I!!SUM-HTM-E.htm), Summary, paragraph 2. Checked 2026-09-24.
[^28]: P.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. Source: [ITU-T P.800.1 (07/2016) Table of contents](https://www.itu.int/dms_pubrec/itu-t/rec/p/T-REC-P.800.1-201607-I!!TOC-HTM-E.htm), Table of contents, clauses 8.1 to 8.3 and 9.1 to 9.3. Checked 2026-09-24.
[^29]: ITU-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. Source: [P.800 : Methods for subjective determination of transmission quality](https://www.itu.int/rec/T-REC-P.800), Recommendation listing, in-force row P.800 (08/96). Checked 2026-09-24.
[^30]: ITU-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. Source: [P.863 : Perceptual objective listening quality prediction](https://www.itu.int/rec/T-REC-P.863), Recommendation listing, in-force and superseded rows. Checked 2026-09-24.
[^31]: P.863 edition 3 (03/18) extended scope to fullband codecs such as Opus and EVS and removed the initial 14 kHz low-pass filter. Source: [ITU-T P.863 (03/2018) Summary](https://www.itu.int/dms_pubrec/itu-t/rec/p/T-REC-P.863-201803-I!!SUM-HTM-E.htm), Summary, edition 3 changes. Checked 2026-09-24.
[^32]: P.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. Source: [ITU-T P.863 (03/2018) Summary](https://www.itu.int/dms_pubrec/itu-t/rec/p/T-REC-P.863-201803-I!!SUM-HTM-E.htm), Summary, paragraph 1. Checked 2026-09-24.
[^33]: 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 (inferred). Source: [Session Initiation Protocol Event Package for Voice Quality Reporting](https://www.rfc-editor.org/rfc/rfc6035.html), Section 4.6.1 ABNF, compared with RFC 3611 section 4.7.5. Checked 2026-09-24.
[^34]: RTCP 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. Source: [RTP Control Protocol Extended Reports (RTCP XR)](https://www.rfc-editor.org/rfc/rfc3611.html), Section 4.7.3, round trip delay and end system delay. Checked 2026-09-24.
[^35]: 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. Source: [RTP Control Protocol Extended Reports (RTCP XR)](https://www.rfc-editor.org/rfc/rfc3611.html), Section 4.7.1, loss rate and discard rate. Checked 2026-09-24.
[^36]: RTCP XR MOS-CQ is an estimated conversational-quality MOS that includes the effects of delay and other factors affecting conversation. Source: [RTP Control Protocol Extended Reports (RTCP XR)](https://www.rfc-editor.org/rfc/rfc3611.html), Section 4.7.5, MOS-CQ. Checked 2026-09-24.
[^37]: RTCP XR MOS-LQ is an estimated listening-quality MOS on a 1 to 5 scale that excludes the effects of delay. Source: [RTP Control Protocol Extended Reports (RTCP XR)](https://www.rfc-editor.org/rfc/rfc3611.html), Section 4.7.5, MOS-LQ. Checked 2026-09-24.
[^38]: RTCP XR encodes MOS-LQ and MOS-CQ as integers from 10 to 50 equal to MOS times 10, with 127 meaning unavailable. Source: [RTP Control Protocol Extended Reports (RTCP XR)](https://www.rfc-editor.org/rfc/rfc3611.html), Section 4.7.5, MOS-LQ and MOS-CQ. Checked 2026-09-24.
[^39]: In 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. Source: [RTP Control Protocol Extended Reports (RTCP XR)](https://www.rfc-editor.org/rfc/rfc3611.html), Section 4.7.5, R factor. Checked 2026-09-24.
[^40]: RTCP XR carries per-call voice quality in the VoIP Metrics Report Block, block type 7. Source: [RTP Control Protocol Extended Reports (RTCP XR)](https://www.rfc-editor.org/rfc/rfc3611.html), Section 4.7. Checked 2026-09-24.
[^41]: The 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. Source: [RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550.html), Section 6.4.1, cumulative number of packets lost. Checked 2026-09-24.
[^42]: 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. Source: [RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550.html), Section 6.4.1, fraction lost. Checked 2026-09-24.
[^43]: 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. Source: [RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550.html), Section 6.4.1, interarrival jitter. Checked 2026-09-24.
[^44]: The RTCP interarrival jitter field is expressed in RTP timestamp units, not milliseconds, so converting it to time requires the payload's clock rate. Source: [RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550.html), Section 6.4.1, interarrival jitter. Checked 2026-09-24.
[^45]: RFC 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. Source: [Session Initiation Protocol Event Package for Voice Quality Reporting](https://www.rfc-editor.org/rfc/rfc6035.html), Section 4 (event package definition). Checked 2026-09-24.
[^46]: 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. Source: [Session Initiation Protocol Event Package for Voice Quality Reporting](https://www.rfc-editor.org/rfc/rfc6035.html), Section 4.6.1, ABNF ListeningQualityR, ConversationalQualityR, MOS-LQ, MOS-CQ. Checked 2026-09-24.
[^47]: RFC 6035 defines three voice quality report types: VQSessionReport, VQIntervalReport and VQAlertReport. Source: [Session Initiation Protocol Event Package for Voice Quality Reporting](https://www.rfc-editor.org/rfc/rfc6035.html), Section 4.6.1, ABNF report type names. Checked 2026-09-24.
[^48]: The current Teams CQD audio classifier uses only three network metrics (round trip, packet loss rate, jitter) and lists no MOS or concealment metric. Source: [Stream classification in Call Quality Dashboard (CQD)](https://learn.microsoft.com/en-us/microsoftteams/stream-classification-in-call-quality-dashboard), Classifier Definitions > Audio Classifier, table and note. Checked 2026-09-24.
[^49]: 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. Source: [Stream classification in Call Quality Dashboard (CQD)](https://learn.microsoft.com/en-us/microsoftteams/stream-classification-in-call-quality-dashboard), Classifier Definitions > Audio Classifier, table. Checked 2026-09-24.
[^50]: 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. Source: [Stream classification in Call Quality Dashboard (CQD)](https://learn.microsoft.com/en-us/microsoftteams/stream-classification-in-call-quality-dashboard), Classifier Definitions > Audio Classifier, Note. Checked 2026-09-24.
[^51]: 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. Source: [Stream classification in Call Quality Dashboard (CQD)](https://learn.microsoft.com/en-us/microsoftteams/stream-classification-in-call-quality-dashboard), Unclassified Streams > QoE reports weren't received. Checked 2026-09-24.
[^52]: 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. Source: [Stream classification in Call Quality Dashboard (CQD)](https://learn.microsoft.com/en-us/microsoftteams/stream-classification-in-call-quality-dashboard), Unclassified Streams. Checked 2026-09-24.
[^53]: Control Hub Webex Calling troubleshooting lets you view calls for the past 21 days. Source: [Troubleshoot Webex Calling calls in Control Hub](https://help.webex.com/en-us/article/frj1efb/Troubleshoot-Webex-Calling-Media-Quality-in-Control-Hub), Search view / Access the Webex Calling troubleshooting view. Checked 2026-09-24.
[^54]: Accessing Webex Calling troubleshooting in Control Hub requires the full admin, read-only admin or support admin role. Source: [Troubleshoot Webex Calling calls in Control Hub](https://help.webex.com/en-us/article/frj1efb/Troubleshoot-Webex-Calling-Media-Quality-in-Control-Hub), Access the Webex Calling troubleshooting view. Checked 2026-09-24.
[^55]: 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. Source: [Troubleshoot Webex Calling calls in Control Hub](https://help.webex.com/en-us/article/frj1efb/Troubleshoot-Webex-Calling-Media-Quality-in-Control-Hub), Troubleshooting media quality issues (endpoint thresholds). Checked 2026-09-24.
[^56]: 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. Source: [Troubleshoot Webex Calling calls in Control Hub](https://help.webex.com/en-us/article/frj1efb/Troubleshoot-Webex-Calling-Media-Quality-in-Control-Hub), Troubleshooting media quality issues (media relay point / hop thresholds). Checked 2026-09-24.
[^57]: Control Hub does not provide Webex Calling media quality metrics for analog phones, IPv6 endpoints, or customers based in India. Source: [Troubleshoot Webex Calling calls in Control Hub](https://help.webex.com/en-us/article/frj1efb/Troubleshoot-Webex-Calling-Media-Quality-in-Control-Hub), Limitations. Checked 2026-09-24.
[^58]: 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. Source: [Troubleshoot Webex Calling calls in Control Hub](https://help.webex.com/en-us/article/frj1efb/Troubleshoot-Webex-Calling-Media-Quality-in-Control-Hub), Troubleshooting media quality issues. Checked 2026-09-24.
[^59]: 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. Source: [Troubleshoot Webex Calling calls in Control Hub](https://help.webex.com/en-us/article/frj1efb/Troubleshoot-Webex-Calling-Media-Quality-in-Control-Hub), Minute-by-minute view. Checked 2026-09-24.
[^60]: The Webex Calling troubleshooting article grades quality on loss, latency and jitter thresholds and does not document a MOS value for Webex Calling calls (inferred). Source: [Troubleshoot Webex Calling calls in Control Hub](https://help.webex.com/en-us/article/frj1efb/Troubleshoot-Webex-Calling-Media-Quality-in-Control-Hub), Whole article (absence of MOS). Checked 2026-09-24.