# Choppy and robotic audio on calls

Canonical: https://warmtransfer.net/knowledge/choppy-audio-troubleshooting

Last verified: 2026-09-25

Choppy and robotic voice quality on real-time calls is commonly triggered by packet loss, delay variation, and playout buffer discards[^32][^5]. Microsoft's Teams network guidance explicitly lists static, cutting out, and voices sounding like robots as symptoms that can be caused by jitter or packet loss[^32].

## Packet Loss, Jitter, and Playout Discards

Cisco defines jitter as a variation in the delay of received packets, which can stem from network congestion, improper queuing, or configuration errors[^6]. On Cisco IOS voice gateways, the playout (de-jitter) buffer discards packets arriving outside its range, resulting in audible audio dropouts[^5]. While a digital signal processor (DSP) can interpolate over minor loss, degradation becomes audible when jitter exceeds its compensation capability[^5]. The Cisco IOS playout delay buffer operates in an adaptive mode by default to adjust to observed jitter up to a point, though administrators can alter it using the `playout-delay` command, including setting it to a fixed mode[^3]. The `Buf Overflow Discard (ms)` counter in Cisco IOS DSP VOICE VP_ERROR statistics records packets that fell outside the playout buffer and were dropped; while a nonzero value is acceptable, it should not continuously increase during an active call[^4].

Under RFC 3550, an RTCP reception report block carries an 8-bit fraction lost field representing the fraction of RTP packets lost since the previous Sender Report (SR) or Receiver Report (RR), formatted as a fixed-point number with the binary point at the left edge[^21]. A 24-bit cumulative packet loss counter tracks total lost packets since reception began[^20]. RFC 3550 defines interarrival jitter as a 32-bit estimate of statistical variance in packet arrival spacing, expressed in RTP timestamp units rather than milliseconds[^24]. RFC 3550 computes interarrival jitter as a running estimate smoothed with gain 1/16: J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16, where D is the difference in packet spacing at the receiver compared with the sender[^22]. RTCP bandwidth is recommended to be fixed at 5% of session bandwidth, with a recommended minimum reporting interval of 5 seconds[^19][^26]. RFC 3550 notes that distributing reception feedback among all participants allows observers to evaluate whether degradation is local or global, facilitating the isolation of problematic network segments[^25].

Under RFC 3611, the RTCP XR VoIP Metrics report block records a distinct discard rate representing packets discarded due to early or late arrival, or under-run and overflow at the receiver's jitter buffer[^52]. This VoIP Metrics block also tracks burst and gap density and duration, round-trip delay, end-system delay (including jitter buffer delay), R factor, MOS-LQ, MOS-CQ, and jitter buffer nominal, maximum, and absolute-maximum delay[^53]. WarmTransfer's reading of the sources is that standard RTCP loss counters (fraction lost, cumulative lost) count packets that never arrived, while packets that arrive too late for the jitter buffer are reported separately as discards in RTCP XR, meaning a call can sound choppy while basic RTCP shows little loss, and heavy jitter should be checked in that case[^13].

For codec-level resilience, Opus defines optional in-band redundancy (LBRR frames) that carry an encoded representation of the signal immediately preceding the current frame to enable recovery from a lost packet[^15]. Opus decoders also include a packet loss concealment (PLC) function for missing frames[^16]. The codec supports frame durations of 2.5, 5, 10, 20, 40, or 60 ms and scales bitrates from approximately 6 kbit/s narrowband speech up to 510 kbit/s[^14].

## Network Transport and QoS

RFC 3246 recommends codepoint 101110 (decimal 46) for the Expedited Forwarding PHB, intended as a foundation for low-loss, low-delay, and low-jitter transport[^11][^12]. RFC 4594 says the Telephony service class SHOULD use the Expedited Forwarding PHB, characterizing telephony as having very low tolerance to loss, delay, and jitter[^18]. RFC 4594 recommends the Class Selector 5 codepoint for the Signaling service class, which is separate from the EF marking for voice media[^17]. On Cisco IOS voice networks, Cisco recommends IP RTP Priority or Low Latency Queuing so that voice packets are queued ahead of other traffic[^7].

