# RTP and RTCP quality metrics

Canonical: https://warmtransfer.net/knowledge/rtp-rtcp-quality

Last verified: 2026-09-24

RFC 3550 (RTP) is a Standards Track RFC dated July 2003 that obsoletes RFC 1889 without changing packet formats on the wire[^23]. The RTCP interarrival jitter field is expressed in RTP timestamp units, not milliseconds, and the RTCP report block fraction lost field is an 8-bit fixed-point fraction of packets lost since the previous SR or RR[^10][^20].

## Core RTP and RTCP reporting mechanics

RTCP Sender Report uses packet type 200 and Receiver Report uses packet type 201[^39]. RFC 3550 recommends that RTCP bandwidth be fixed at 5% of the session bandwidth, with one quarter of the RTCP bandwidth dedicated to participants that are sending data[^29][^35]. The RECOMMENDED fixed minimum RTCP reporting interval in RFC 3550 is 5 seconds[^32].

Reception report blocks in Sender Reports and Receiver Reports communicate loss, transit variance, and delays:[^39]

- **Fraction lost**: The RTCP report block fraction lost field is an 8-bit fixed-point fraction of packets lost since the previous SR or RR[^10].
- **Cumulative packets lost**: The RTCP cumulative number of packets lost is a 24-bit field that can be negative because duplicate packets are counted as received[^8].
- **Interarrival jitter**: RFC 3550 computes interarrival jitter as a running estimate updated with a gain of 1/16 on the absolute difference in transit time between consecutive packets[^18]. The RTCP interarrival jitter field is expressed in RTP timestamp units, not milliseconds[^20].
- **Round-trip time computation**: An RTP sender computes round-trip time from a received report block as arrival time A minus LSR minus DLSR[^36].

RTP and RTCP multiplexing on a single port is negotiated with the SDP attribute a=rtcp-mux, which the initial offer must include at media level[^34]. When RTP and RTCP are multiplexed, RTP payload types 64 to 95 must be avoided so RTCP packets can be distinguished, and dynamic payload types should come from 96 to 127[^33].

## Clock rates and jitter unit conversion

Under RFC 3551 the default audio packetization interval SHOULD be 20 ms or one frame, whichever is longer, unless otherwise noted[^9]. Payload clock rates dictate the conversion of RTCP interarrival jitter into time units:[^20]

- PCMU (static payload type 0) and PCMA (static payload type 8) use an RTP clock rate of 8000 Hz[^14].
- G.729 uses static payload type 18 with an RTP timestamp clock rate of 8000 Hz for all data rates[^16].
- G.722 (static payload type 9) samples at 16000 Hz but its RTP clock rate is 8000 Hz for backward compatibility with an erroneous RFC 1890 assignment[^15].

WarmTransfer's reading of the sources is that to express RTCP jitter in milliseconds, divide the timestamp-unit value by the payload clock rate in kHz; for G.711, G.729 and G.722 that divisor is 8, so 160 units equals 20 ms[^19].

RFC 5481 defines IPDV as each packet's one-way delay minus the previous packet's delay, and PDV as each packet's delay minus the minimum delay in the measurement interval[^17]. RFC 5481 states that the RTCP interarrival jitter value can be calculated from IPDV singletons, but recommends PDV, not IPDV, for sizing de-jitter buffers[^22][^30]. WarmTransfer's reading of the sources is that the RTCP jitter figure is a smoothed IPDV-style average and should not be read directly as the jitter buffer depth a stream needs[^31].

## RTCP Extended Reports (RTCP XR)

RFC 3611 (RTCP Extended Reports) is a Standards Track RFC dated November 2003[^24]. RFC 3611 defines seven RTCP XR report block types: Loss RLE (1), Duplicate RLE (2), Packet Receipt Times (3), Receiver Reference Time (4), DLRR (5), Statistics Summary (6) and VoIP Metrics (7)[^52].

