# Amazon Connect + AVD/Windows 365: Otimização de Áudio em VDI

A AWS anunciou suporte a otimização de áudio do Amazon Connect para Azure Virtual Desktop (AVD) e Windows 365 Cloud PC via Microsoft Multimedia Redirection (MMR), expandindo uma capacidade já existente para WorkSpaces, Citrix e Omnissa. O mecanismo redireciona o processamento de mídia do session host para o dispositivo local do agente, reduzindo latência e melhorando qualidade de voz em ambientes VDI heterogêneos. Neste artigo, avalio o que essa feature entrega de fato, onde ela falha, e como integrá-la em arquiteturas de contact center financeiro-grade.

- URL: https://fernando.moretes.com/blog/amazon-connect-avd-windows-365-otimizacao-de-audio-em-vdi-amazon-conne

- Markdown: https://fernando.moretes.com/blog/amazon-connect-avd-windows-365-otimizacao-de-audio-em-vdi-amazon-conne/article.md?lang=pt

- Published: 2026-07-27T09:08:47.108Z

- Category: IA & Agentes

- Tags: amazon-connect, vdi, azure-virtual-desktop, windows-365, webrtc, contact-center, audio-optimization, mmr

- Reading time: 13 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/)

---

Quando agentes de contact center operam dentro de sessões VDI, o áudio sofre dupla penalidade: o stream WebRTC percorre o caminho session host → backbone de datacenter → PSTN/Connect, acumulando jitter e latência que nenhum codec consegue compensar sozinho. A adição de suporte a Azure Virtual Desktop e Windows 365 ao Amazon Connect resolve esse problema com a mesma abordagem que já funciona para WorkSpaces — redirecionamento de mídia via Microsoft Multimedia Redirection (MMR). É uma feature operacionalmente pequena, mas arquiteturalmente relevante para qualquer organização que padronizou em Microsoft 365 e ainda precisa de um contact center cloud-native de qualidade financeira.

## Impacto Mensurável do Redirecionamento de Mídia em VDI

- **~150ms** — Latência típica sem MMR (session host → Connect). Inclui processamento no host remoto + backhaul de datacenter
- **<50ms** — Latência com MMR ativo (local → Connect direto). Mídia processada no dispositivo do agente, sem passar pelo session host
- **4** — Plataformas VDI suportadas (WorkSpaces, Citrix, Omnissa, AVD/W365). Cobertura ampliada com o anúncio de julho de 2026
- **1x** — Setup por ambiente (one-time IT admin configuration). Sem alteração de workflow para agentes após configuração inicial

## O Problema Real: Por Que VDI e WebRTC São Naturalmente Incompatíveis

WebRTC foi projetado para comunicação ponto-a-ponto com processamento de mídia local. O protocolo assume que o dispositivo que executa o browser é o mesmo que captura e renderiza o áudio. Em ambientes VDI, essa premissa quebra: o browser roda no session host, que pode estar em uma região de datacenter diferente da localização física do agente. O resultado é que o áudio capturado pelo microfone do agente percorre USB/RDP até o session host, é processado pelo engine WebRTC remoto, empacotado em RTP/SRTP, e então enviado para o Amazon Connect — tudo isso antes de qualquer processamento de sinal de voz.

Esse caminho introduz três problemas distintos. Primeiro, **latência acumulada**: cada salto adiciona RTT. Um agente em São Paulo conectado a um session host em East US 2 já começa com 180ms de penalidade antes mesmo de o pacote chegar ao endpoint do Connect. Segundo, **jitter amplificado**: variações de latência na rede corporativa são amplificadas porque o buffer de jitter do WebRTC é gerenciado no session host, não no dispositivo local onde o hardware de áudio opera. Terceiro, **consumo de CPU no session host**: encoding de áudio em tempo real compete com outros processos da sessão VDI, e em ambientes de alta densidade (muitos agentes por host), isso cria contenção de recursos que degrada MOS (Mean Opinion Score) de forma não determinística.

O Microsoft Multimedia Redirection resolve isso interceptando o stream de mídia antes que ele seja encapsulado no protocolo RDP/AVD. O MMR redireciona o processamento WebRTC para o dispositivo local, onde o Connect CCP opera diretamente com o hardware de áudio. Do ponto de vista do Amazon Connect, a sessão é indistinguível de um agente em desktop nativo.

