# VDI Media Redirection in Amazon Connect: How It Really Works

Amazon Connect's support for Azure Virtual Desktop and Windows 365 via Microsoft Multimedia Redirection looks simple on the surface, but it hides a media routing decision chain with serious implications for latency, security, and compliance. In this article I dissect the mechanism layer by layer, expose the failure modes the documentation doesn't mention, and offer a design model for high-demand financial environments.

- URL: https://fernando.moretes.com/blog/redirecionamento-de-midia-vdi-no-amazon-connect-como-realmente-funcion-amazon-conne

- Markdown: https://fernando.moretes.com/blog/redirecionamento-de-midia-vdi-no-amazon-connect-como-realmente-funcion-amazon-conne/article.md?lang=en

- Published: 2026-07-26T09:03:11.026Z

- Category: AI & Agents

- Tags: amazon-connect, vdi, webrtc, azure-virtual-desktop, media-redirection, contact-center, financial-grade, observability

- Reading time: 10 min

- Source: [Amazon Connect now supports audio optimization for Azure Virtual Desktop and Windows 365 Cloud PC](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-connect/)

---

When a contact center agent operates inside a virtual desktop, every voice packet travels a path most architects never explicitly drew: from the local microphone, through the VDI client, through the remoting protocol, up to the session host in the cloud, and only then to Amazon Connect's WebRTC endpoint. The result is double audio encoding, accumulated latency, and jitter that no call-quality SLA survives. The Azure Virtual Desktop and Windows 365 support announced in July 2026 solves this via Microsoft Multimedia Redirection — but the solution creates its own set of invariants that need rigorous management in financial-grade environments.

## The Fundamental Problem: Two Competing Media Paths

In a VDI deployment without optimization, audio follows the remoting protocol path — RDP in the AVD case. The microphone captures PCM at the local endpoint, the RDP client compresses and transmits that audio to the session host, where the browser or agent application receives it, processes it via WebRTC, and sends it to Amazon Connect's media servers. In the reverse direction, the customer's audio arrives at Connect, descends via WebRTC to the session host, is recompressed by RDP, and played through the local speaker. Each hop adds between 20 ms and 60 ms of latency, and the double transcoding — typically Opus in WebRTC plus the RDP codec, such as G.722 or SILK — degrades quality in a measurable way. In financial contact center environments where call recording, real-time sentiment analysis via Amazon Connect Contact Lens, and voice fraud detection are operational requirements, that degradation is not cosmetic: it compromises the accuracy of the ML models that process audio downstream.

Microsoft Multimedia Redirection (MMR) breaks this cycle by intercepting the media pipeline before it enters the RDP channel. Instead of letting audio ascend to the session host, MMR instructs the browser on the session host to negotiate the WebRTC session directly with the Amazon Connect endpoint, but redirects the actual media processing — capture, encoding, decoding, rendering — to the agent's local device. The session host becomes a signaling proxy, not a media proxy. This is the central insight that makes the feature functionally equivalent to running the softphone directly on the physical endpoint, with the difference that the application context and agent identity remain on the managed virtual desktop.

## Media Flow: With and Without MMR Redirection

Comparison of the two media paths — the degraded path via RDP protocol versus the optimized path via MMR with direct WebRTC to Amazon Connect.

### 🧑 Agent Endpoint (Local Device)

- Microphone + Speaker (user)
- AVD / W365 RDP Client (edge)
- MMR Browser Plugin (local) (compute)

### ☁️ Azure Session Host (VDI)

- Session Host Browser + CCP (compute)
- MMR Host Extension (compute)

### 🔒 Signaling Plane

- WebRTC Signaling (DTLS) (network)

### 📞 Amazon Connect (AWS)

- Connect Media Servers (SRTP) (messaging)
- Contact Lens Real-time Audio (ai)
- Connect Streams JS Library (frontend)

### Flows

- mic -> vdi_client: Raw PCM (no MMR)
- vdi_client -> session_host: RDP codec (G.722/SILK) — degraded path
- session_host -> connect_media: WebRTC/Opus — double transcode
- mic -> mmr_plugin: Locally captured PCM
- mmr_plugin -> webrtc_sig: Negotiates WebRTC session via MMR
- session_host -> mmr_host: Intercepts media pipeline
- mmr_host -> webrtc_sig: Redirected signaling
- webrtc_sig -> connect_media: Direct SRTP endpoint→Connect
- connect_media -> contact_lens: Clean audio stream
- connect_streams -> session_host: CCP UI / custom workspace