Within the VoIP Metrics block:
- **Loss and discard rates**: In the RTCP XR VoIP Metrics block, loss rate and discard rate are 8-bit fixed-point fractions computed as packets lost or discarded divided by packets expected, multiplied by 256 and capped at 255[^57].
- **Bursts and gaps**: The RTCP XR VoIP Metrics block reports burst and gap durations as mean durations in milliseconds and burst and gap densities as 8-bit fixed-point fractions[^53]. RFC 3611 recommends a Gmin gap threshold value of 16 for distinguishing bursts from gaps in VoIP Metrics reporting[^55].
- **Delays**: The RTCP XR VoIP Metrics block carries round trip delay and end system delay as 16-bit values in milliseconds[^54].
- **Jitter buffer metrics**: The RTCP XR VoIP Metrics block reports jitter buffer nominal, maximum and absolute maximum delay as 16-bit values in milliseconds[^56].
- **R factor**: The RTCP XR VoIP Metrics R factor and external R factor are integers from 0 to 100, with 127 meaning unavailable[^60].
- **MOS metrics**: The RTCP XR VoIP Metrics MOS-LQ and MOS-CQ fields carry MOS multiplied by 10 as an integer from 10 to 50, with 127 meaning unavailable[^58]. In RFC 3611, MOS-LQ is a listening-quality estimate that excludes delay effects, while MOS-CQ is a conversational-quality estimate that includes them[^59].

Later architectural guidance in RFC 6792, citing RFC 6390, states that new RTCP XR report block definitions should refer to performance metrics defined elsewhere rather than define new ones, and recommends that new RTCP XR metric blocks carry a very small number of metrics describing one parameter, rather than bundling many metrics as the RFC 3611 VoIP Metrics block does[^25][^26]. RFC 7003 (Standards Track, September 2013) defines the RTCP XR Burst/Gap Discard Metrics block as block type 20[^27]. The Threshold field in the RFC 7003 burst/gap discard block is equivalent to Gmin in RFC 3611[^28].

The in-force edition of ITU-T G.114 (One-way transmission time) is 05/2003, amended in 09/2003 with an Appendix II on VoIP delay and in 11/2009 with an Appendix III[^13]. The in-force edition of ITU-T G.107, The E-model: a computational model for use in transmission planning, is 06/2015[^11]. The in-force edition of ITU-T P.800.1, Mean opinion score (MOS) terminology, is 07/2016[^21].

## Platform quality thresholds and reporting

WarmTransfer's reading of the sources is that vendor good/poor jitter thresholds differ by roughly 5 times (Webex Calling endpoint 150 ms vs Teams CQD audio 30 ms), so a poor grade on one platform cannot be carried over as a poor grade on another:[^41]

| Platform / Context | Latency / RTT "Good" | Jitter "Good" | Packet Loss "Good" |
| --- | --- | --- | --- |
| Webex Calling Endpoints[^45] | < 400 ms | < 150 ms | < 5% |
| Webex Calling Relay Hops[^46] | < 200 ms | < 75 ms | < 2.5% |
| Microsoft Teams CQD (Poor criteria)[^5] | > 500 ms | > 30 ms | > 0.1 |
| Skype for Business Online (retired targets)[^38] | < 60 ms | < 3 ms | < 0.5% avg |

WarmTransfer's reading of the sources is that vendor good/poor jitter thresholds differ by roughly 5 times (Webex Calling endpoint 150 ms vs Teams CQD audio 30 ms), so a poor grade on one platform cannot be carried over as a poor grade on another[^41].

### Cisco Webex Calling