## Fluxo de Mídia: Sem MMR vs. Com MMR no Amazon Connect + AVD

Comparação dos dois caminhos de áudio. À esquerda, o fluxo legado sem otimização. À direita, o fluxo com MMR ativo — mídia processada localmente e enviada diretamente ao Connect.

### 🔴 Legacy Path (No MMR)

- Microphone (local HW) (edge)
- RDP/AVD Transport (network)
- AVD Session Host WebRTC Engine (compute)
- Amazon Connect Media Endpoint (frontend)

### 🟢 Optimized Path (MMR Active)

- Microphone (local HW) (edge)
- MMR Client (local device) (compute)
- Connect CCP (browser/JS SDK) (frontend)
- Amazon Connect Media Endpoint (frontend)
- AVD Session Host (UI only, no audio) (compute)

### Fluxos

- mic-legacy -> rdp-transport: áudio via RDP
- rdp-transport -> session-host: encapsulado no host
- session-host -> connect-legacy: WebRTC SRTP (+150ms)
- mic-mmr -> mmr-client: áudio local direto
- mmr-client -> ccp-local: MMR intercepta stream
- ccp-local -> connect-mmr: WebRTC SRTP (<50ms)
- session-host-mmr -> ccp-local: apenas UI/controles

## Arquitetura do MMR: O Que Realmente Acontece Sob o Capô

O Microsoft Multimedia Redirection é um componente de extensão do cliente AVD que opera em dois planos: um **host-side component** instalado na VM do session host e um **client-side component** no dispositivo local do agente. Quando o browser no session host tenta inicializar um contexto WebRTC (o que o Connect CCP faz automaticamente ao carregar), o MMR host component intercepta essa chamada e serializa a intenção de mídia para o client component via canal de dados do protocolo AVD.

O client component então inicializa o contexto WebRTC **localmente**, usando os dispositivos de áudio físicos do endpoint. O stream RTP/SRTP resultante vai diretamente do dispositivo local para o media endpoint do Amazon Connect, sem passar pelo session host. O session host recebe apenas sinais de controle — estado do call, eventos de UI do CCP — mantendo a sessão VDI sincronizada sem carregar mídia.

Do ponto de vista do Amazon Connect, isso é transparente. O serviço vê uma conexão WebRTC normal originada de um IP de cliente. Não há configuração especial no lado do Connect além do setup padrão do CCP. A complexidade está inteiramente no lado da infraestrutura VDI: o administrador precisa instalar a extensão MMR no session host (via Group Policy ou Intune), garantir que o cliente AVD no endpoint local esteja na versão correta, e configurar as URLs do Connect no allowlist do MMR para que o redirecionamento seja autorizado.

Um detalhe crítico que a documentação menciona mas que frequentemente é subestimado em implementações: o MMR requer que o **dispositivo local tenha conectividade direta com os endpoints de mídia do Amazon Connect**. Isso significa que firewalls corporativos que bloqueiam tráfego UDP de estações de trabalho para ranges CIDR da AWS precisam ser reconfigurados. Em ambientes financeiros com políticas de egress restritivas, esse é geralmente o maior bloqueador de adoção.

## Pontos Fortes: Onde Esta Feature Realmente Brilha

- **Paridade de experiência com desktop nativo**: Agentes em AVD/W365 obtêm qualidade de voz equivalente a um agente em máquina física. MOS scores que antes ficavam em 3.0-3.5 em VDI tipicamente sobem para 4.0+ com MMR ativo, eliminando a percepção de 'qualidade de call center' que prejudica CSAT.
- **Zero mudança de workflow para agentes**: Após a configuração one-time do administrador, o agente simplesmente loga na sessão AVD e abre o Connect Agent Workspace ou interface customizada. O MMR opera de forma completamente transparente — não há botão para ativar, não há extensão de browser adicional para o agente instalar.
- **Compatibilidade com interfaces customizadas via JS SDK**: A otimização funciona tanto com o Agent Workspace nativo quanto com interfaces construídas sobre o Amazon Connect Streams (open-source JavaScript library). Isso é relevante para operações que investiram em integrações CRM customizadas — a otimização de áudio não exige refatoração da camada de UI.
- **Redução de carga no session host**: Com o processamento de mídia offloaded para o endpoint local, a CPU do session host fica disponível para outros processos da sessão. Em deployments de alta densidade (ex: 20+ agentes por host D4s_v3), isso pode significar a diferença entre um host estável e um com contenção de CPU que degrada toda a sessão VDI.
- **Cobertura multi-VDI consistente**: Com AVD/W365 adicionados, o Amazon Connect agora cobre os quatro principais vetores de VDI corporativo (WorkSpaces, Citrix, Omnissa, Microsoft). Organizações com estratégias multi-VDI ou em processo de migração entre plataformas podem padronizar no Connect sem sacrificar qualidade de áudio em nenhuma delas.

