Configurar o proxy CMS WebRTC sobre Expressway

Introdução

Este original descreve as etapas para configurar e pesquisar defeitos Cisco que encontra o server (CMS) WebRTC sobre Expressway.

Pré-requisitos

Requisitos

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

• Expressway X8.9.2 e mais tarde
• Server 2.1.4 CMS e mais atrasado
• 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:

• O móbil básico e o Acesso remoto (MRA) relacionaram ajustes (zona UC Traversal, túneis SSH) devem já ser permitidos e configurado em Expressway, clicam aqui para guias MRA
• WebBridge (WB), a Mensagem elástico e o protocolo da presença (XMPP) e CallBridge configurado e permitido no CMS, clicam aqui para o manual de configuração
• GIRE a chave da opção instalada em Expressway-e
• Porta TCP 443 aberta no Firewall do Internet público ao endereço IP público do Expressway-e
• A porta 3478 TCP e UDP (pedidos da VOLTA) abriu no Firewall do Internet público ao endereço IP público do Expressway-e
• A porta 3478 TCP e UDP (pedidos da VOLTA) abriu no Firewall do CMS ao endereço IP privado do Expressway-e (se você usa o NIC dual em Expressway-e)
• Registros externos DNS para o FQDN do WebBridge, pode ser resolvido ao IP address do público-revestimento do Expressway-e
• Pode ser resolvido FQDN WB do registro dos DN internos ao IP address do server CMS
• A reflexão NAT permitiu no firewall externo para o endereço IP público do Expressway-e, clica aqui por exemplo a configuração

Nota: 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.

 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 CMS (API)
• Carteiro (cliente API)
• Expressway
• Server 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 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.

Configurar

Diagrama de Rede

Esta imagem fornece um exemplo das conexões flui do proxy da Web para CMS WebRTC:

Nota: 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).

Configuration Steps

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.

Nota: 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)

  Nota: 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. Você deve configurar dois exemplos separados do turnServer sobre o API, e aponta-os a cada um dos server de Expressway-e no conjunto (conforme o processo configurational mostrado em etapa 4, que mostra o processo para um server de Expressway-e; configuração a segunda dos turnServer seria similar, simplesmente usando os IP address e as credenciais respectivos da volta para o outro server de Expressway-e).

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

Nota: 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 aqui.

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:

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

d. Repita a etapa 4c para que cada server de Expressway-e seja usado para a VOLTA

Estas imagens fornecem exemplos das etapas configurational:

Verificar

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

Etapa1. 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 IP address 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

Nota: 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

Nota: 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:

• Copie a identificação do turnServer da etapa 2b
• Envie um pedido GET com o cliente API com este comando:

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 identificação 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 identificação 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. Verifique o uso do relé da VOLTA durante atendimento em curso

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.

Troubleshooting

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.

O cliente externo de WebRTC conecta mas nenhum media (devendo CONGELAR a falha)

Nesta encenação, o cliente RTC pode resolver a identificação de atendimento 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:

• Comece o wireshark no cliente RTC quando você tenta um atendimento e quando a falha ocorre, param a captação
• Depois que a edição ocorre, verifique os log de eventos CMS

Navegue aos logs > ao evento entra o CMS WebAdmin

• Filtre os traços de Wireshark com aturdem, veem o exemplo abaixo:

  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.

O cliente externo de WebRTC não obtém junta-se à opção de atendimento

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:

• Assegure-se de que o Callbridge possa resolver o FQDN WB ao endereço IP interno (o Callbridge não deve resolver este ao IP address do Expressway-e)
• Nivele o esconderijo DNS no Callbridge, através do comando line interface(cli), com o resplendor dns do comando
• Assegure-se de que a WB confie o certificado de servidor de Callbridge (não o expedidor)

O cliente externo de WebRTC colado (em media da carga) ao conectar ao cospace e obtém então reorientado à página da inicial WB

Solução:

• Assegure-se de que o CMS possa resolver o registro _xmpp-client SRV na rede interna para o domínio CB
• Recolha a captação de Wireshark no cliente e no diagnóstico que registram incluindo o tcpdump em Expressway-e ao tentar conectar com o cliente externo

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:

Nota: 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.

• Extraia/abrir o zíper o pacote do log dowloaded de Expressway-e e abra o arquivo .pcap tomado na relação do Público-revestimento
• Filtre em ambas as capturas de pacote de informação com aturdem
  • Procure então o pedido obrigatório do cliente externo ao endereço IP público de Expressway-e, direito-clique e seleto siga > córrego UDP
  • Geralmente a porta do destino do pedido obrigatório do cliente estaria na escala de 24000-29999, que é o intervalo de porta dos relés da VOLTA em Expressway-e
• Se nenhuma resposta aos pedidos obrigatórios é recebida no lado do cliente, verifique na captação do Expressway-e se os pedidos estão chegando
• Se os pedidos estão chegando e Expressway-e está respondendo ao cliente, verifique se o FW externo está permitindo o tráfego de partida UDP
• Se os pedidos não estão chegando, verifique o FW para assegurar-se de que o intervalo de porta acima não esteja obstruído
• Se Expressway-e está distribuído com Network Interface Controller duplo (NIC DUAL) com o modo do NAT estático permitido, a seguir assegure-se de que a reflexão NAT esteja apoiada e configurada em seu FW externo

O cliente externo de WebRTC incapaz de juntar-se ao cospace e obtém o de advertência (incapaz de conectar - tente outra vez mais tarde)

Nesta encenação, o cliente RTC pode resolver a identificação de atendimento 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.

Informações Relacionadas

• Guia do uso da porta IP VCS/Expressway

• Suporte Técnico e Documentação - Cisco Systems