Webex Calling troubleshooting in Control Hub grades an endpoint as good when packet loss is under 5%, latency or RTT under 400 ms and jitter under 150 ms[^45]. Webex Calling troubleshooting grades a media relay point hop as good when packet loss is under 2.5%, latency or RTT under 200 ms and jitter under 75 ms[^46]. Access to the Webex Calling troubleshooting view requires the full admin, read-only admin or support admin role in Control Hub[^51]. Webex Calling troubleshooting in Control Hub lets admins view calls for the past 21 days[^50]. The Webex Calling minute-by-minute media quality view is available for Webex clients and RoomOS endpoints but not for MPP phones or Cisco-managed third-party endpoints[^48]. For Webex Calling PSTN calls, the end-to-end experience and receive stream metrics of the PSTN-side party are not available because they are not transmitted to the Webex Calling cloud[^49]. WarmTransfer's reading of the sources is that the Webex Calling Control Hub troubleshooting article lists latency, packet loss, jitter and media bitrate as audio metrics and does not describe a MOS value[^47].

Cisco strongly recommends UDP for all Webex voice and video media and warns that TCP fallback retransmission and buffering show up as increased latency and jitter[^44]. Cisco strongly recommends that TLS not be used to transport Webex media in production because of further quality degradation from proxy bottlenecks[^43]. WarmTransfer's reading of the sources is that the Webex network requirements article gives no numeric packet loss, jitter or latency targets for media[^42].

### Microsoft Teams and Skype for Business Online

Teams CQD marks an audio stream Poor if packet utilization exceeds 500 packets and any one of round trip over 500 ms, packet loss rate over 0.1, or jitter over 30 ms is met[^5]. Microsoft states that a CQD Poor audio classification does not mean the stream was actually poor or that the user perceived a quality issue[^6]. CQD marks a stream Unclassified when ICE connectivity fails or the required metrics are not reported, for example because no QoE report arrived, the call was short, or packet utilization was low[^7]. The current Microsoft Teams prepare-network page attributes robotic or cutting-out audio to jitter or packet loss but carries no numeric latency, jitter or loss requirement table[^40].

The archived Skype for Business Online network performance page set client-to-Microsoft-edge targets of RTT under 60 ms, average packet loss under 0.5%, maximum packet loss under 5% and jitter under 3 ms, with poor at over 500 ms, 10%, 25% and 30 ms respectively[^38]. The archived Skype for Business Online guidance says to sample every 10 minutes for at least a week and compare the 90th percentile value against the network performance requirements[^37].

### Cisco Unified Communications Manager (CUCM)

In Cisco Unified CM Call Management Records the jitter field is an unsigned integer estimate of RTP interarrival time variance expressed in milliseconds[^2]. Cisco Unified CM CMR latency is not populated for all phone loads; the guide cites SIP loads 9.2.1 and 9.2.2 as examples where latency does not show[^3]. In Cisco Unified CM CMR varVQMetrics, MLQK is a K-factor estimate of the MOS of the last 8 seconds of speech, and MLQKmn and MLQKmx are the worst and best 8-second intervals[^4]. CUCM CMR CCR is the cumulative ratio of concealment time to speech time, CS counts time with some concealment and SCS counts time with significant concealment[^1].

## See also