On Wi-Fi networks, RFC 8325 maps EF-marked (telephony) traffic to IEEE 802.11 User Priority 6, which places it in the Voice Access Category (AC_VO)[^50]. However, RFC 8325 notes a common default of deriving 802.11 UP from the 3 most significant DSCP bits, which maps EF voice (101110) to UP 5 and lands in the Video Access Category instead of Voice[^51]. For upstream Wi-Fi traffic, RFC 8325 says client operating systems should use the same DSCP-to-UP mappings as downstream, but packets requesting CS6 or CS7 should be mapped to UP 0 and re-marked to DSCP 0[^49].

Microsoft states that absent QoS, jitter causes missing words or syllables, packet loss lowers voice quality and makes speech hard to understand, and long round-trip time makes people talk over each other[^29]. Microsoft emphasizes that QoS should be implemented on all segments of a managed network, as any part of the path that fails to support QoS priorities can degrade call quality[^31]. For remote users, QoS can be prioritized only within the internal managed network, and a VPN adds packet overhead and delay to real-time traffic[^35]. Microsoft recommends split-tunnel VPNs so that Teams traffic bypasses the VPN and goes directly to Microsoft 365, noting that VPNs are typically not designed for real-time media, some do not support UDP, they add another layer of encryption on already-encrypted media, they can hairpin traffic, and they can route users to a more distant front door, adding latency and jitter[^33][^36]. For Wi-Fi environments, Microsoft recommends QoS or Wi-Fi Multimedia (WMM) to prioritize media, prefers the 5-GHz band (with band steering on dual-band networks), and recommends non-overlapping channels on neighbouring access points[^37].

Microsoft's recommended initial Teams QoS settings mark audio from client source ports 50000-50019 with DSCP 46, video from ports 50020-50039 with DSCP 34, and screen sharing from ports 50040-50059 with DSCP 18[^27]. Teams Mac, iOS, and Android clients use hard-coded DSCP values (EF for audio, AF41 for video and screen sharing), but QoS marking still requires the 'Insert Quality of Service (QoS) markers for real-time media traffic' setting to be enabled in the Teams admin center[^28]. Port-based tagging with router ACLs works across Windows, Mac, and Linux, but marks traffic only at the WAN edge, leading Microsoft to recommend combining client DSCP marking with port-based ACLs[^30]. To validate Teams QoS, Microsoft says to capture traffic, preferably at the network egress point using port mirroring, and confirm that the DSCP value is not changed or stripped as the traffic crosses the network, requiring marking at both ends of the call[^34].

For Webex environments, Webex apps and Cisco video devices use UDP ports 5004 and 9000 for media, with TCP 5004 and then TLS 443 as fallbacks[^43]. Cisco prefers UDP for Webex voice and video media, warning that when media falls back to TCP, retransmission and receiver buffering show up as increased latency and jitter that degrade call quality[^47]. Cisco warns that Webex media sent over TLS through a configured proxy server can create bandwidth bottlenecks and packet loss, and strongly recommends against TLS media transport in production[^48].

## Diagnostic Dashboards and Threshold Differences

In its earlier (classic) experience, Microsoft Teams per-user Call Analytics shows each leg of a call or meeting, with device, network, and connectivity details, listing calls and meetings for the last 30 days[^1]. In Call Analytics session details, yellow items are outside the normal range but unlikely to be the main cause, while red items are significant and likely the main cause of poor quality[^2]. The red item 'Audio network classified poor call' covers packet loss, jitter, NMOS degradation, RTT, or concealed ratio[^2]. Teams Call Quality Dashboard marks an audio stream Poor if Packet Utilization exceeds 500 packets and any one of these holds: average round trip above 500 ms, average packet loss rate above 0.1, or average jitter above 30 ms[^8]. Microsoft states that a CQD Poor audio classification means a network threshold was broken, not that the audio was actually poor or that the user perceived a problem, because the Teams media stack can mitigate considerable network degradation[^9]. CQD marks a stream Unclassified when ICE connectivity fails, when QoE reports are not received (such as when third-party endpoints do not send QoE), on short calls, or on low packet utilization such as a mostly-muted microphone[^10].

