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 pesquisar defeitos Cisco que encontra o server (CMS) WebRTC sobre Expressway.
A Cisco recomenda que você tenha conhecimento destes tópicos:
Pré-requisito de configuração:
Note: Os pares de Expressway que são usados para serviços do convidado do Jabber não podem ser usados para serviços de proxy CMS WebRTC.
Este documento não é restringido à versão de software e hardware específica, porém as exigências da versão mínima de software devem ser cumpridas.
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 sua rede está viva, assegure-se de que você compreenda o impacto potencial do comando any.
O suporte de proxy de WebRTC foi adicionado a Expressway da versão X8.9.2, que permite usuários dos fora-locais de consultar a Cisco que encontra a ponte da Web do server.
Os clientes externos e os convidados podem controlar ou juntar-se a espaços sem a necessidade de todo o software a não ser um navegador suportado. Clique aqui para uma lista de navegadores suportados.
Esta imagem fornece um exemplo das conexões flui do proxy da Web para CMS WebRTC:
Note: Você deve configurar seu firewall externo para permitir a reflexão NAT para o IP address público de Expressway-e (dos Firewall os pacotes da desconfiança tipicamente que têm o mesmo IP address da fonte e do destino).
Etapa 1. Integre a WB CMS em Expressway-C.
a. Navegue à configuração > uma comunicação unificada > Cisco que encontra o server
b. Permita o proxy da Web do server da reunião
c. Incorpore o FQDN da WB ao campo do cliente URI da conta do convidado
d. Clique sobre a salvaguarda
e. Adicionar o FQDN da WB no certificado de servidor de Expressway-e como um nome alternativo sujeito (SAN), clique-o aqui para o guia do certificado de Expressway.
Note: O cliente URI da conta do convidado deve ser como configurado no server WebAdmin CMS (interface GUI da Web) sem o prefixo de https://.
Etapa 2. Permita GERENCIEM sobre Expressway-e e adicionam as credenciais de autenticação ao base de dados de autenticação local.
a. Navegue à configuração > ao Traversal > à VOLTA
b. Permita serviços da VOLTA, de fora a sobre
c. Seleto configurar credenciais do cliente da VOLTA no base de dados local e adicionar as credenciais (o nome de usuário e senha)
Note: Se você tem um conjunto de Expressway-e e são todos a ser usados como server da VOLTA, a seguir assegure para permiti-lo em todos os Nós.
Etapa 3. Mude a porta da administração de Expressway-e (opcional).
a. Navegue ao sistema > à administração
b. Sob a configuração do servidor de Web, mude a porta do administrador da Web a 445 das opções da gota-para baixo, a seguir selecione a salvaguarda
c. Repita as etapas 3a a 3b em todo o Expressway-e usado para serviços de proxy de WebRTC
Note: Cisco recomenda a administração que a porta seja mudada porque o uso 443 dos clientes de WebRTC. Se o navegador de WebRTC tenta à porta de acesso 80, Expressway-e reorienta a conexão a 443.
Etapa 4. Adicionar Expressway-e como server da VOLTA para o traversal dos media NAT no server CMS.
a. Transfira e instale o carteiro de; https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop?hl=en
b. Incorpore o acesso URL API à barra de endereços, por exemplo; https://<Callbridge_fqdn>:445/api/v1/<entity>
c. Envie um CARGO com https://<Callbridge_fqdn>:445/api/v1/turnservers, depois que você adiciona estes campos no corpo:
d. Repita a etapa 4c para que cada server de Expressway-e seja usado para a VOLTA
Estas imagens fornecem exemplos das etapas configurational:
Use esta seção para confirmar se a sua configuração funciona corretamente.
Etapa 1. Em Expressway-C, certifique-se da WB esteja integrada corretamente.
a. Navegue à configuração > uma comunicação unificada > Cisco que encontra o server, e você deve ver o endereço IP de Um ou Mais Servidores Cisco ICM NT da WB:
b. Navegue à configuração > uma comunicação unificada > HTTP permitem a lista > regras automaticamente adicionadas, certificam-se de isto esteja 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 se espera encontrar não necessariamente a WB nos Nós descobertos porque as regras são simplesmente permitir o proxy do tráfego HTTPS à WB, e para uma comunicação unificada.
c. Certifique-se do túnel do Shell Seguro (ssh) para o FQDN WB esteja construído em Expressway-C a Expressway-e e que é ativo. Navegue estado aos túneis do estado > das comunicações unificadas > das comunicações unificadas SSH, você deve ver que o FQDN da WB e do alvo deve ser Expressway-e:
Etapa 2. Verifique que o server da VOLTA esteve adicionado ao server CMS.
a. No WebUI, se você usa um único server de Expressway, navegue aos logs > aos log de eventos, a saída mostra o endereço IP do servidor da VOLTA, como no exemplo:
2017-04-15 09:37:26.864 Info TURN server 7: starting up "10.48.36.248" (configured object 6508065f-298f-4146-8697-4b7087279de3)
b. Se você usa server múltiplos da VOLTA de Expressway, envie um pedido GET com um cliente API com este comando:
https://<Callbridge_IP>:445/api/v1/turnservers
Note: Este comando pode igualmente ser usado se você tem um único server da VOLTA de Expressway.
A saída, no caso dos server múltiplos da VOLTA de Expressway, é similar àquela neste exemplo:
<?xml version="1.0"?> <turnServers total="2"> <turnServer id="7eecf3eb-49f2-4963-bf67-2bac98355ca1"> <serverAddress>10.48.79.129</serverAddress> <clientAddress>175.6.7.9</clientAddress> </turnServer> <turnServer id="eef94a2b-3bfa-40f7-b83c-ece8df424e15"> <serverAddress>10.48.36.248</serverAddress> <clientAddress>175.6.7.8</clientAddress> </turnServer> </turnServers>
c. Para verificar o estado de cada server da VOLTA faça o seguinte:
https://<Callbridge_IP>:445/api/v1/turnservers/<turnServer id>/status
A saída indica a informação que inclui o Round-Trip Time (RTT) nos milissegundos (Senhora) associou o server da VOLTA. Esta informação é importante para a seleção CB do melhor server da VOLTA de usar-se.
A saída abaixo mostra o estado para o server da VOLTA com ID 7eecf3eb-49f2-4963-bf67-2bac98355ca1:
<?xml version="1.0"?>
<turnServer>
<status>success</status>
<host>
<address>10.48.36.248</address>
<portNumber>3478</portNumber>
<reachable>true</reachable>
<roundTripTimeMs>37</roundTripTimeMs>
<mappedAddress>10.48.36.5</mappedAddress>
<mappedPortNumber>44920</mappedPortNumber>
</host>
</turnServer>
A saída abaixo mostra o estado para o server da VOLTA com ID eef94a2b-3bfa-40f7-b83c-ece8df424e15:
<?xml version="1.0"?>
<turnServer>
<status>success</status>
<host>
<address>10.48.79.129</address>
<portNumber>3478</portNumber>
<reachable>true</reachable>
<roundTripTimeMs>48</roundTripTimeMs>
<mappedAddress>10.48.36.5</mappedAddress>
<mappedPortNumber>44920</mappedPortNumber>
</host>
Etapa 3. Na altura de um atendimento vivo que seja feito com o uso do cliente de WebRTC, você pode ver o estado do relé dos media da VOLTA em Expressway. Navegue ao uso do relé do estado > da VOLTA, a seguir selecione a vista.
Esta seção fornece a informação que você pode se usar para pesquisar defeitos sua configuração, algumas edições de WebRTC e falhas possíveis típicas.
Os logs para as conexões WB e o traçado DNS podem ser permitidos no WebAdmin do server CMS:
a. Conecte ao WebAdmin
b. Navegue aos logs > detalhou o seguimento
c. Permita o traçado da conexão de Bridge da Web e o DNS que seguem para a duração desejada:
O debug logging do console de Chrome e de Firefox pode ser usado para pesquisar defeitos falhas da conexão de cliente de WebRTC, tais como edições com media e Conectividade à WB. Isto pode ser feito visível com o uso da combinação Ctrl+Shift+C. do teclado.
Em Chrome, use chrome://webrtc-internals/ ou aproximadamente: webrtc em Firefox, em uma aba separada na altura de um atendimento vivo para indicar os diagnósticos avançados, que seja útil pesquisar defeitos edições dos media com WebRTC.
A captura de pacote de informação de Whireshark no cliente de WebRTC igualmente fornece alguma informação util sobre o relé dos media o server da VOLTA.
Nesta encenação, o cliente RTC pode resolver a identidade da chamada a jalero.space, mas quando você entra em seus nome e Joincall seleto, o cliente indica a conexão, como mostrado na imagem abaixo:
Após aproximadamente 30 segundos, é reorientada à página inicial WB.
Para pesquisar defeitos, faça o seguinte:
Navegue aos logs > ao evento entra o CMS WebAdmin
Nos traços de Wireshark, você vê que o cliente envia atribui o pedido com as credenciais configuradas, ao server da VOLTA de Expressway-e 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 server responde com atribui o erro:
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
ou
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 logs CMS, o mensagem de registro abaixo é mostrado:
2017-04-15 10:34:56.536 Warning call 7: ICE failure 4 (unauthorized - check credentials)
Solução:
Verifique as credenciais da VOLTA configuradas no CMS e assegure-se de que combine aquele que é configurado no base de dados de autenticação local de Expressway-e.
No estado de Callbridge > a página geral, isto é indicada:
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 ao >Diagnostics da manutenção > registro diagnóstico e assegure-se de que tcpdump da tomada ao registrar é verificado como mostrado na imagem abaixo, antes que você selecione o log novo do começo:
Note: Assegure-se de que a captação de Wireshark no dispositivo do cliente e a abertura de Expressway-e estejam começadas antes de reproduzir o atendimento de falha. Quando o atendimento de falha foi reproduzido, pare e transfira a abertura de Expressway-e e da captação no cliente.
Nesta encenação, o cliente RTC pode resolver a identidade da chamada a jalero.space, mas quando você entra em seus nome e Joincall seleto, o Unableto de advertência conecta - a tentativa é indicada outra vez mais tarde imediatamente:
Solução:
Certifique-se do CMS, na rede interna, possa resolver sempre o registro _xmpp-client SRV para o domínio CB.