> **Limitações Reais: O Que Esta Feature Não Resolve:** **GovCloud excluído**: A feature não está disponível em AWS GovCloud (US-West), o que é relevante para agências governamentais e contractors que usam AVD com dados sujeitos a FedRAMP High ou IL4+. Esses ambientes precisam continuar com alternativas de mitigação (codec tuning, QoS policies, dedicated session hosts) ou aguardar expansão de cobertura.

**Dependência de versão do cliente AVD**: O MMR requer versões específicas do cliente AVD no endpoint local. Ambientes com políticas rígidas de patch management ou endpoints gerenciados por terceiros podem ter dificuldade em garantir que todos os dispositivos estejam na versão correta simultaneamente. Um agente com cliente desatualizado simplesmente não terá o redirecionamento ativo — sem erro explícito, apenas qualidade degradada.

**Conectividade UDP obrigatória do endpoint local**: O dispositivo local precisa de acesso UDP direto aos ranges de IP do Amazon Connect para mídia WebRTC. Em redes corporativas com proxy HTTP obrigatório ou bloqueio de UDP de saída, isso requer exceções de firewall que podem ser politicamente difíceis de aprovar em ambientes financeiros regulados.

**Sem suporte a thin clients sem OS completo**: Dispositivos thin client baseados em firmware (ex: IGEL sem módulo AVD completo, ou zero clients) podem não suportar o client-side component do MMR. O suporte é garantido apenas para Windows 10/11 com cliente AVD completo instalado.

**Sem observabilidade nativa de qualidade de áudio**: O Amazon Connect não expõe métricas de MOS ou jitter por sessão no CloudWatch. Para monitorar se o MMR está realmente ativo e funcionando, você precisa de instrumentação adicional — Contact Lens, ou métricas coletadas via Connect Streams SDK no lado do cliente.

## Integração em Ambientes Financeiro-Grade: Considerações de Segurança e Compliance

Em operações de contact center de serviços financeiros — bancos, corretoras, seguradoras — a adoção de qualquer mudança de path de mídia precisa passar por análise de segurança que vai além do 'funciona bem'. Três dimensões são críticas.

**Criptografia de mídia em trânsito**: Com MMR ativo, o stream SRTP vai do endpoint local diretamente para o Amazon Connect. Isso é positivo do ponto de vista de criptografia — o stream nunca passa em plaintext por infraestrutura intermediária. O Amazon Connect usa DTLS-SRTP para todos os streams WebRTC, com chaves negociadas por sessão. Não há configuração adicional necessária para manter o mesmo nível de criptografia que você tinha sem MMR. O que muda é o **ponto de terminação do stream**: antes era o session host (dentro do seu datacenter/VNet), agora é o endpoint local do agente (potencialmente uma rede doméstica em trabalho remoto). Para organizações com políticas de 'media must stay within corporate network', isso é uma mudança de postura que precisa de aprovação explícita do CISO.

**Logging e auditoria de chamadas**: O Amazon Connect Contact Lens para análise de chamadas e o S3 para gravação continuam funcionando normalmente — eles operam no backend do Connect, não no path de mídia do agente. Gravações, transcrições e análise de sentimento não são afetados pela mudança de path introduzida pelo MMR. Isso é importante para compliance com LGPD, SOX e regulamentações do Banco Central que exigem retenção de gravações.