- See also [SRTP and media encryption negotiation](https://warmtransfer.net/knowledge/srtp-media-security).
- See also [SIP trace capture and ladder analysis](https://warmtransfer.net/knowledge/sip-trace-analysis).
- See also [Webex Calling ICE media path optimization](https://warmtransfer.net/knowledge/webex-calling-media-optimization).
- See also [SDP offer answer and codec negotiation](https://warmtransfer.net/knowledge/sdp-offer-answer).
- See also [One-way and no-way audio diagnosis](https://warmtransfer.net/knowledge/one-way-audio).
- See also [NAT traversal ICE STUN and TURN](https://warmtransfer.net/knowledge/nat-traversal-ice).
- See also [WebRTC in modern contact centers](https://warmtransfer.net/knowledge/webrtc-deployment).

## Applicability

Applies to: IETF RTP, IETF IPPM delay variation, IETF RTCP XR, ITU-T G.114, ITU-T G.107, ITU-T P.800.1, Webex Calling; Teams CQD, Cisco Webex Calling, Microsoft Teams Call Quality Dashboard, Microsoft Skype for Business Online (retired), Cisco Webex services, Microsoft Teams, and Cisco Unified Communications Manager. Deployments: on-premises, multi-tenant, and any. Sources checked 2026-09-24. The in-force edition of ITU-T G.114 is 05/2003, the in-force edition of ITU-T G.107 is 06/2015, and the in-force edition of ITU-T P.800.1 is 07/2016[^11][^13][^21]. Cisco Unified CM CMR latency is not populated for SIP loads 9.2.1 and 9.2.2 as examples where latency does not show[^3].

## What remains uncertain

Webex Contact Center agent and customer leg voice quality metrics and any MOS exposure are not covered by the sources below. Webex Calling media quality analytics reports beyond troubleshooting view (does any report show MOS) are not covered by the sources below. ITU-T G.107 (06/2015) R-to-MOS conversion formula and default R value are not covered by the sources below. Verifying G.114 clause 4 wording on 400 ms and the status of 150 ms guidance and the three-band table is not covered by the sources below. Teams CQD intelligent media quality classifiers are not covered by the sources below. IOS-XE CUBE and Local Gateway RTP and RTCP statistics (show call active voice) and voice quality reporting are not covered by the sources below. Teams Direct Routing SBC media quality metrics and health dashboard are not covered by the sources below. Webex Control Hub ThousandEyes integration latency and loss grading is not covered by the sources below.

## Sources

[^1]: CUCM CMR CCR is the cumulative ratio of concealment time to speech time, CS counts time with some concealment and SCS counts time with significant concealment. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 14 and SUs - CMR Field Descriptions](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/14/cucm_b_reporting-billing-administration-guide-14/cucm_b_reporting-and-billing-administration-guide_chapter_01101.html), K-factor data table, CCR / CS / SCS. Checked 2026-09-24.
[^2]: In Cisco Unified CM Call Management Records the jitter field is an unsigned integer estimate of RTP interarrival time variance expressed in milliseconds. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 14 and SUs - CMR Field Descriptions](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/14/cucm_b_reporting-billing-administration-guide-14/cucm_b_reporting-and-billing-administration-guide_chapter_01101.html), CMR field table, jitter. Checked 2026-09-24.
[^3]: Cisco Unified CM CMR latency is not populated for all phone loads; the guide cites SIP loads 9.2.1 and 9.2.2 as examples where latency does not show. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 14 and SUs - CMR Field Descriptions](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/14/cucm_b_reporting-billing-administration-guide-14/cucm_b_reporting-and-billing-administration-guide_chapter_01101.html), CMR field table, latency. Checked 2026-09-24.
[^4]: In Cisco Unified CM CMR varVQMetrics, MLQK is a K-factor estimate of the MOS of the last 8 seconds of speech, and MLQKmn and MLQKmx are the worst and best 8-second intervals. Source: [Call Reporting and Billing Administration Guide for Cisco Unified Communications Manager, Release 14 and SUs - CMR Field Descriptions](https://www.cisco.com/c/en/us/td/docs/voice_ip_comm/cucm/callReportingBillingAdmin/14/cucm_b_reporting-billing-administration-guide-14/cucm_b_reporting-and-billing-administration-guide_chapter_01101.html), K-factor data table, MLQK / MLQKmn / MLQKmx. Checked 2026-09-24.
[^5]: Teams CQD marks an audio stream Poor if packet utilization exceeds 500 packets and any one of round trip over 500 ms, packet loss rate over 0.1, or jitter over 30 ms is met. 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.
[^6]: Microsoft states that a CQD Poor audio classification does not mean the stream was actually poor or that the user perceived a quality issue. Source: [Stream classification in Call Quality Dashboard (CQD)](https://learn.microsoft.com/en-us/microsoftteams/stream-classification-in-call-quality-dashboard), Audio Classifier > Note. Checked 2026-09-24.
[^7]: CQD marks a stream Unclassified when ICE connectivity fails or the required metrics are not reported, for example because no QoE report arrived, the call was short, or packet utilization was low. 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.
[^8]: The RTCP cumulative number of packets lost is a 24-bit field that can be negative because duplicate packets are counted as received. 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 field. Checked 2026-09-24.
[^9]: Under RFC 3551 the default audio packetization interval SHOULD be 20 ms or one frame, whichever is longer, unless otherwise noted. Source: [RTP Profile for Audio and Video Conferences with Minimal Control](https://www.rfc-editor.org/rfc/rfc3551.html), Section 4.2. Checked 2026-09-24.
[^10]: The RTCP report block fraction lost field is an 8-bit fixed-point fraction of packets lost since the previous SR or RR. Source: [RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550.html), Section 6.4.1, fraction lost field. Checked 2026-09-24.
[^11]: The in-force edition of ITU-T G.107, The E-model: a computational model for use in transmission planning, is 06/2015. 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 page version table. Checked 2026-09-24.
[^12]: ITU-T G.114 (05/2003) recommends that 400 ms one-way delay should not be exceeded for general network planning. Source: [G.114: One-way transmission time (recommendation page)](https://www.itu.int/rec/T-REC-G.114), Clause 4 (per first extraction pass of T-REC-G.114-200305-I PDF; unconfirmed). Checked 2026-09-24.
[^13]: The in-force edition of ITU-T G.114 (One-way transmission time) is 05/2003, amended in 09/2003 with an Appendix II on VoIP delay and in 11/2009 with an Appendix III. Source: [G.114: One-way transmission time (recommendation page)](https://www.itu.int/rec/T-REC-G.114), Recommendation page version table. Checked 2026-09-24.
[^14]: PCMU (static payload type 0) and PCMA (static payload type 8) use an RTP clock rate of 8000 Hz. Source: [RTP Profile for Audio and Video Conferences with Minimal Control](https://www.rfc-editor.org/rfc/rfc3551.html), Section 4.5.14; Section 6 payload type table. Checked 2026-09-24.
[^15]: G.722 (static payload type 9) samples at 16000 Hz but its RTP clock rate is 8000 Hz for backward compatibility with an erroneous RFC 1890 assignment. Source: [RTP Profile for Audio and Video Conferences with Minimal Control](https://www.rfc-editor.org/rfc/rfc3551.html), Section 4.5.2. Checked 2026-09-24.
[^16]: G.729 uses static payload type 18 with an RTP timestamp clock rate of 8000 Hz for all data rates. Source: [RTP Profile for Audio and Video Conferences with Minimal Control](https://www.rfc-editor.org/rfc/rfc3551.html), Section 4.5.6. Checked 2026-09-24.
[^17]: RFC 5481 defines IPDV as each packet's one-way delay minus the previous packet's delay, and PDV as each packet's delay minus the minimum delay in the measurement interval. Source: [Packet Delay Variation Applicability Statement](https://www.rfc-editor.org/rfc/rfc5481.html), Sections 4.1 and 4.2. Checked 2026-09-24.
[^18]: RFC 3550 computes interarrival jitter as a running estimate updated with a gain of 1/16 on the absolute difference in 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; Appendix A.8. Checked 2026-09-24.
[^19]: To express RTCP jitter in milliseconds, divide the timestamp-unit value by the payload clock rate in kHz; for G.711, G.729 and G.722 that divisor is 8, so 160 units equals 20 ms (inferred). Source: [RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550.html), Section 6.4.1 (units) combined with rfc-3551-rtp-av-profile Sections 4.5.2, 4.5.6, 4.5.14 (clock rates). Checked 2026-09-24.
[^20]: The RTCP interarrival jitter field is expressed in RTP timestamp units, not milliseconds. Source: [RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550.html), Section 6.4.1, interarrival jitter field. Checked 2026-09-24.
[^21]: The in-force edition of ITU-T P.800.1, Mean opinion score (MOS) terminology, is 07/2016. Source: [P.800.1: Mean opinion score (MOS) terminology (recommendation page)](https://www.itu.int/rec/T-REC-P.800.1), Recommendation page version table. Checked 2026-09-24.
[^22]: RFC 5481 recommends PDV, not IPDV, for sizing de-jitter buffers. Source: [Packet Delay Variation Applicability Statement](https://www.rfc-editor.org/rfc/rfc5481.html), Section 7.1.2. Checked 2026-09-24.
[^23]: RFC 3550 (RTP) is a Standards Track RFC dated July 2003 that obsoletes RFC 1889 without changing packet formats on the wire. Source: [RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550.html), header block; Abstract. Checked 2026-09-24.
[^24]: RFC 3611 (RTCP Extended Reports) is a Standards Track RFC dated November 2003. Source: [RTP Control Protocol Extended Reports (RTCP XR)](https://www.rfc-editor.org/rfc/rfc3611.html), header block. Checked 2026-09-24.
[^25]: RFC 6792, citing RFC 6390, states that new RTCP XR report block definitions should refer to performance metrics defined elsewhere rather than define new ones. Source: [Guidelines for Use of the RTP Monitoring Framework](https://www.rfc-editor.org/rfc/rfc6792.html), Section 1. Checked 2026-09-24.
[^26]: RFC 6792 recommends that new RTCP XR metric blocks carry a very small number of metrics describing one parameter, rather than bundling many metrics as the RFC 3611 VoIP Metrics block does. Source: [Guidelines for Use of the RTP Monitoring Framework](https://www.rfc-editor.org/rfc/rfc6792.html), Sections 4.1 and 5.1. Checked 2026-09-24.
[^27]: RFC 7003 (Standards Track, September 2013) defines the RTCP XR Burst/Gap Discard Metrics block as block type 20. Source: [RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting](https://www.rfc-editor.org/rfc/rfc7003.html), header block; Section 3 and IANA Considerations. Checked 2026-09-24.
[^28]: The Threshold field in the RFC 7003 burst/gap discard block is equivalent to Gmin in RFC 3611. Source: [RTP Control Protocol (RTCP) Extended Report (XR) Block for Burst/Gap Discard Metric Reporting](https://www.rfc-editor.org/rfc/rfc7003.html), Section 3.2, Threshold field. Checked 2026-09-24.
[^29]: RFC 3550 recommends that RTCP bandwidth be fixed at 5% of the session bandwidth. Source: [RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550.html), Section 6.2. Checked 2026-09-24.
[^30]: RFC 5481 states that the RTCP interarrival jitter value can be calculated from IPDV singletons. Source: [Packet Delay Variation Applicability Statement](https://www.rfc-editor.org/rfc/rfc5481.html), Section 6.6. Checked 2026-09-24.
[^31]: The RTCP jitter figure is a smoothed IPDV-style average and should not be read directly as the jitter buffer depth a stream needs (inferred). Source: [Packet Delay Variation Applicability Statement](https://www.rfc-editor.org/rfc/rfc5481.html), Sections 6.6 and 7.1.2, read with rfc-3550-rtp Section 6.4.1. Checked 2026-09-24.
[^32]: The RECOMMENDED fixed minimum RTCP reporting interval in RFC 3550 is 5 seconds. Source: [RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550.html), Section 6.2. Checked 2026-09-24.
[^33]: When RTP and RTCP are multiplexed, RTP payload types 64 to 95 must be avoided so RTCP packets can be distinguished, and dynamic payload types should come from 96 to 127. Source: [Multiplexing RTP Data and Control Packets on a Single Port](https://www.rfc-editor.org/rfc/rfc5761.html), Section 4. Checked 2026-09-24.
[^34]: RTP and RTCP multiplexing on a single port is negotiated with the SDP attribute a=rtcp-mux, which the initial offer must include at media level. Source: [Multiplexing RTP Data and Control Packets on a Single Port](https://www.rfc-editor.org/rfc/rfc5761.html), Section 5.1.1. Checked 2026-09-24.
[^35]: RFC 3550 recommends that one quarter of the RTCP bandwidth be dedicated to participants that are sending data. Source: [RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550.html), Section 6.2. Checked 2026-09-24.
[^36]: An RTP sender computes round-trip time from a received report block as arrival time A minus LSR minus DLSR. Source: [RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550.html), Section 6.4.1, delay since last SR (DLSR) field and Figure 2. Checked 2026-09-24.
[^37]: The archived Skype for Business Online guidance says to sample every 10 minutes for at least a week and compare the 90th percentile value against the network performance requirements. Source: [Media Quality and Network Connectivity Performance - Skype for Business Online (retired)](https://learn.microsoft.com/en-us/previous-versions/skypeforbusiness/optimizing-your-network/media-quality-and-network-connectivity-performance), Measuring network performance. Checked 2026-09-24.
[^38]: The archived Skype for Business Online network performance page set client-to-Microsoft-edge targets of RTT under 60 ms, average packet loss under 0.5%, maximum packet loss under 5% and jitter under 3 ms, with poor at over 500 ms, 10%, 25% and 30 ms respectively. Source: [Media Quality and Network Connectivity Performance - Skype for Business Online (retired)](https://learn.microsoft.com/en-us/previous-versions/skypeforbusiness/optimizing-your-network/media-quality-and-network-connectivity-performance), Network Performance requirements from a Skype for Business client to Microsoft network Edge (table). Checked 2026-09-24.
[^39]: RTCP Sender Report uses packet type 200 and Receiver Report uses packet type 201. Source: [RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550.html), Section 12.1, RTCP Packet Types. Checked 2026-09-24.
[^40]: The current Microsoft Teams prepare-network page attributes robotic or cutting-out audio to jitter or packet loss but carries no numeric latency, jitter or loss requirement table. Source: [Prepare your organization's network for Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/prepare-network), Network optimization section. Checked 2026-09-24.
[^41]: Vendor good/poor jitter thresholds differ by roughly five times (Webex Calling endpoint 150 ms vs Teams CQD audio 30 ms), so a poor grade on one platform cannot be carried over as a poor grade on another (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), Media quality thresholds for endpoints, compared with ms-learn-cqd-stream-classification Audio Classifier table. Checked 2026-09-24.
[^42]: The Webex network requirements article gives no numeric packet loss, jitter or latency targets for media (inferred). Source: [Network Requirements for Webex Services](https://help.webex.com/en-us/article/WBX000028782/Network-Requirements-for-Webex-Services), whole article. Checked 2026-09-24.
[^43]: Cisco strongly recommends that TLS not be used to transport Webex media in production because of further quality degradation from proxy bottlenecks. Source: [Network Requirements for Webex Services](https://help.webex.com/en-us/article/WBX000028782/Network-Requirements-for-Webex-Services), TLS as a fallback transport. Checked 2026-09-24.
[^44]: Cisco strongly recommends UDP for all Webex voice and video media and warns that TCP fallback retransmission and buffering show up as increased latency and jitter. Source: [Network Requirements for Webex Services](https://help.webex.com/en-us/article/WBX000028782/Network-Requirements-for-Webex-Services), Protocols for media / TCP as a fallback transport. Checked 2026-09-24.
[^45]: Webex Calling troubleshooting in Control Hub grades an endpoint as good when packet loss is under 5%, latency or RTT under 400 ms and jitter 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), Media quality thresholds for endpoints. Checked 2026-09-24.
[^46]: Webex Calling troubleshooting grades a media relay point hop as good when packet loss is under 2.5%, 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), Media quality thresholds for media relay points (hops). Checked 2026-09-24.
[^47]: The Webex Calling Control Hub troubleshooting article lists latency, packet loss, jitter and media bitrate as audio metrics and does not describe a MOS value (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), Call details / media quality metrics sections. Checked 2026-09-24.
[^48]: The Webex Calling minute-by-minute media quality view is available for Webex clients and RoomOS endpoints but not for MPP phones or Cisco-managed third-party endpoints. 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 media quality section. Checked 2026-09-24.
[^49]: For Webex Calling PSTN calls, the end-to-end experience and receive stream metrics of the PSTN-side party are not available because they are not transmitted to 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), PSTN / Local Gateway call section. Checked 2026-09-24.
[^50]: Webex Calling troubleshooting in Control Hub lets admins 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), Troubleshooting view / search section. Checked 2026-09-24.
[^51]: Access to the Webex Calling troubleshooting view requires the full admin, read-only admin or support admin role in Control Hub. Source: [Troubleshoot Webex Calling calls in Control Hub](https://help.webex.com/en-us/article/frj1efb/Troubleshoot-Webex-Calling-Media-Quality-in-Control-Hub), Before you begin / prerequisites. Checked 2026-09-24.
[^52]: RFC 3611 defines seven RTCP XR report block types: Loss RLE (1), Duplicate RLE (2), Packet Receipt Times (3), Receiver Reference Time (4), DLRR (5), Statistics Summary (6) and VoIP Metrics (7). Source: [RTP Control Protocol Extended Reports (RTCP XR)](https://www.rfc-editor.org/rfc/rfc3611.html), Sections 4.1 to 4.7. Checked 2026-09-24.
[^53]: The RTCP XR VoIP Metrics block reports burst and gap durations as mean durations in milliseconds and burst and gap densities as 8-bit fixed-point fractions. Source: [RTP Control Protocol Extended Reports (RTCP XR)](https://www.rfc-editor.org/rfc/rfc3611.html), Section 4.7.2. Checked 2026-09-24.
[^54]: The RTCP XR VoIP Metrics block carries round trip delay and end system delay as 16-bit values in milliseconds. Source: [RTP Control Protocol Extended Reports (RTCP XR)](https://www.rfc-editor.org/rfc/rfc3611.html), Section 4.7.3. Checked 2026-09-24.
[^55]: RFC 3611 recommends a Gmin gap threshold value of 16 for distinguishing bursts from gaps in VoIP Metrics reporting. Source: [RTP Control Protocol Extended Reports (RTCP XR)](https://www.rfc-editor.org/rfc/rfc3611.html), Section 4.7.6, Gmin field. Checked 2026-09-24.
[^56]: The RTCP XR VoIP Metrics block reports jitter buffer nominal, maximum and absolute maximum delay as 16-bit values in milliseconds. Source: [RTP Control Protocol Extended Reports (RTCP XR)](https://www.rfc-editor.org/rfc/rfc3611.html), Section 4.7.7. Checked 2026-09-24.
[^57]: In the RTCP XR VoIP Metrics block, loss rate and discard rate are 8-bit fixed-point fractions computed as packets lost or discarded divided by packets expected, multiplied by 256 and capped at 255. Source: [RTP Control Protocol Extended Reports (RTCP XR)](https://www.rfc-editor.org/rfc/rfc3611.html), Section 4.7.1. Checked 2026-09-24.
[^58]: The RTCP XR VoIP Metrics MOS-LQ and MOS-CQ fields carry MOS multiplied by 10 as an integer from 10 to 50, 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 fields. Checked 2026-09-24.
[^59]: In RFC 3611, MOS-LQ is a listening-quality estimate that excludes delay effects, while MOS-CQ is a conversational-quality estimate that includes them. 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 fields. Checked 2026-09-24.
[^60]: The RTCP XR VoIP Metrics R factor and external R factor are integers from 0 to 100, with 127 meaning unavailable. Source: [RTP Control Protocol Extended Reports (RTCP XR)](https://www.rfc-editor.org/rfc/rfc3611.html), Section 4.7.5, R factor and ext. R factor fields. Checked 2026-09-24.