O conjunto de documentação deste produto faz o possível para usar uma linguagem imparcial. Para os fins deste conjunto de documentação, a imparcialidade é definida como uma linguagem que não implica em discriminação baseada em idade, deficiência, gênero, identidade racial, identidade étnica, orientação sexual, status socioeconômico e interseccionalidade. Pode haver exceções na documentação devido à linguagem codificada nas interfaces de usuário do software do produto, linguagem usada com base na documentação de RFP ou linguagem usada por um produto de terceiros referenciado. Saiba mais sobre como a Cisco está usando a linguagem inclusiva.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve as etapas para configurar e solucionar os problemas do Cisco Meeting Server (CMS) WebRTC pelo Expressway.
A Cisco recomenda que você tenha conhecimento destes tópicos:
Pré-requisitos de configuração:
Note: Par Expressway que é usado para serviços de convidado do Jabber não pode ser usado em serviços proxy do WebRTC CMS.
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.
The information in this document was created from the devices in a specific lab environment. 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.
O suporte a proxy WebRTC foi adicionado ao Expressway a partir da versão X8.9.2, que permite aos usuários fora do local navegar para 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:
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)
Note: 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.
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.
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).
Note: 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).
Note: 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
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
Note: 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.
No CMS 2.9.x em diante, use o menu Configuration —> API para adicionar servidores rotativos:
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:
Use esta seção para confirmar se a sua configuração funciona 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
Note: 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:
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.
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.
Ferramentas úteis:
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:
Navegue até Logs > Event logs (Logs > Logs de evento) no WebAdmin do CMS
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.
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:
Solução:
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:
Note: 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.
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.