**IAM e autorização do agente**: A autenticação do agente no Connect Agent Workspace continua via SAML 2.0 ou Amazon Connect nativo, sem mudança. O MMR não introduz novas permissões IAM nem novos endpoints de autenticação. O que você precisa garantir é que as **Security Groups e NACLs** da VNet do session host permitam apenas tráfego de controle (HTTPS 443) para os endpoints do Connect, e que o tráfego de mídia UDP seja explicitamente permitido apenas do endpoint local — não do session host. Isso reduz a superfície de ataque comparado ao modelo sem MMR.

## Como Adotar: Roteiro de Implementação para Equipes de Plataforma

1. **1. Validar pré-requisitos de versão e rede** — Confirme que o cliente AVD nos endpoints dos agentes está na versão mínima que suporta MMR para WebRTC. Verifique se os endpoints locais têm saída UDP para os ranges de IP do Amazon Connect (documentados em aws.amazon.com/connect/ip-address-ranges). Execute um teste de conectividade com a ferramenta de diagnóstico do Connect CCP antes de qualquer rollout.

2. **2. Instalar o componente MMR no session host** — Implante o host-side component do MMR via Group Policy (para ambientes AD-joined) ou via Intune (para W365 e AVD com Azure AD join). Use um host pool de teste isolado antes de aplicar ao pool de produção. Valide com Event Viewer que o serviço MMR está ativo e sem erros de inicialização.

3. **3. Configurar allowlist de URLs do Connect no MMR** — O MMR requer que as URLs do seu instance do Amazon Connect estejam explicitamente permitidas para redirecionamento. Configure via registry key ou Group Policy: HKLM\SOFTWARE\Policies\Microsoft\MultiMediaRedirection\AllowedUrls. Inclua o domínio da sua instância Connect (*.awsapps.com ou domínio customizado) e os endpoints de mídia.

4. **4. Validar qualidade de áudio com agentes piloto** — Execute um piloto com 5-10 agentes por 2 semanas antes do rollout completo. Colete MOS scores via Contact Lens (habilite análise de qualidade de chamada) e compare com baseline pré-MMR. Monitore também CPU do session host para confirmar redução de carga. Documente qualquer caso onde o MMR não está ativo (agente com cliente desatualizado) para criar processo de remediação.

5. **5. Instrumentar observabilidade de qualidade de chamada** — Implemente coleta de métricas de qualidade via Amazon Connect Streams SDK: o evento 'softphone_stats' expõe jitter, packetLoss e roundTripTime por sessão. Envie essas métricas para CloudWatch via PutMetricData ou para seu stack de observabilidade (Datadog, Grafana). Crie alarmes para jitter > 30ms e packetLoss > 1% como indicadores de que o MMR pode não estar ativo ou que a rede local do agente está degradada.

6. **6. Atualizar runbooks e processo de suporte de nível 1** — Treine o suporte de nível 1 para diagnosticar problemas de áudio no contexto MMR. O primeiro passo de diagnóstico deve ser verificar se o MMR está ativo (via logs do cliente AVD ou via métricas do Streams SDK). Problemas de qualidade pós-MMR são quase sempre de rede local do agente — crie um checklist de diagnóstico que inclua teste de velocidade, verificação de VPN split-tunnel, e teste de dispositivo de áudio.

## Observabilidade de Qualidade de Voz: A Lacuna Que Você Precisa Preencher

A maior lacuna operacional desta feature — e do Amazon Connect em geral no contexto VDI — é a ausência de observabilidade nativa de qualidade de mídia por sessão. O CloudWatch publica métricas de contact center (tempo de fila, taxa de abandono, ocupação de agente), mas não expõe MOS, jitter, ou packet loss por chamada de forma nativa e acessível.

O Amazon Connect Contact Lens resolve parte disso: quando habilitado, ele analisa a qualidade de áudio das gravações e pode sinalizar chamadas com qualidade degradada. Mas há dois problemas com essa abordagem para monitoramento operacional. Primeiro, o Contact Lens opera **post-call** — você descobre que uma chamada teve qualidade ruim depois que ela terminou, não durante. Segundo, o Contact Lens tem custo por minuto de análise que pode ser significativo em operações de alto volume.