Webex Calling call troubleshooting in Control Hub covers calls from the past 21 days and requires the full admin, read-only admin, or support admin role[^39]. Webex Calling troubleshooting in Control Hub grades an endpoint as good when packet loss is under 5%, latency or RTT is under 400 ms, and jitter is under 150 ms[^40]. Webex Calling grades a media relay point (hop) in the Webex cloud as good when packet loss is under 2.5%, latency or RTT is under 200 ms, and jitter is under 75 ms, which are tighter than the endpoint thresholds[^41]. The Webex Calling hop details view shows per-hop send and receive network metrics, along with endpoint IP, codec, and device type, so an admin can tell whether poor quality originates at the caller, the callee, or the cloud path[^42]. Webex Calling troubleshooting offers a minute-by-minute media quality view (latency, packet loss, jitter, bitrate, CPU, and memory) for Webex clients and RoomOS endpoints, which helps locate brief bad periods in long calls[^45]. Webex Calling processes media quality metrics from Cisco devices and from supported third-party Polycom, Yealink, and AudioCodes devices, whereas analog phones and IPv6 endpoints do not provide metrics[^44].

WarmTransfer's reading of the sources is that 'poor quality' thresholds are product-specific classifiers and should not be carried from one platform to another: Teams CQD flags audio at average jitter above 30 ms, while Webex Calling grades an endpoint good below 150 ms jitter and a cloud hop good below 75 ms[^38].

## See also

