Configurar o WebRTC do CMS ou o Proxy de Aplicativo Web no Expressway

Introdução

Este documento descreve as etapas para configurar e solucionar os problemas do Cisco Meeting Server (CMS) WebRTC pelo Expressway.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Expressway X12.6.1 e posterior (x12.6.1 e posterior só podem funcionar com CMS 2.9.2 ou posterior devido a alterações no comportamento Exp TURN)
• Servidor CMS 2.9.3 e posterior
• Tradução de Endereço de Rede (NAT)
• Traversal usando relés (TURN) em torno do NAT 
• Session Traversal Utilities (STUN) para NAT
• Domain Name System (DNS)

Pré-requisitos de configuração:

• As configurações básicas relacionadas ao acesso remoto e móvel (MRA) (zona de passagem UC, túneis SSH) já devem estar habilitadas e configuradas no Expressway, clique aqui para obter guias MRA.
• Para o CMS 2.9.x - WebBridge (WB), XMPP e CallBridge configurados e habilitados no CMS, consulte o guia de configuração
• Chave de opção TURN instalada no Expressway-E. 
• Porta TCP 443 aberta no Firewall da internet pública para o endereço IP público do Expressway-E.
• Porta TCP e UDP 3478 (solicitações TURN) aberta no Firewall pela Internet pública para o endereço IP público do Expressway-E.
  • O TCP 3478 só será necessário se 'turnservers' na API do CMS tiver tcpPortNumberOverride definido como 3478.
• A porta UDP 3478 (solicitações TURN) aberta no Firewall do CMS para o endereço IP privado do Expressway-E (se você usar NIC dupla no Expressway-E).
  • O CMS 2.9.2 e anterior envia solicitações de vinculação para o Exp E, enquanto o 2.9.3 envia solicitações de alocação
• Registros de DNS externo para a URL de junção para webbridge, que pode ser resolvido para o endereço IP público do Expressway-E.
• Registro DNS interno para URL de Ingresso que pode ser resolvido para o endereço IP do servidor webbridge.
• Se estiver executando X12.5.2 ou anterior, assegure que a reflexão de NAT seja permitida no firewall externo para o endereço IP público do Expressway-E, clique aqui para obter a configuração de exemplo. A partir do X12.5.3, isso não é mais necessário para um Expressway independente.
• Ao usar a porta 443 para TURN, você ainda precisará abrir a porta UDP 3478 para mídia no firewall externo. 

Cuidado: quando a porta TCP 443 está habilitada, o Expressway não pode mais responder na porta TCP 3478.

Observação: o par Expressway usado para serviços de convidado Jabber não pode ser usado para serviços de proxy CMS WebRTC.

Observação: se estiver atualizando para a versão 3.0 ou posterior a partir de versões anteriores, consulte Orientação para atualização uniforme do Cisco Meeting Server 2.9 para a versão 3.0 (e posteriores)

Componentes Utilizados

Este documento não está restrito a versões específicas de software e hardware, no entanto, os requisitos mínimos de versão de software devem ser atendidos.

• Application Program Interface (API) do CMS
• Expressway
• Servidor CMS

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

O suporte a proxy WebRTC foi adicionado ao Expressway a partir da versão X8.9.2, que permite que usuários fora do local naveguem até um Web Bridge do Cisco Meeting Server.

Clientes e convidados externos podem gerenciar ou entrar em espaços sem precisar de nenhum outro software além de um navegador compatível. Clique aqui para obter uma lista de navegadores compatíveis.

A partir de 5 de fevereiro de 2021, estes são os navegadores compatíveis com o CMS 3.1.1:

Configurar

Diagrama de Rede

Esta imagem fornece um exemplo do fluxo de conexões do Web Proxy para CMS WebRTC: (do guia de configuração de Uso da porta IP Exp).

Observação: ao executar o X12.5.2 ou anterior, você deve configurar seu firewall externo para permitir a reflexão de NAT para o endereço IP público Expressway-E (os firewalls geralmente não confiam nos pacotes que têm o mesmo endereço IP origem e destino). A partir do X12.5.3, isso não é mais necessário para um Expressway independente.

Configuration Steps

Etapa 1. Integrar o CMS WB no Expressway-C

a. Navegue até Configuration > Unified Communication > Cisco Meeting Server.

b. Habilite o Proxy da Web do Servidor de Reunião.

c. Insira a URL de ingresso no campo URI do cliente da conta de convidado.

d. Clique em Save.

e. Adicione a URL de associação do CMS ao certificado do servidor Expressway-E como um SAN (nome alternativo do assunto). Consulte o Guia de implantação de criação e uso de certificados do Cisco VCS.

Etapa 2. Ative TURN no Expressway-E e adicione a credencial de autenticação ao banco de dados de autenticação local

a. Navegue até Configuration > Traversal > TURN.

b. Habilite os serviços TURN, de desligado a ligado.

c. Escolha Configure as credenciais do cliente TURN no banco de dados local e adicione as credenciais (nome de usuário e senha).