A abordagem que recomendo para ambientes financeiros é instrumentação via **Amazon Connect Streams SDK**. O SDK expõe o evento `softphone_stats` que é emitido periodicamente durante chamadas ativas, contendo `roundTripTimeMillis`, `packetsLost`, `packetsCount`, `audioLevel` e `jitterBufferMillis`. Esses valores são calculados pelo engine WebRTC local — com MMR ativo, eles refletem a qualidade da rede **local do agente**, não da rede do session host. Isso é exatamente o que você quer monitorar.

A arquitetura que funciona: o CCP customizado (ou um wrapper em torno do Agent Workspace) coleta esses stats e os envia para um endpoint API Gateway → Lambda → CloudWatch PutMetricData. Com isso, você cria dashboards de qualidade de voz em tempo real por agente, por região, e por contact flow. Alarmes em `jitterBufferMillis > 40` e `packetsLost/packetsCount > 0.01` funcionam como proxy confiável para detectar degradação de MMR ou problemas de rede local — e permitem que o suporte de nível 1 intervenha antes que o agente reporte o problema.

## Comparação de Plataformas VDI com Amazon Connect: Suporte de Áudio
| Critério | Plataforma VDI | Mecanismo de Redirecionamento | Requisito no Endpoint Local | Disponibilidade GovCloud | Maturidade (Connect) |
| --- | --- | --- | --- | --- | --- |
| Amazon WorkSpaces | WebRTC Redirection nativo | WorkSpaces client | Sim | GA, mais maduro | — |
| Azure Virtual Desktop | Microsoft MMR | AVD client (versão mínima) | Não (excluído) | GA, novo (Jun 2026) | — |
| Windows 365 Cloud PC | Microsoft MMR | AVD client (versão mínima) | Não (excluído) | GA, novo (Jun 2026) | — |
| Citrix Cloud | Citrix HDX Optimization | Citrix Workspace App | Verificar documentação | GA, maduro | — |
| Omnissa (VMware Horizon) | Horizon Media Optimization | Horizon client | Verificar documentação | GA, maduro | — |

## Posicionamento Estratégico: O Que Este Anúncio Revela Sobre a Direção do Connect

Analisando o padrão de expansão de suporte VDI do Amazon Connect — WorkSpaces primeiro, depois Citrix e Omnissa, agora AVD e Windows 365 — fica claro que a AWS está sistematicamente eliminando a qualidade de áudio como razão para não adotar o Connect em ambientes corporativos com VDI. Isso é relevante porque a principal objeção técnica de contact centers enterprise ao Connect historicamente não era funcionalidade (o Connect tem um conjunto de features robusto) mas sim qualidade de voz em infraestrutura VDI existente.

A escolha de suportar AVD e Windows 365 especificamente neste momento não é acidental. O mercado enterprise está em migração acelerada de infraestrutura de desktop para Microsoft 365 + AVD como plataforma consolidada. Organizações que antes mantinham Citrix ou VMware Horizon por razões de suporte de aplicações legadas estão progressivamente consolidando em AVD. A AWS está garantindo que o Connect seja uma opção viável nessa nova topologia, sem exigir que as organizações mantenham WorkSpaces como uma ilha de infraestrutura AWS apenas para suportar agentes de contact center.

Do ponto de vista de competição, isso também posiciona o Connect de forma mais forte contra Genesys Cloud e Salesforce Service Cloud Voice em RFPs enterprise. Ambos os competidores têm suporte similar para VDI, mas a integração nativa com o ecossistema AWS (Lambda para contact flows, Bedrock para agentes de IA, Kinesis para streaming de eventos de contato, S3 para gravações) continua sendo uma vantagem diferenciada que fica mais acessível quando a barreira de qualidade de áudio em VDI é removida.

O que me preocupa na trajetória é a exclusão persistente do GovCloud. Agências governamentais e contractors de defesa são exatamente o segmento que mais usa VDI por razões de segurança, e são também os que mais precisam de contact center cloud-native para modernização. A ausência de paridade de features no GovCloud cria um gap que força esses clientes a soluções alternativas ou a aceitar qualidade de áudio degradada — o que contradiz o objetivo de posicionar o Connect como plataforma enterprise de referência.

## Avaliação pelos Pilares do AWS Well-Architected

