cdr analytics · published

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

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

Uses

Referenced by

Sources

  1. 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.
  2. 2
    CUCM writes one CMR for each IP phone involved in a call or for each MGCP gateway.
  3. 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.
  4. 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.
  5. 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).
  6. 6
    CUCM CMR jitter and latency fields are expressed in milliseconds, unlike the raw RTCP jitter field, which uses timestamp units.
  7. 7
    CUCM documents K-factor scores as ranging from 1 (poor voice quality) to 5 (very good voice quality).
  8. 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.
  9. 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.
    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
  10. 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.
    G.107.1 : Wideband E-model · Recommendation listing, in-force and superseded rows · Checked 2026-09-24
  11. 11
    G.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
  12. 12
    Impairment 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
  13. 13
    The 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
  14. 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.
    ITU-T G.107 (06/2015) Summary · Summary, paragraph 2, sentences on the current version · Checked 2026-09-24
  15. 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'.
    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
  16. 16
    The 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
  17. 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.
    G.107: The E-model: a computational model for use in transmission planning (recommendation page) · Recommendation listing, superseded rows · Checked 2026-09-24
  18. 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.
    ITU-T G.107 (06/2015) Summary · Summary, paragraph 1 · Checked 2026-09-24
  19. 19
    G.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
  20. 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.
    ITU-T G.107 (06/2015) Summary · Summary, paragraph 2, sentences on the 2009 and 2011 versions · Checked 2026-09-24
  21. 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.
    ITU-T G.114 (05/2003) Summary · Summary · Checked 2026-09-24
  22. 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).
    G.114: One-way transmission time (recommendation page) · Recommendation listing, in-force rows · Checked 2026-09-24
  23. 23
    G.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
  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
    ITU-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
  25. 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.
    ITU-T P.800.1 (07/2016) Table of contents · Table of contents, clause 7.1 to 7.4 · Checked 2026-09-24
  26. 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.
    P.800.1: Mean opinion score (MOS) terminology (recommendation page) · Recommendation listing, in-force and superseded rows · Checked 2026-09-24
  27. 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.
    ITU-T P.800.1 (07/2016) Summary · Summary, paragraph 2 · Checked 2026-09-24
  28. 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.
    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
  29. 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.
    P.800 : Methods for subjective determination of transmission quality · Recommendation listing, in-force row P.800 (08/96) · Checked 2026-09-24
  30. 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.
    P.863 : Perceptual objective listening quality prediction · Recommendation listing, in-force and superseded rows · Checked 2026-09-24
  31. 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.
    ITU-T P.863 (03/2018) Summary · Summary, edition 3 changes · Checked 2026-09-24
  32. 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.
    ITU-T P.863 (03/2018) Summary · Summary, paragraph 1 · Checked 2026-09-24
  33. 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
    Session 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
  34. 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.
    RTP Control Protocol Extended Reports (RTCP XR) · Section 4.7.3, round trip delay and end system delay · Checked 2026-09-24
  35. 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.
    RTP Control Protocol Extended Reports (RTCP XR) · Section 4.7.1, loss rate and discard rate · Checked 2026-09-24
  36. 36
    RTCP 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
  37. 37
    RTCP 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
  38. 38
    RTCP 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
  39. 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.
    RTP Control Protocol Extended Reports (RTCP XR) · Section 4.7.5, R factor · Checked 2026-09-24
  40. 40
    RTCP 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
  41. 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.
    RTP: A Transport Protocol for Real-Time Applications · Section 6.4.1, cumulative number of packets lost · Checked 2026-09-24
  42. 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.
    RTP: A Transport Protocol for Real-Time Applications · Section 6.4.1, fraction lost · Checked 2026-09-24
  43. 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.
    RTP: A Transport Protocol for Real-Time Applications · Section 6.4.1, interarrival jitter · Checked 2026-09-24
  44. 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.
    RTP: A Transport Protocol for Real-Time Applications · Section 6.4.1, interarrival jitter · Checked 2026-09-24
  45. 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.
    Session Initiation Protocol Event Package for Voice Quality Reporting · Section 4 (event package definition) · Checked 2026-09-24
  46. 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.
    Session Initiation Protocol Event Package for Voice Quality Reporting · Section 4.6.1, ABNF ListeningQualityR, ConversationalQualityR, MOS-LQ, MOS-CQ · Checked 2026-09-24
  47. 47
    RFC 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
  48. 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.
    Stream classification in Call Quality Dashboard (CQD) · Classifier Definitions > Audio Classifier, table and note · Checked 2026-09-24
  49. 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.
    Stream classification in Call Quality Dashboard (CQD) · Classifier Definitions > Audio Classifier, table · Checked 2026-09-24
  50. 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.
    Stream classification in Call Quality Dashboard (CQD) · Classifier Definitions > Audio Classifier, Note · Checked 2026-09-24
  51. 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.
    Stream classification in Call Quality Dashboard (CQD) · Unclassified Streams > QoE reports weren't received · Checked 2026-09-24
  52. 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.
    Stream classification in Call Quality Dashboard (CQD) · Unclassified Streams · Checked 2026-09-24
  53. 53
    Control 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
  54. 54
    Accessing 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
  55. 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.
    Troubleshoot Webex Calling calls in Control Hub · Troubleshooting media quality issues (endpoint thresholds) · Checked 2026-09-24
  56. 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.
    Troubleshoot Webex Calling calls in Control Hub · Troubleshooting media quality issues (media relay point / hop thresholds) · Checked 2026-09-24
  57. 57
    Control 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
  58. 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.
    Troubleshoot Webex Calling calls in Control Hub · Troubleshooting media quality issues · Checked 2026-09-24
  59. 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.
    Troubleshoot Webex Calling calls in Control Hub · Minute-by-minute view · Checked 2026-09-24
  60. 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
    Troubleshoot Webex Calling calls in Control Hub · Whole article (absence of MOS) · Checked 2026-09-24