## How MMR Works in Depth: Signaling vs. Media Plane

Microsoft Multimedia Redirection operates on two distinct layers that are essential not to confuse. The **signaling layer** remains on the session host: the browser on AVD runs Amazon Connect Streams JavaScript, establishes the session with Amazon Connect, negotiates ICE/DTLS parameters, and receives call control events. None of this changes with MMR active. What changes is the **media layer**: when MMR detects that the WebRTC context is running on a session host with a compatible client connected, it injects a virtual device driver on the local endpoint and redirects the SRTP streams so they originate and arrive directly on the agent's physical device, without transiting the session host.

From Amazon Connect's perspective, the call looks identical to any normal WebRTC call. SRTP packets arrive from the local endpoint's IP, the DTLS handshake is resolved locally, and the Opus codec operates on audio samples captured without intermediaries. The critical operational difference is that **the session host never processes real-time voice audio** — it only maintains application state and the control session. This has direct implications for session host sizing: in deployments without MMR, each simultaneous agent consumes DSP CPU on the host for real-time audio encoding/decoding, which is frequently the bottleneck for agent density per VM. With MMR, that cost disappears from the host and is absorbed by the local endpoint, which typically has idle capacity.

The administrative setup is described in the documentation as a one-time process per VDI environment, involving installing the MMR extension in Edge/Chrome on the session host and configuring Group Policy or Intune to enable redirection. Amazon Connect requires no additional configuration on the AWS side — the feature is transparent to the Connect control plane.

> **The Session Host Becomes a Signaling Proxy, Not a Media Proxy:** This distinction is the heart of the feature. When MMR is active, the session host processes only WebRTC control bytes — ICE candidates, SDP offers/answers, DTMF events — while the actual SRTP stream never touches the host. For VM sizing in AVD, this means the CPU metric relevant for capacity planning shifts from 'audio codec load per agent' to 'CCP JavaScript overhead per agent', which is an order of magnitude smaller. In practical terms: a D4s_v5 VM that supported 8 agents without MMR can support 20-25 agents with MMR active, depending on the complexity of the custom agent interface.

## Failure Modes: What Happens When MMR Is Unavailable

The most important and least documented failure mode is **silent fallback**. When MMR cannot establish redirection — whether because the plugin is not installed on the local client, because the RDP client version is incompatible, or because network policies block direct communication between the endpoint and Connect's media servers — the browser on the session host simply continues operating in non-optimized mode. The agent can take calls, but with the degraded quality of the RDP path. There is no visible alert in the CCP interface, no event in Connect's CloudWatch Metrics, and no log in Contact Lens indicating that audio was processed through the slow path.

This creates a serious observability problem in financial contact centers: you may have a fraction of your agents operating with degraded audio quality without knowing it. The only reliable way to detect this is to monitor the origin of SRTP packets in Connect's call metrics. When MMR is active, the source IP of media packets is the agent's local endpoint IP. When inactive, the source IP is the session host IP in Azure. This distinction can be captured via Amazon Connect Contact Trace Records (CTRs), specifically in the `MediaStreams` field, and correlated with the session host inventory to identify agents operating in degraded mode.

Another relevant failure mode is **redirection loss during a call**. If the RDP session is interrupted and reconnected while a call is active — a common scenario on unstable networks or when the agent locks and unlocks the workstation — MMR may not be able to re-establish redirection without restarting the WebRTC context. The result is a call that starts with optimized audio and switches to the RDP path mid-conversation, with a 200-500 ms audio glitch during the transition. In financial environments with mandatory call recording, this glitch can create gaps in the recording that need to be documented for compliance purposes.

## Security and Compliance Implications in Financial Environments

MMR media redirection fundamentally changes the threat model of a contact center deployment. In the non-optimized model, all audio transits the managed session host, which is within Azure's control perimeter — with DLP policies, activity logging, and potentially within the scope of certifications like PCI DSS or SOC 2. With MMR active, the SRTP stream goes directly from the agent's local device to Amazon Connect's media servers, **completely bypassing the session host perimeter**.