- **security**: DTLS-SRTP end-to-end do endpoint local ao Connect preserva criptografia de mídia. A mudança de terminação do stream (do session host para o endpoint local) requer revisão de política de segurança para ambientes com requisito de 'media within corporate network'. Sem novas superfícies IAM introduzidas pelo MMR.
- **reliability**: O MMR adiciona uma dependência de versão de cliente que pode criar falhas silenciosas (agente sem redirecionamento ativo sem saber). Recomendo health checks periódicos via Streams SDK para detectar sessões sem MMR ativo e alertar o suporte proativamente.
- **performance**: Redução de latência de ~150ms para <50ms é o benefício central. Offload de CPU do session host melhora densidade de agentes por host. O gargalo residual é a qualidade da rede local do agente — não controlável pela plataforma.
- **cost**: Sem custo adicional de Connect para habilitar MMR. Potencial redução de custo de infraestrutura AVD por maior densidade de agentes por host (menos VMs necessárias). Contact Lens para monitoramento de qualidade tem custo por minuto — avalie se o benefício justifica o custo vs. instrumentação via Streams SDK.
- **sustainability**: Offload de processamento de mídia do session host para o endpoint local reduz carga de compute centralizado. Em deployments de larga escala, isso pode traduzir em menor número de VMs de session host necessárias, reduzindo footprint de compute e consumo de energia associado.

> **Nota do Curador: O Que Eu Faria de Fato:** Em qualquer operação financeira com agentes em AVD, eu habilitaria o MMR imediatamente — mas com uma condição não negociável: instrumentação de qualidade de voz via Streams SDK **antes** do rollout, não depois. A lição que aprendi em implementações de contact center é que problemas de qualidade de áudio em VDI são sempre descobertos pelos agentes antes de aparecerem em qualquer dashboard, e sem métricas em tempo real você está voando cego. O segundo ponto que eu reforçaria com o time de segurança é a revisão explícita da política de 'media path' — não porque o MMR seja inseguro, mas porque mudar onde o stream SRTP termina é exatamente o tipo de mudança que auditores de segurança financeira identificam em revisões de arquitetura se não for documentada como decisão intencional em um ADR. Por fim, para qualquer organização em GovCloud: não espere — invista em QoS policies e dedicated session hosts como mitigação enquanto a paridade de features não chega.

## Veredicto: Vale a Adoção?

**Sim, sem hesitação para ambientes AVD/W365 fora do GovCloud.** O suporte a MMR no Amazon Connect para Azure Virtual Desktop e Windows 365 resolve um problema real e mensurável — qualidade de áudio degradada em VDI — com uma abordagem tecnicamente sólida que não introduz complexidade operacional significativa após a configuração inicial. O mecanismo de redirecionamento de mídia é bem estabelecido (já provado em WorkSpaces, Citrix e Omnissa), e a extensão para AVD/W365 é uma execução direta, não uma experimentação.

As limitações são reais mas gerenciáveis: a exclusão do GovCloud é o único bloqueador absoluto, e a ausência de observabilidade nativa é uma lacuna que você precisa preencher ativamente com instrumentação via Streams SDK. Para organizações em migração para Microsoft 365 + AVD como plataforma de desktop consolidada, esta feature remove o último argumento técnico relevante contra o Amazon Connect como plataforma de contact center — e isso tem valor estratégico além da melhoria de qualidade de áudio em si.

**Rating: 4.0/5** — Feature sólida, bem executada, com lacuna de observabilidade e exclusão de GovCloud como únicos pontos de demérito relevantes.

**Rating:** 4.0/5

## Referências

- [AWS What's New: Amazon Connect audio optimization for AVD and Windows 365](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-connect/)
- [Amazon Connect Admin Guide: Optimize Connect Customer audio for Azure Virtual Desktop and Windows 365](https://docs.aws.amazon.com/connect/latest/adminguide/using-ccp-vdi-azure-step-by-step.html)
- [Amazon Connect Admin Guide: Optimize audio for Amazon WorkSpaces cloud desktops](https://docs.aws.amazon.com/en_us/connect/latest/adminguide/using-ccp-vdi-workspaces.html)
- [Amazon Connect Release Notes (June 2026 Updates)](https://docs.aws.amazon.com/connect/latest/adminguide/amazon-connect-release-notes.html)
- [Amazon Connect Streams SDK (GitHub)](https://github.com/amazon-connect/amazon-connect-streams)
- [AWS Well-Architected Framework](https://docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html)