Documents

tier 1 standards and regulators

G.107: The E-model: a computational model for use in transmission planning (recommendation page)

ITU-T · 2015-06-01 · accessed 2026-09-24

tier 1 standards and regulators

G.107.1 : Wideband E-model

ITU-T · 2019-06-01 · accessed 2026-09-24

tier 1 standards and regulators

G.114: One-way transmission time (recommendation page)

ITU-T · 2003-05-01 · accessed 2026-09-24

tier 1 standards and regulators

ITU-T G.107 (06/2015) Summary

ITU-T · 2015-06-29 · accessed 2026-09-24

tier 1 standards and regulators

ITU-T G.107.1 (06/2019) Summary

ITU-T · 2019-06-01 · accessed 2026-09-24

tier 1 standards and regulators

ITU-T G.114 (05/2003) Summary

ITU-T · 2003-05-01 · accessed 2026-09-24

tier 1 standards and regulators

ITU-T P.800.1 (07/2016) Summary

ITU-T · 2016-07-29 · accessed 2026-09-24

tier 1 standards and regulators

ITU-T P.800.1 (07/2016) Table of contents

ITU-T · 2016-07-29 · accessed 2026-09-24

tier 1 standards and regulators

ITU-T P.863 (03/2018) Summary

ITU-T · 2018-03-01 · accessed 2026-09-24

tier 1 standards and regulators

P.800 : Methods for subjective determination of transmission quality

ITU-T · 1996-08-01 · accessed 2026-09-24

tier 1 standards and regulators

P.800.1: Mean opinion score (MOS) terminology (recommendation page)

ITU-T · 2016-07-01 · accessed 2026-09-24

tier 1 standards and regulators

P.863 : Perceptual objective listening quality prediction

ITU-T · 2020-04-01 · accessed 2026-09-24

tier 1 standards and regulators

RTP Control Protocol Extended Reports (RTCP XR)

IETF / RFC Editor · 2003-11-01 · accessed 2026-09-24

tier 1 standards and regulators

RTP: A Transport Protocol for Real-Time Applications

IETF / RFC Editor · 2003-07-01 · accessed 2026-09-24

tier 1 standards and regulators

Session Initiation Protocol Event Package for Voice Quality Reporting

IETF / RFC Editor · 2010-11-01 · accessed 2026-09-24

tier 2 current vendor documentation

Stream classification in Call Quality Dashboard (CQD)

Microsoft · 2026-06-16 · accessed 2026-09-24

tier 2 current vendor documentation

Troubleshoot Webex Calling calls in Control Hub

Cisco Systems, Inc. (Webex Help Center) · 2026-09-01 · accessed 2026-09-05

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}
}