For regulated environments, this requires an explicit review of the control model. The agent's local device needs to be considered part of the compliance scope — which in contact centers with remote agents or BYOD can be problematic. The questions that need to be answered before enabling MMR in production include: (1) Is the local endpoint within the scope of the corporate DLP program? (2) Does SRTP traffic leaving directly from the local endpoint pass through security inspection or go straight to the internet? (3) Does Connect's call recording policy capture audio before or after the entry point into the media servers? The answer to (3) is that Connect records audio on its own media servers, regardless of the arrival path — so recording is not affected by MMR. But (1) and (2) are the responsibility of the organization's security architect, not Connect.

From an encryption standpoint, SRTP with DTLS-SRTP is the WebRTC standard and is present in both paths. The difference is that in the non-MMR path, there is an additional non-SRTP segment between the local endpoint and the session host, protected by the RDP protocol's TLS — which may have cipher suite configurations different from corporate policies. With MMR, that segment disappears and the entire audio encryption chain is DTLS-SRTP end-to-end between the endpoint and Connect.

## Common Anti-Patterns in MMR Deployment with Amazon Connect

- **Assuming MMR is active without validation**: Enabling the feature in the AVD environment and presuming all agents are on the optimized path without monitoring source IPs in CTRs. Silent fallback is the default failure mode.
- **Ignoring the compliance scope of the local endpoint**: Treating media redirection as a purely technical change without reviewing whether the agent's local device is within PCI/SOC 2 scope. In financial contact centers, this can create an undetected control violation.
- **Not testing RDP reconnection behavior during active calls**: Validating only the happy path (MMR active from call start) without testing what happens when the RDP session is interrupted and restored mid-call.
- **Sizing session hosts based on benchmarks without MMR**: Using CPU metrics from existing non-MMR deployments to plan capacity for new deployments, drastically underestimating the agent density per VM possible with MMR.
- **Blocking UDP traffic from local endpoint to Connect media servers**: Configuring local firewalls or corporate proxies that force WebRTC traffic over TCP, eliminating MMR's latency benefits and potentially causing worse degradation than the original RDP path.
- **Using outdated AVD client versions**: MMR support requires specific versions of the Windows App or Azure Virtual Desktop client. Keeping endpoints on old versions due to conservative update policies results in silent fallback without clear diagnostics.

## Well-Architected Lenses for MMR in Amazon Connect

- **security**: Review the threat model to include the agent's local endpoint as an attack surface when MMR is active. Ensure MDM/Intune policies cover local devices with the same controls applied to the session host. Validate that SRTP traffic from the local endpoint passes through DNS inspection and does not bypass corporate security proxies. Explicitly document in the PCI/SOC 2 control model that the audio stream does not transit the session host.
- **reliability**: Implement active MMR mode monitoring via CTR analysis in S3 with Athena queries on the MediaStreams field. Configure CloudWatch alarms for deviations in the media source IP distribution. Test RDP reconnection procedures with active calls in staging before production. Define separate SLOs for MMR-optimized calls vs. fallback calls.
- **performance**: Re-size session hosts based on benchmarks with MMR active, using CCP JavaScript CPU metric as the capacity driver instead of audio codec load. Monitor MOS scores via Contact Lens to validate quality gains in production. Configure QoS policies on the local endpoint to prioritize UDP traffic on port 3478 (STUN/TURN) and Connect's media port ranges.

## End-to-End Observability: Closing the Audio Quality Loop

Audio quality observability in contact centers with VDI is historically a blind spot. Amazon Connect exposes call quality metrics via CloudWatch — including `VoiceCallsAttempted`, `VoiceCallsConnected`, and duration metrics — but does not directly expose media quality metrics like MOS score or per-call packet loss. Contact Lens fills part of this gap by analyzing transcribed audio, but its sensitivity to codec issues is limited when degradation is subtle.

The approach I recommend for financial environments is a three-layer observability pipeline. **Layer 1 — Mode detection**: A Lambda function triggered by the contact completion event in EventBridge processes the CTR stored in S3, extracts the `MediaStreams.Customer.Type` field and media source IP, and publishes a custom CloudWatch metric indicating whether the call was MMR-optimized or not. This feeds an Operational dashboard showing the percentage of calls on the optimized path per agent, per routing group, and per AVD region.

**Layer 2 — Audio quality**: Enable Contact Lens for all calls and monitor the `InterruptionsPercentage` and `NonTalkTime` metrics as indirect proxies for audio issues — calls with glitches tend to have more unintentional silences and more interruptions. Create a CloudWatch alarm that fires when the `NonTalkTime` average of an AVD agent group exceeds 2 standard deviations from the historical baseline.