Observação: se você tiver um cluster do Expressway-Es e todos forem usados como servidores TURN, certifique-se de habilitá-lo em todos os nós. Você deve configurar duas instâncias separadas do turnServer sobre a API e apontá-las para cada um dos servidores Expressway-E no cluster (conforme o processo de configuração mostrado na Etapa 4, que mostra o processo para um servidor Expressway-E; a configuração do segundo turnServer seria semelhante, usando apenas os respectivos endereços IP e credenciais de turn para o outro servidor Expressway-E).

Nota: Você pode usar um balanceador de carga de rede na frente de suas vias expressas para tráfego TCP/HTTPS, mas a mídia TURN ainda deve ir do IP público do cliente para os servidores TURN. A mídia TURN não deve passar pelo balanceador de carga de rede

Etapa 3. Alterar a porta de administração do Expressway-E

Essa etapa é necessária, pois as conexões webrtc chegam no TCP 443, mas o Exp 12.7 introduziu uma nova Interface de Gerenciamento Dedicada (DMI) que pode ser usada para o 443.

a. Navegue até Sistema > Administração.

b. Em Web server configuration, altere a porta do administrador da Web para 445 nas opções suspensas e clique em Save.

c. Repita as etapas 3a a 3b em todos os Expressway-Es usados para serviços proxy WebRTC.

Observação: a Cisco recomenda que a porta de administração seja alterada porque os clientes WebRTC usam 443. Se o navegador WebRTC tentar acessar a porta 80, o Expressway-E redireciona a conexão para a 443.

Etapa 4. Adicione o Expressway-E como servidor(es) TURN para Media NAT Traversal no servidor do CMS

No CMS 2.9.x em diante, use o menu Configuration —> API para adicionar servidores turn:

• serverAddress: (Endereço IP privado do Expressway)
• clientAddress: (endereço IP público do Expressway)
• tipo: (via expressa)
• nome de usuário: (conforme configurado na etapa 2c)
• senha: (conforme configurado na etapa 2c)
• tcpPortNumberOverride: 3478

d. Repita a etapa 4c para cada servidor Expressway-E a ser usado para TURN

Esta imagem fornece um exemplo das etapas de configuração:

Verificar

Use esta seção para confirmar se a sua configuração funciona corretamente.

Etapa 1. No Expressway-C, verifique se o WB está integrado corretamente

a. Navegue até Configuration > Unified Communication > Cisco Meeting Server. Você deve ver o endereço IP do WB:

b. Navegue até Configuration > Unified Communication > HTTP allow list > Automatically added rules. Verifique se isso foi adicionado às regras:

Meeting Server web bridges 	https 	443 	Prefix 	/ 	GET, POST, PUT, HEAD, DELETE
Meeting Server web bridges 	wss 	443 	Prefix 	/ 	GET, POST, PUT, HEAD, DELETE

Observação: não se espera encontrar o WB nos nós descobertos porque as regras são simplesmente para permitir o proxy do tráfego HTTPS para o WB, e não necessariamente para a comunicação unificada.

c. Verifique se o túnel Shell Seguro (SSH) para o FQDN WB foi construído no Expressway-C para o Expressway-E e se está ativo. Navegue até Status > Unified Communications > Unified Communications SSH tunnels status. Você deve ver o FQDN do WB e o destino deve ser o Expressway-E.

Etapa 2. Verifique se o servidor TURN foi adicionado ao servidor CMS

No menu API do CMS, procure os servidores turn e clique em cada um. Dentro de cada objeto, há um link para verificar o status:

O resultado exibe as informações que incluem o tempo de resposta (RTT) em milissegundos (Ms) associados ao servidor TURN. Essas informações são importantes para que o CB selecione o melhor servidor TURN a ser usado.

Etapa 3. Verificar o uso do TURN Relay durante a chamada em andamento

No momento em que uma chamada ao vivo é feita com o uso do cliente WebRTC, você pode ver o status do TURN media Relay no Expressway. Navegue até Status > TURN relay usage e escolha view.

Troubleshooting

Ferramentas úteis:

• Arquivo HAR de navegadores (Como gerar um arquivo HAR no Chrome ou Firefox)
• Despejo interno de WebRTC do navegador - chrome://webrtc-internals ou edge://webrtc-internals - Crie o despejo assim que o Join for tentado.
• Os registros do console do navegador também podem ser úteis.
• Captura Wireshark do cliente, Exp E, Exp C e CMS.
• As depurações de Exp E network.http.trafserver ajudam na solução de problemas de websocket.

O cliente WebRTC externo se conecta, mas não há mídia (devido à falha de ICE)

Neste cenário, o cliente RTC é capaz de resolver o ID de chamada para jalero.space, mas quando você digita seu nome e seleciona Unir chamada, o cliente exibe Conectando, como mostrado nesta imagem:

Depois de cerca de 30 segundos ele é redirecionado para a página inicial do WB.

Para solucionar problemas, siga estes passos:

• Inicie o Wireshark no cliente RTC quando tentar ligar e, quando a falha acontece, interrompe a captura.
• Depois que o programa acontecer, verifique os logs de evento do CMS:

Navegue até Logs > Event logs no CMS WebAdmin.

