Configurar o WebRTC do CMS ou o proxy do Web App no Expressway

Introduction

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

Prerequisites

Requirements

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

• O Expressway X12.6.1 e posterior (x12.6.1 e posterior só funcionará com o CMS 2.9.2 ou posterior devido a alterações no comportamento do Exp TURN)
• Servidor CMS 2.9.3 e posterior
• Tradução de Endereço de Rede (NAT)
• Passagem usando retransmissões em torno do NAT (TURN)
• Utilitários de passagem de sessão para NAT (STUN)
• Domain Name System (DNS)

Pré-requisitos de configuração:

• Configurações relacionadas de acesso remoto e móvel (MRA) (zona de passagem UC, túneis SSH) já devem estar ativadas e definidas no Expressway, clique aqui para obter os guias de MRA
• Para CMS 2.9.x - WebBridge (WB), XMPP e CallBridge configurados e ativados 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) abertas no Firewall da Internet Pública para o endereço IP público do Expressway-E
  • O TCP 3478 só é necessário se 'turnservers' na API do CMS tiver tcpPortNumberOverride definido como 3478
• 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 anteriores enviam solicitações de vinculação ao Exp E, enquanto o 2.9.3 envia solicitações de alocação
• Registros DNS externos para o URL de junção da webbridge, resolvíveis para o endereço IP público do Expressway-E
• Registro DNS interno para URL de adesão que pode ser resolvido para o endereço IP do servidor de webbridge
• Se estiver executando X12.5.2 ou anterior, certifique-se de que a reflexão de NAT é permitida no firewall externo para o endereço IP público do Expressway-E, clique aqui para obter um exemplo de configuração. A partir do X12.5.3, isso não é mais necessário para um Expressway autônomo.
• Ao usar o TURN443, você ainda precisará abrir a porta UDP 3478 para mídia no firewall externo

Nota: Par Expressway que é usado para serviços de convidado do Jabber não pode ser usado em serviços proxy do WebRTC CMS.

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. All of the devices used in this document started with a cleared (default) configuration. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.

Informações de Apoio

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

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 oferece um exemplo do fluxo de conexões do proxy da Web para WebRTC CMS: (do guia de configuração de uso da porta IP da Exp)

Nota: 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 do Expressway-E (os firewalls geralmente desconfiam dos pacotes que têm o mesmo endereço IP de origem e destino). A partir do X12.5.3, isso não é mais necessário para um Expressway autônomo.

Configuration Steps

Etapa 1. Integre o CMS WB no Expressway-C

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

b. Habilitar o Proxy da Web do Meeting Server.

c. Insira o URL de junção no campo URI do cliente de conta de convidado.

d. Click Save.

e. Adicione a URL de junção do CMS ao certificado do servidor Expressway-E como um nome alternativo de assunto (SAN). Consulte o Guia de criação e uso de certificado 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. Ative os serviços TURN, de desligado para ligado.

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

Nota: Se você tiver um cluster do Expressway-Es e todos eles forem usados como servidores TURN, certifique-se de ativá-lo em todos os nós. Você precisa configurar duas instâncias separadas de turnServer pela 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 de um servidor Expressway-E; a configuração do segundo turnServer seria semelhante, usando apenas os respectivos endereços IP e credenciais TURN para o outro servidor Expressway-E).

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

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

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

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

b. Em Configuração do servidor Web, altere a porta do administrador da Web para 445 nas opções suspensas e clique em Salvar

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

Nota: A Cisco recomenda que a porta de administração seja alterada, pois os clientes WebRTC usam a 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 a passagem de NAT de mídia no servidor CMS

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

• serverAddress: (Endreço IP privado do Expressway)
• clientAddress: (Endereço IP público do Expressway)
• digite: (expressway)
• nome de usuário: (como configurado na etapa 2c)
• senha: (como configurado na etapa 2c)
• tcpPortNumberOverride: 3478

d. Repita a etapa 4c em todos os servidores Expressway-E a serem usados para TURN

Esta imagem fornece exemplos 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 (Configuração > Comunicações unificadas > Cisco Meeting Server) e você verá o endereço IP do WB:

b. Navegue até Configuration > Unified Communication > HTTP allow list > Automatically added rules (Configuração > Unified Communication > Lista de permissões HTTP > Regras adicionadas automaticamente), 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

Nota: Não é esperado encontrar o WB nos nós detectados, já que as regras são apenas para permitir o proxy de tráfego HTTPS para o WB e não necessariamente para o Unified Communication.

c. Verifique se o túnel Secure Shell (SSH) do WB FQDN WB foi criado no Expressway-C para o Expressway-E e que esteja ativo. Navegue até Status > Unified Communications > Unified Communications SSH tunnels status (Status > Unified Communications > Status dos túneis SSH do Unified Communications), é preciso 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 da API do CMS, procure os servidores giratórios e clique em cada um deles. 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 de retransmissão TURN e durante a chamada em andamento

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

Troubleshoot

Ferramentas úteis:

• Arquivo HAR dos navegadores (Como gerar um arquivo HAR no Chrome ou Firefox)
• Despejo interno do WebRTC a partir do browser - chrome://webrtc-internals ou edge://webrtc-internals - Criar despejo assim que tentar Unir
• 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 servidor de tráfego.http.e de rede E do Exp 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 pode resolver a ID de chamada para jalero.space, mas quando você digita seu nome e seleciona Ingressar na 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, faça o seguinte:

• 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 (Logs > Logs de evento) no WebAdmin do CMS

• 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 assegure-se de que correspondam ao que está configurado 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 o URL de junção ao FQDN da webbridge (o Callbridge não deve resolver isso no endereço IP do Expressway-E).
• Limpe o cache DNS no Callbridge, via Command line interface (CLI), com o comando dns flush.
• Certifique-se de que o WB confie 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:

• Certifique-se de que o CMS possa resolver o registro SRV _xmpp-client na rede interna para o domínio CB e certifique-se de que as ligações WebRTC funcionem internamente.
• Colete uma captura Wireshark no cliente e no registro de diagnóstico incluindo tcpdump no Expressway-E enquanto tenta se conectar ao cliente externo:

Navegue até Manutenção > Diagnóstico > Log de diagnóstico e verifique se Take tcpdump while logging está marcado, como mostrado nesta imagem, antes de selecionar Start new log:

Nota: Certifique-se de que a captura do Wireshark no dispositivo cliente e o log 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 na interface pública.
• Filtrar em ambas as capturas de pacote com stun:
  • Em seguida, procure a solicitação de vinculação do cliente externo ao 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 associação for recebida do lado do cliente, verifique a 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.
• Caso as solicitações não estejam chegando, verifique o FW para assegurar que o intervalo de portas acima não esteja bloqueado.
• Se o Expressway-E for implantado com um controlador de interface de rede dupla (DUAL-NIC) com modo NAT estático ativado e X12.5.2 ou anterior, verifique se a reflexão de NAT é suportada e configurada em seu FW externo. A partir do X12.5.3, isso não é mais necessário para um Expressway autônomo.

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