**Layer 3 — Incident correlation**: Integrate RDP reconnection events from Azure Monitor with Connect CTRs via a correlation table in DynamoDB, using `AgentId` as the partition key and call start timestamp as the sort key. When an agent reports an audio issue, the support runbook queries this table to check whether there was an RDP reconnection during the call — which immediately points to the mid-call redirection loss failure mode.

## Comparison: VDI Platforms Supported by Amazon Connect
| Criterion | VDI Platform | Redirection Mechanism | Admin Setup | Detectable Fallback? | Local Compliance Scope |
| --- | --- | --- | --- | --- | --- |
| Amazon WorkSpaces | Native AWS WebRTC Redirection | Config via WorkSpaces console | Yes, via CloudWatch WorkSpaces | AWS-managed — defined scope | — |
| Azure Virtual Desktop / Windows 365 | Microsoft Multimedia Redirection (MMR) | One-time: extension + GPO/Intune | Only via CTR analysis (manual) | Local endpoint enters scope | — |
| Citrix Cloud Desktops | Citrix HDX RealTime Optimization Pack | Citrix plugin install on endpoint | Via Citrix Director + CTR correlation | Local endpoint enters scope | — |
| Omnissa (VMware Horizon) Cloud Desktops | Omnissa Horizon Media Optimization | Horizon Client + admin policy | Via Horizon Console + CTR correlation | Local endpoint enters scope | — |

> **Architect's Note: What I Would Do Differently:** In every financial contact center project with VDI I've been part of, the audio quality problem only became a priority after a customer complaint — never before. What I would do from day zero is instrument MMR mode detection via CTRs and create an explicit SLO: '95% of calls must be MMR-optimized'. This transforms an invisible infrastructure issue into a monitored service indicator. The second lesson learned the hard way: never enable MMR in production without first validating that agents' local endpoints have direct UDP access to Connect's media server IP ranges — most rollout problems I've seen were caused by corporate firewalls silently blocking UDP and forcing fallback to TCP or the RDP path. Finally, treat the local endpoint compliance review as a non-negotiable prerequisite, not a post-deployment afterthought.

## Verdict: Solid Feature, But Requires Deliberate Observability Engineering

Amazon Connect's support for Azure Virtual Desktop and Windows 365 via MMR is technically well-grounded and solves a real audio quality problem that affects the operational effectiveness of contact centers with distributed workforces. The approach of redirecting only the media plane while keeping the control plane on the session host is the correct design decision — it preserves the value of VDI (centralized management, application security) while eliminating the latency bottleneck.

However, the feature is not plug-and-play in regulated financial environments. Silent fallback without native observability, the change in local endpoint compliance scope, and the undocumented behavior during mid-call RDP reconnections are real risks that need deliberate mitigation. The recommendation is: enable MMR, but invest proportionally in three things before production rollout — endpoint UDP connectivity validation, CTR instrumentation for mode detection, and formal review of the compliance control model. For organizations already operating with WorkSpaces, the observability pattern is more mature; for AVD VDI newcomers, the investment in observability is the differentiator between a successful deployment and one that generates support tickets indefinitely.

**Rating:** Recommended with conditions

## References

- [Amazon Connect: Audio Optimization for Azure Virtual Desktop and Windows 365 (What's New, Jul 2026)](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-connect/)
- [Amazon Connect Administrator Guide: Using CCP with Azure Virtual Desktop (Step-by-Step)](https://docs.aws.amazon.com/connect/latest/adminguide/using-ccp-vdi-azure-step-by-step.html)
- [Amazon Connect Release Notes — June 2026: MMR for AVD and Windows 365](https://docs.aws.amazon.com/connect/latest/adminguide/amazon-connect-release-notes.html)
- [Amazon Connect Administrator Guide: Audio Optimization for Amazon WorkSpaces](https://docs.aws.amazon.com/en_us/connect/latest/adminguide/using-ccp-vdi-workspaces.html)
- [Amazon Connect Streams (Open Source JavaScript Library — GitHub)](https://github.com/amazon-connect/amazon-connect-streams)
- [Microsoft Multimedia Redirection for Azure Virtual Desktop — Microsoft Docs](https://learn.microsoft.com/en-us/azure/virtual-desktop/multimedia-redirection-intro)
- [AWS Well-Architected Framework — Operational Excellence Pillar](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/welcome.html)
- [Amazon Connect Contact Trace Records Data Model](https://docs.aws.amazon.com/connect/latest/adminguide/ctr-data-model.html)