• Filtre os rastreamentos do Wireshark com stun. Veja este exemplo:

Nos rastreamentos do Wireshark, você verá que o cliente envia Allocate Request (Solicitação de alocação) com as credenciais configuradas para o servidor Expressway-E TURN na porta 3478:

1329    2017-04-15 10:26:42.108282    10.55.157.229    10.48.36.248    STUN    186 
   Allocate Request UDP user: expturncreds realm: TANDBERG with nonce

O servidor responde com Allocate Error (Erro de alocação):

1363    2017-04-15 10:26:42.214119    10.48.36.248    10.55.157.229    STUN    254
    Allocate Error Response user: expturncreds with nonce realm: TANDBERG UDP error-code: 431
 (*Unknown error code*) Integrity Check Failure

or

3965    2017-04-15 10:34:54.277477    10.48.36.248    10.55.157.229    STUN    218
    Allocate Error Response user: expturncreds with nonce realm: TANDBERG UDP error-code: 401
 (Unauthorized) Unauthorized

Nos registros do CMS, esta mensagem de registro é mostrada:

2017-04-15	10:34:56.536	Warning	call 7: ICE failure 4 (unauthorized - check credentials)

Solução:

Verifique as credenciais TURN configuradas no CMS e certifique-se de que elas correspondam às configuradas no banco de dados de autenticação local do Expressway-E.

O cliente WebRTC externo não tem a opção Participar da chamada

Na página Status > General (Status > Geral) do Callbridge, isto é exibido:

2017-04-15	12:09:06.647	Web bridge connection to "webbridge.alero.aca" failed (DNS failure)
2017-04-15	12:10:11.634	Warning	web bridge link 2: name resolution for "webbridge.alero.aca" failed
2017-04-15	11:55:50.835	Info	failed to establish connection to web bridge link 2 (unknown error)

Solução:

• Certifique-se de que o Callbridge possa resolver a URL Join para o FQDN webbridge (o Callbridge não deve resolver isso para o endereço IP do Expressway-E).
• Limpe o cache do DNS no Callbridge, através da interface de linha de comando (CLI), com o comando dns flush.
• Verifique se o WB confia no certificado do servidor Callbridge (não no emissor).

O cliente WebRTC externo fica preso (na mídia de carregamento) ao se conectar ao espaço conjunto e é redirecionado para a página inicial do WB

Solução:

• Verifique se o CMS pode resolver o registro SRV _xmpp-client na rede interna para o domínio CB e verifique se as conexões WebRTC funcionam internamente.
• Colete uma captura do Wireshark no cliente e o log de diagnóstico, incluindo tcpdump no Expressway-E, ao tentar se conectar com o cliente externo:

Navegue até Maintenance > Diagnostics > Diagnostic logging e certifique-se de que Take tcpdump while logging esteja marcado, como mostrado nesta imagem, antes de você selecionar Start new log:

Observação: certifique-se de que a captura Wireshark no dispositivo do cliente e o registro no Expressway-E sejam iniciados antes de reproduzir a chamada com falha. Quando a chamada com falha for reproduzida, pare e baixe o log no Expressway-E e a captura no cliente.

• Extraia/descompacte o pacote de log baixado do Expressway-E e abra o arquivo .pcap obtido na interface pública.
• Filtre em ambas as capturas de pacotes com stun:
  • Em seguida, procure a solicitação de associação do cliente externo para o endereço IP público do Expressway-E, clique com o botão direito do mouse e selecione Follow > UDP Stream.
  • Geralmente, a porta de destino da solicitação de vinculação do cliente estaria no intervalo de 24000-29999, que é o intervalo de portas de retransmissão TURN no Expressway-E.
• Se nenhuma resposta às solicitações de vinculação for recebida no lado do cliente, verifique na captura do Expressway-E se as solicitações estão chegando.
• Caso as solicitações estejam chegando e o Expressway-E esteja respondendo ao cliente, verifique se o FW externo está permitindo o tráfego UDP de saída.
• Se as solicitações não estiverem chegando, verifique o FW para garantir que o intervalo de portas listado anteriormente não esteja bloqueado.
• Se o Expressway-E for implantado com um controlador de interface de rede duplo (NIC DUAL) com modo NAT estático ativado e for X12.5.2 ou anterior, verifique se a reflexão de NAT é suportada e configurada no seu FW externo. A partir do X12.5.3, isso não é mais necessário para um Expressway independente.

O cliente WebRTC externo não é capaz de se juntar ao espaço conjunto e recebe o aviso (Não foi possível conectar - tente novamente mais tarde)

Neste cenário, o cliente RTC pode resolver a ID de chamada para jalero.space, mas quando você digita seu nome e seleciona Ingressar na chamada, o aviso Não é possível conectar - tente novamente mais tarde é exibido imediatamente:

Solução:

Verifique se o CMS, na rede interna, consegue resolver o registro SRV _xmpp-client para o domínio CB.

Informações Relacionadas

• Guia de uso da porta de IP VCS/Expressway
• Suporte Técnico e Documentação - Cisco Systems