See also [Echo on VoIP calls](https://warmtransfer.net/knowledge/echo-on-calls).
See also [Webex Calling analytics in Control Hub](https://warmtransfer.net/knowledge/webex-calling-analytics).
See also [SIP trunk carrier turn-up and acceptance testing](https://warmtransfer.net/knowledge/sip-trunk-carrier-turn-up).
See also [QoS marking and queuing for voice](https://warmtransfer.net/knowledge/qos-marking).
See also [SD-WAN considerations for voice](https://warmtransfer.net/knowledge/sdwan-voice).
See also [Firewall ports and IP ranges for cloud calling](https://warmtransfer.net/knowledge/firewall-ports-uc).
See also [Codec selection and bandwidth planning](https://warmtransfer.net/knowledge/bandwidth-codec-planning).
See also [DNS SRV and service discovery for SIP](https://warmtransfer.net/knowledge/dns-srv-voice).
See also [Network readiness assessment for cloud calling](https://warmtransfer.net/knowledge/network-readiness-assessment).
See also [Webex Edge Connect private cloud connectivity](https://warmtransfer.net/knowledge/webex-edge-connect).
See also [Voice VLAN and LLDP-MED and CDP and PoE for IP phones](https://warmtransfer.net/knowledge/voice-vlan-lldp-poe).
See also [UC disaster recovery and business continuity](https://warmtransfer.net/knowledge/uc-disaster-recovery).

## Applicability

Applies to: Microsoft Teams, Cisco IOS voice gateways, IETF RTP, IETF RTCP XR, IETF Opus codec, IETF DiffServ, Cisco IOS routers, IETF DiffServ over Wi-Fi, Cisco Webex, Microsoft Teams admin center Call Analytics, Microsoft Teams Call Quality Dashboard, Cisco Webex Calling (Control Hub troubleshooting), and Microsoft Teams CQD. Deployments: on-premises, multi-tenant, and any. Sources checked 2026-09-25. The playout delay buffer runs in adaptive mode by default on Cisco IOS voice platforms and can be changed with the playout-delay command, including a fixed mode[^3].

## What remains uncertain

Whether third-party session border controllers alter RTCP reception report intervals or suppress RTCP XR blocks is not covered by the sources below.

How local operating system scheduling affects jitter buffer sizing across desktop clients is not covered by the sources below.

## Sources

[^1]: Teams per-user Call Analytics shows each leg of a call or meeting, with device, network and connectivity details, so an admin can isolate the problem area. It lists the user's calls and meetings for the last 30 days. Source: [Use Call Analytics to troubleshoot poor call quality](https://learn.microsoft.com/en-us/microsoftteams/use-call-analytics-to-troubleshoot-poor-call-quality), Sections 'Introduction to Call Analytics' and 'Where to find per-user Call Analytics'. Checked 2026-09-25.
[^2]: In Teams Call Analytics session details, yellow items are outside the normal range but unlikely to be the main cause, while red items are significant and likely the main cause of poor quality. 'Audio network classified poor call' covers packet loss, jitter, NMOS degradation, RTT or concealed ratio. Source: [Use Call Analytics to troubleshoot poor call quality](https://learn.microsoft.com/en-us/microsoftteams/use-call-analytics-to-troubleshoot-poor-call-quality), Section 'Troubleshoot user call quality problems', step 5 and the issues table. Checked 2026-09-25.
[^3]: The Cisco IOS playout delay buffer runs in adaptive mode by default, adjusting to the jitter present up to a point. It can be changed with the playout-delay command, including a fixed mode. Source: [Understanding Jitter in Packet Voice Networks (Cisco IOS Platforms)](https://www.cisco.com/c/en/us/support/docs/voice/voice-quality/18902-jitter-packet-voice.html), Section 'Determine the Severity of Jitter'. Checked 2026-09-25.
[^4]: On Cisco IOS voice gateways, the 'Buf Overflow Discard (ms)' counter in the DSP VOICE VP_ERROR statistics counts packets that fell outside the playout buffer and were dropped. A nonzero value is acceptable, but it should not keep increasing during a call. Source: [Understanding Jitter in Packet Voice Networks (Cisco IOS Platforms)](https://www.cisco.com/c/en/us/support/docs/voice/voice-quality/18902-jitter-packet-voice.html), Section 'Determine the Severity of Jitter' (show voice call output). Checked 2026-09-25.
[^5]: On Cisco IOS voice gateways, the playout (de-jitter) buffer discards packets that arrive outside its range, and dropouts are then heard in the audio. The DSP can interpolate over small losses, but problems become audible when jitter exceeds what it can compensate. Source: [Understanding Jitter in Packet Voice Networks (Cisco IOS Platforms)](https://www.cisco.com/c/en/us/support/docs/voice/voice-quality/18902-jitter-packet-voice.html), Section 'Jitter in Packet Voice Networks'. Checked 2026-09-25.
[^6]: Cisco defines jitter as a variation in the delay of received packets, caused for example by network congestion, improper queuing or configuration errors. Source: [Understanding Jitter in Packet Voice Networks (Cisco IOS Platforms)](https://www.cisco.com/c/en/us/support/docs/voice/voice-quality/18902-jitter-packet-voice.html), Section 'Jitter in Packet Voice Networks'. Checked 2026-09-25.
[^7]: Cisco's jitter guidance for IOS voice networks recommends IP RTP Priority or Low Latency Queuing so that voice packets are queued ahead of other traffic. Source: [Understanding Jitter in Packet Voice Networks (Cisco IOS Platforms)](https://www.cisco.com/c/en/us/support/docs/voice/voice-quality/18902-jitter-packet-voice.html), Section 'Queueing'. Checked 2026-09-25.
[^8]: Teams Call Quality Dashboard marks an audio stream Poor if Packet Utilization exceeds 500 packets and any one of these holds: average round trip above 500 ms, average packet loss rate above 0.1, or average jitter above 30 ms. Source: [Stream classification in Call Quality Dashboard (CQD)](https://learn.microsoft.com/en-us/microsoftteams/stream-classification-in-call-quality-dashboard), Section 'Classifier Definitions', subsection 'Audio Classifier' (table). Checked 2026-09-25.
[^9]: Microsoft states that a CQD Poor audio classification means a network threshold was broken, not that the audio was actually poor or that the user perceived a problem, because the Teams media stack can mitigate considerable network degradation. Source: [Stream classification in Call Quality Dashboard (CQD)](https://learn.microsoft.com/en-us/microsoftteams/stream-classification-in-call-quality-dashboard), Section 'Audio Classifier', Note below the table. Checked 2026-09-25.
[^10]: CQD marks a stream Unclassified when ICE connectivity fails, when QoE reports are not received (e.g. some third-party endpoints do not send QoE), on short calls, or on low packet utilization such as a mostly-muted microphone. Source: [Stream classification in Call Quality Dashboard (CQD)](https://learn.microsoft.com/en-us/microsoftteams/stream-classification-in-call-quality-dashboard), Section 'Unclassified Streams'. Checked 2026-09-25.
[^11]: RFC 3246 recommends codepoint 101110 (decimal 46) for the Expedited Forwarding PHB. Source: [RFC 3246: An Expedited Forwarding PHB (Per-Hop Behavior)](https://www.rfc-editor.org/rfc/rfc3246), Section 2.7 'Recommended codepoint for this PHB'. Checked 2026-09-25.
[^12]: The EF PHB is intended as a building block for low-loss, low-delay and low-jitter services. Source: [RFC 3246: An Expedited Forwarding PHB (Per-Hop Behavior)](https://www.rfc-editor.org/rfc/rfc3246), Section 1 'Introduction'. Checked 2026-09-25.
[^13]: Standard RTCP loss counters (fraction lost, cumulative lost) count packets that never arrived, while packets that arrive too late for the jitter buffer are reported separately as discards in RTCP XR. A call can therefore sound choppy while basic RTCP shows little loss, and heavy jitter should be checked in that case (inferred). Source: [RFC 3611: RTP Control Protocol Extended Reports (RTCP XR)](https://www.rfc-editor.org/rfc/rfc3611), Section 4.7 (loss rate vs discard rate), read together with RFC 3550 Section 6.4.1. Checked 2026-09-25.
[^14]: Opus can encode frames of 2.5, 5, 10, 20, 40 or 60 ms and scales from about 6 kbit/s narrowband speech up to 510 kbit/s. Source: [RFC 6716: Definition of the Opus Audio Codec](https://www.rfc-editor.org/rfc/rfc6716), Section 2.1.4 'Frame Duration'; Section 1 (bitrate range). Checked 2026-09-25.
[^15]: Opus defines optional in-band redundancy (LBRR frames) that, when present, carry an encoded representation of the signal immediately before the current frame, allowing recovery from a lost packet. Source: [RFC 6716: Definition of the Opus Audio Codec](https://www.rfc-editor.org/rfc/rfc6716), Section 4.2.5 'LBRR Frames'. Checked 2026-09-25.
[^16]: The Opus specification includes a packet loss concealment (PLC) function in the decoder for missing packets. Source: [RFC 6716: Definition of the Opus Audio Codec](https://www.rfc-editor.org/rfc/rfc6716), Section 4.4 'Packet Loss Concealment (PLC)'. Checked 2026-09-25.
[^17]: RFC 4594 recommends the Class Selector 5 (CS5) codepoint for the Signaling service class, which is separate from the EF marking for voice media. Source: [RFC 4594: Configuration Guidelines for DiffServ Service Classes](https://www.rfc-editor.org/rfc/rfc4594), Section 4.2 'Signaling'. Checked 2026-09-25.
[^18]: RFC 4594 (Informational) says the Telephony service class SHOULD use the Expedited Forwarding PHB, and it characterizes telephony as having very low tolerance to loss, delay and jitter. Source: [RFC 4594: Configuration Guidelines for DiffServ Service Classes](https://www.rfc-editor.org/rfc/rfc4594), Section 4.1 'Telephony'; Figure 2 (service class characteristics). Checked 2026-09-25.
[^19]: RFC 3550 recommends that the fraction of session bandwidth added for RTCP be fixed at 5%. Source: [RFC 3550: RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550), Section 6.2 'RTCP Transmission Interval'. Checked 2026-09-25.
[^20]: An RTCP reception report block carries a 24-bit cumulative number of packets lost since reception began, in addition to the per-interval fraction lost. Source: [RFC 3550: RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550), Section 6.4.1, report block field 'cumulative number of packets lost'. Checked 2026-09-25.
[^21]: In an RTCP reception report block, the 8-bit 'fraction lost' field is the fraction of RTP data packets from the source lost since the previous SR or RR was sent, expressed as a fixed-point number with the binary point at the left edge. Source: [RFC 3550: RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550), Section 6.4.1 (SR: Sender Report RTCP Packet), report block field 'fraction lost'; reused by RR per Section 6.4.2. Checked 2026-09-25.
[^22]: RFC 3550 computes interarrival jitter as a running estimate smoothed with gain 1/16: J(i) = J(i-1) + (|D(i-1,i)| - J(i-1))/16, where D is the difference in packet spacing at the receiver compared with the sender. Source: [RFC 3550: RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550), Section 6.4.1 (interarrival jitter definition) and Appendix A.8 'Estimating the Interarrival Jitter'. Checked 2026-09-25.
[^23]: RFC 3550's guidance on analyzing reports treats packet loss as tracking persistent congestion and interarrival jitter as tracking transient congestion, so rising jitter can indicate congestion before it becomes loss. Source: [RFC 3550: RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550), Section 6.4.4 'Analyzing Sender and Receiver Reports'. Checked 2026-09-25.
[^24]: The RTCP interarrival jitter field is a 32-bit estimate of the statistical variance of RTP packet interarrival time, measured in RTP timestamp units rather than milliseconds. Source: [RFC 3550: RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550), Section 6.4.1, report block field 'interarrival jitter'. Checked 2026-09-25.
[^25]: RFC 3550 states that sending reception feedback to all participants lets someone observing problems evaluate whether those problems are local or global, which is the basis for comparing reports from different receivers to localize a bad segment. Source: [RFC 3550: RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550), Section 6 'RTP Control Protocol -- RTCP', function 1 (feedback on quality of data distribution). Checked 2026-09-25.
[^26]: RFC 3550 recommends a fixed minimum RTCP reporting interval of 5 seconds. Source: [RFC 3550: RTP: A Transport Protocol for Real-Time Applications](https://www.rfc-editor.org/rfc/rfc3550), Section 6.2 'RTCP Transmission Interval'. Checked 2026-09-25.
[^27]: Microsoft's recommended initial Teams QoS settings mark audio from client source ports 50000-50019 with DSCP 46 (EF). Video uses 50020-50039 with DSCP 34 (AF41), and screen sharing uses 50040-50059 with DSCP 18 (AF21). Source: [Implement Quality of Service in Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/qos-in-teams), Step 3 'Choose initial port ranges for each media type', table 'Recommended initial port ranges'. Checked 2026-09-25.
[^28]: Teams Mac, iOS and Android clients use hard-coded DSCP values (EF for audio, AF41 for video and screen sharing), but QoS marking still requires the 'Insert Quality of Service (QoS) markers for real-time media traffic' setting to be enabled in the Teams admin center. Source: [Implement Quality of Service in Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/qos-in-teams), Step 4 'Implement QoS settings', bullets on Mac and mobile clients. Checked 2026-09-25.
[^29]: Microsoft describes the effects of missing QoS as follows: jitter causes missing words or syllables, packet loss lowers voice quality and makes speech hard to understand, and long round-trip time makes people talk over each other. Source: [Implement Quality of Service in Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/qos-in-teams), Introduction, list following 'Without some form of QoS'. Checked 2026-09-25.
[^30]: Microsoft notes that port-based DSCP tagging with router ACLs works across Windows, Mac and Linux, but marks traffic only at the WAN edge, not all the way to the client. It recommends combining client DSCP marking with port-based ACLs. Source: [Implement Quality of Service in Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/qos-in-teams), Step 2 'Select a QoS implementation method', subsections 'Port-based tagging at router' and 'Best practice'. Checked 2026-09-25.
[^31]: Microsoft says QoS should be implemented on all segments of a managed network, and that any part of the path that fails to support the QoS priorities can degrade call quality. Source: [Implement Quality of Service in Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/qos-in-teams), Introduction (paragraph beginning 'For QoS to be effective'). Checked 2026-09-25.
[^32]: Microsoft's Teams network guidance lists calls that have static, cut out, or make voices sound like robots as a symptom that could be caused by jitter or packet loss, and as a reason to do network optimization. Source: [Prepare your organization's network for Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/prepare-network), Section 'Network optimization', bullet list of reasons for other optimization. Checked 2026-09-25.
[^33]: Microsoft recommends a split-tunnel VPN so that Teams traffic bypasses the VPN and goes directly to Microsoft 365. Source: [Prepare your organization's network for Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/prepare-network), Section 'Network optimization', table row 'Configure split-tunnel VPN'. Checked 2026-09-25.
[^34]: To validate Teams QoS, Microsoft says to capture traffic, preferably at the network egress point using port mirroring, and confirm that the DSCP value is not changed or stripped as the traffic crosses the network. The marking must be present at both ends of the call. Source: [Implement Quality of Service in Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/qos-in-teams), Step 5 'Validate your QoS implementation'. Checked 2026-09-25.
[^35]: Microsoft notes that QoS works as expected only when implemented on all links between callers. For a remote user, QoS can be prioritized only within the internal managed network, and a VPN adds packet overhead and delay to real-time traffic. Source: [Implement Quality of Service in Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/qos-in-teams), Step 1 'Make sure your network is ready', subsection 'VPN considerations'. Checked 2026-09-25.
[^36]: Microsoft gives these reasons to keep Teams media off the VPN: VPNs are typically not designed for real-time media, some do not support UDP, they add another layer of encryption on already-encrypted media, they can hairpin traffic, and they can route users to a more distant front door, adding latency and jitter. Source: [Prepare your organization's network for Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/prepare-network), Section 'Network optimization', table row 'Configure split-tunnel VPN', list 'Other reasons why we recommend bypassing the VPN'. Checked 2026-09-25.
[^37]: For Wi-Fi, Microsoft recommends QoS or Wi-Fi Multimedia (WMM) to prioritize media, prefers the 5-GHz band (with band steering on dual-band networks), and recommends non-overlapping channels on neighbouring access points. Source: [Prepare your organization's network for Microsoft Teams](https://learn.microsoft.com/en-us/microsoftteams/prepare-network), Section 'Network optimization', table row 'Optimize WiFi'. Checked 2026-09-25.
[^38]: 'Poor quality' thresholds are product-specific classifiers and should not be carried from one platform to another: Teams CQD flags audio at average jitter above 30 ms, while Webex Calling grades an endpoint good below 150 ms jitter and a cloud hop good below 75 ms (inferred). Source: [Stream classification in Call Quality Dashboard (CQD)](https://learn.microsoft.com/en-us/microsoftteams/stream-classification-in-call-quality-dashboard), Audio Classifier table, compared with Webex Calling endpoint and hop thresholds. Checked 2026-09-25.
[^39]: Webex Calling call troubleshooting in Control Hub covers calls from the past 21 days and 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), Prerequisites section. Checked 2026-09-25.
[^40]: Webex Calling troubleshooting in Control Hub grades an endpoint as good when packet loss is under 5%, 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), Media quality thresholds for endpoints (section describing good vs poor grading). Checked 2026-09-25.
[^41]: Webex Calling grades a media relay point (hop) in the Webex cloud as good when packet loss is under 2.5%, latency or RTT is under 200 ms, and jitter is under 75 ms. These limits are tighter than the endpoint thresholds. Source: [Troubleshoot Webex Calling calls in Control Hub](https://help.webex.com/en-us/article/frj1efb/Troubleshoot-Webex-Calling-Media-Quality-in-Control-Hub), Hop details / media relay point thresholds. Checked 2026-09-25.
[^42]: The Webex Calling hop details view shows per-hop send and receive network metrics, along with endpoint IP, codec and device type, so an admin can tell whether poor quality originates at the caller, the callee or the cloud path. Source: [Troubleshoot Webex Calling calls in Control Hub](https://help.webex.com/en-us/article/frj1efb/Troubleshoot-Webex-Calling-Media-Quality-in-Control-Hub), Hop details section. Checked 2026-09-25.
[^43]: Webex apps and Cisco video devices use UDP ports 5004 and 9000 for media, with TCP 5004 and then TLS 443 as fallbacks. Source: [Network Requirements for Webex Services](https://help.webex.com/en-us/article/WBX000028782/Network-Requirements-for-Webex-Services), Media ports table for Webex App and Cisco Video Devices. Checked 2026-09-25.
[^44]: Webex Calling processes media quality metrics from Cisco devices and from supported third-party Polycom, Yealink and AudioCodes devices. Analog phones and IPv6 endpoints do not provide metrics. Source: [Troubleshoot Webex Calling calls in Control Hub](https://help.webex.com/en-us/article/frj1efb/Troubleshoot-Webex-Calling-Media-Quality-in-Control-Hub), Supported devices / limitations section. Checked 2026-09-25.
[^45]: Webex Calling troubleshooting offers a minute-by-minute media quality view (latency, packet loss, jitter, bitrate, CPU and memory) for Webex clients and RoomOS endpoints, which helps locate brief bad periods in long calls. 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-25.
[^46]: The Webex services network requirements page, as fetched on 2026-09-25, contains no section on QoS or DSCP marking and no guidance on VPN or split tunnelling for media (inferred). Source: [Network Requirements for Webex Services](https://help.webex.com/en-us/article/WBX000028782/Network-Requirements-for-Webex-Services), Whole document (absence check). Checked 2026-09-25.
[^47]: Cisco prefers UDP for Webex voice and video media. When media falls back to TCP, retransmission and receiver buffering show up as increased latency and jitter that degrade call quality. Source: [Network Requirements for Webex Services](https://help.webex.com/en-us/article/WBX000028782/Network-Requirements-for-Webex-Services), Section on media transport protocols (UDP preferred; TCP and TLS fallback). Checked 2026-09-25.
[^48]: Cisco warns that Webex media sent over TLS through a configured proxy server can create bandwidth bottlenecks and packet loss, and strongly recommends against TLS media transport in production. Source: [Network Requirements for Webex Services](https://help.webex.com/en-us/article/WBX000028782/Network-Requirements-for-Webex-Services), Section on media transport protocols (TLS as last resort). Checked 2026-09-25.
[^49]: For upstream Wi-Fi traffic, RFC 8325 says client operating systems should use the same DSCP-to-UP mappings as downstream, but packets requesting CS6 or CS7 should be mapped to UP 0 and re-marked to DSCP 0. Source: [RFC 8325: Mapping Diffserv to IEEE 802.11](https://www.rfc-editor.org/rfc/rfc8325), Section 5.1 'Upstream DSCP-to-UP Mapping within the Wireless Client Operating System'. Checked 2026-09-25.
[^50]: RFC 8325 maps EF-marked (telephony) traffic to IEEE 802.11 User Priority 6, which places it in the Voice Access Category (AC_VO). Source: [RFC 8325: Mapping Diffserv to IEEE 802.11](https://www.rfc-editor.org/rfc/rfc8325), Section 4.2.1 'Telephony'. Checked 2026-09-25.
[^51]: RFC 8325 identifies a common default of deriving 802.11 UP from the three most significant DSCP bits. Under that default, EF voice (101110) maps to UP 5 and lands in the Video Access Category instead of Voice. Source: [RFC 8325: Mapping Diffserv to IEEE 802.11](https://www.rfc-editor.org/rfc/rfc8325), Section 2.3 'Default DSCP-to-UP Mappings and Conflicts'. Checked 2026-09-25.
[^52]: The RTCP XR VoIP Metrics block reports a discard rate, separate from loss rate: the fraction of RTP packets discarded because of late or early arrival, or under-run or overflow at the receiving jitter buffer. Source: [RFC 3611: RTP Control Protocol Extended Reports (RTCP XR)](https://www.rfc-editor.org/rfc/rfc3611), Section 4.7 'VoIP Metrics Report Block', field 'discard rate'. Checked 2026-09-25.
[^53]: The RTCP XR VoIP Metrics block also carries burst and gap density and duration, round-trip delay, end-system delay (which includes jitter buffer delay), an R factor, MOS-LQ, MOS-CQ, and jitter buffer nominal, maximum and absolute-maximum delay. Source: [RFC 3611: RTP Control Protocol Extended Reports (RTCP XR)](https://www.rfc-editor.org/rfc/rfc3611), Section 4.7 'VoIP Metrics Report Block' (field list). Checked 2026-09-25.