Esta seção abrange a ferramenta de teste de conectividade híbrida. Você pode acessar essa ferramenta de solução de problemas a partir do Control Hub.

Você também pode acessar os problemas conhecidos dos artigos relacionados.

Ferramenta de teste de conectividade híbrida (Control Hub)

Você pode acessar a ferramenta de teste de conectividade híbrida do Control Hub: na exibição do cliente em , vá para Serviços > Híbrido, clique em Editar configurações no cartão de Chamada híbrida, role até Destino SIP padrão e clique em Testar próximo ao destino SIP que você https://admin.webex.com entrou.

Esta tabela lista erros comuns que podem aparecer após você testar um endereço destino SIP para as Chamada híbrida. A tabela também fornece algumas próximas etapas para solução de problemas, incluindo links para detalhes relevantes no Guia de solução de problemas do serviço de chamada híbrida .

Tabela 1. Erros comuns e etapas de solução de problemas para testar um endereço de destino SIP para chamadas híbridas

Erro

Palavra-chave

Mais informações e etapas para solucionar problemas

Nenhum endereço DNS encontrado

DNS SRV

Falha na buscar DNS. Verifique se existe um registro DNS ou SRV para o Destino SIP e se ele resolve para um ou mais endereços IP válidos.

Consulte Não foi possível resolver o Expressway DNS SRV/hostname no guia de solução de problemas para obter mais informações.

O tempo de conexão se esmorou

Falha do soquete

A conexão de rede e/ou do TLS Mútuo esgotou. Verifique a conectividade de rede, a velocidade de conexão, a configuração do firewall e a configuração do TLS Mútuo.

Consulte estas seções do guia de solução de problemas para obter mais informações:

Falha do TLS

Falhas no handshake TLS mútuo

Erro do TLS mútuo: Verifique a configuração mútua TLS em ambos Expressway e , e se os certificados de TLS Mútuo estão presentes e https://admin.webex.comsão válidos em ambos os locais.

Veja Falhas mútuas do TLS Handshake no guia de solução de problemas para obter mais informações.

Falha na conexão

Falha do soquete

Falha na conexão TCP: Verifique a conectividade de rede, velocidade de conexão e/ou configuração do firewall.

Consulte estas seções do guia de solução de problemas para obter mais informações:

Falha de leitura/gravação TCP

Falha do soquete

Falha de leitura/gravação TCP: Tente novamente. Se o erro persistir, verifique a conectividade de rede, a configuração do firewall e a configuração de TLS mútuo.

Consulte estas seções do guia de solução de problemas para obter mais informações:

Falha de TCP

Falha do soquete

Falha de TCP: Falha de leitura/gravação TCP: Tente novamente. Se o erro persistir, verifique a conectividade de rede, a configuração do firewall e a configuração de TLS mútuo.

Consulte estas seções do guia de solução de problemas para obter mais informações:

Esta seção abrange as listas de verificação de problemas e tarefas que você pode ver antes de entrar em contato com o suporte.

Se as chamadas do Webex para a sua empresa não estão tocando no lado da empresa, vá pelos pontos nesta lista de verificação para verificar duas vezes sua configuração.

Antes de passar por essas sugestões de solução de problemas, consulte as https://status.webex.com informações mais recentes sobre quaisquer falhas na nuvem. Nessa página de status, você também pode assinar as notificações.

Verifique estes pontos de solução de problemas relacionados com a TLS mútuo de conexão e certificados:

  • Instale o pacote de pacotes de certificado raiz nuvem Webex no Expressway-E.

  • Configure uma porta TLS mútuo dedicada no Expressway-E.

  • Configure uma zona DNS para a nuvem no Expressway-E.

  • Abra o número TLS mútuo de entrada no seu firewall —5062, que pode não estar aberto por padrão.

  • Determine qual certificado raiz opção que você está usando na nuvem Webex — A opção é usada para verificar o certificado SIP TLS Expressway-Edo seu Expressway.)

    • Armazenamento padrão — é o certificado Expressway-E assinado por uma das autoridades públicas? Se você não tiver certeza, use a opção de armazenamento personalizado.

    • Armazenamento personalizado — é o seu certificado Expressway-E ou seu signatário instalado na nuvem? O certificado contém os nomes dos organizadores Expressway-E verificados?

Na exibição do cliente https://admin.webex.comem , vá para Serviços > híbridos > de chamada > híbridas. Marque estes pontos que estão relacionados com as suas destino SIP que você definiu durante o processo de implantação:

  • Os pontos de valor na porta TLS mútuo dedicada do Expressway-E.

  • Tente se conectar ao endereço IP:porta . (Vários endereços se você configurou um SRV.)

  • Se você tiver configurado um endereço de IP ou um nome de host, especifique a TLS mútuo de entrada.

  • Se você usou um SRV, certifique-se de que ele esteja no formato_sips._tcp.< domínio que você colocou como Destino SIP >.

  • Se você não quiser configurar uma SRV, você pode inserir o endereço de IP:porta ou nome do organizador:porta como nome da sua destino SIP.

  • Se as chamadas do Expressway-E para a nuvem estiverem falhando e você estiver usando o método manual de gerenciamento de certificados, certifique-se de seguir as etapas em Atualização do certificado CA raiz do Webex e carregue o certificado IdenTrust para seus dispositivos Expressway o mais rápido possível.

  • Para chamadas que encaminham do Webex para a empresa, verifique o histórico de pesquisa e os registros de rede no Expressway-E. Esta etapa ajuda você a isolar o problema para a nuvem ou para a empresa.

  • Se você reutilizar uma zona B2B existente e as regras de pesquisa, considere criar zonas dedicadas e regras de pesquisa. Essa configuração evita interferência com as configurações de zona existentes para o B2B/MRA, evita loops de roteamento e facilita a solução de problemas.

  • Verifique o histórico de pesquisa e os registros de rede no Expressway-E. Verifique se o convite SIP da nuvem chega no Expressway-E e corresponde à zona DNS que você configurou para a nuvem.

    • Se o CONVITE SIP não chegar ou corresponder à zona DNS configurada, siga o caminho da chamada para o Unified Communications Manager. Esta etapa ajuda você a descobrir onde a chamada está falhando ou perdida.

    • Consulte a lista TLS mútuo de resolução de problemas.

  • Verifique o header de rota. Verifique se ele contém o valor do nome de domínio totalmente qualificado (FQDN) do cluster que está configurado nas configurações da empresa do Unified Communications Manager e nas regras de pesquisa do Expressway. Veja este exemplo de rota de header e cluster FQDN:

    • Rota: ,

      • Neste exemplo, o grupo FQDN início é myucmcluster.example.com.

  • Os e-mails no Unified Communications Manager devem corresponder exatamente ao e-mail (sincronizado do Active Directory ou de qualquer outra fonte) na nuvem Webex.

  • As URIs de diretório devem corresponder a quaisquer domínios que você verificou na sua organização.

  • Verifique sua configuração de codec .

    Os serviços Webex suportam os seguintes codecs:

    • Áudio—G.711, G.722, AAC-LD

    • Vídeo—H.264

    Oferecemos suporte ao G.729 para entrar em uma reunião Webex, reunião de sala pessoal ou reunião do aplicativo Webex de um dispositivo SIP. Não oferecemos suporte ao G.729 para discar 1:1 do aplicativo Webex para um dispositivo SIP ou ponte.

  • No grupo inicial do Unified Communications Manager dos usuários afetados, escolha Sistema > Parâmetros corporativos ; em Configuração de domínio geral , verifique a configuração do nome de domínio totalmente qualificado (FQDN) do grupo. O FQDN de uso que você usou deve seguir estas diretrizes:

    FQDN de diretrizes

    Descrição e exemplo

    Vários grupos

    A entrada deve ser exclusiva para cada grupo com chamada híbrida — por exemplo, CLUSTER1.example.com, cluster2.example.com, e assim por diante.

    Nenhum curinga

    Não use entradas com curingas, como *.example.com ou example*.com.

    Primeiro FQDN entrada para chamadas híbridas

    Em uma lista de várias entradas, a nuvem Webex usa a primeira entrada à esquerda para as chamada híbrida e essa primeira entrada não deve conter um curinga.

    Veja este exemplo de três FQDN entrada da esquerda para a direita (a primeira sendo para as chamada híbrida): cluster1.example.com *.example.com example*.com

    Diferente do Expressway-E

    Deve ser diferente do sistema Expressway-E, DNS e nome de domínio. Caso contrário, Expressway-E retira o header da rota.

    Nova entrada para chamadas híbridas

    Se a entrada FQDN atual no Unified CM não atender aos requisitos listados acima, você poderá adicionar um novo elemento ao início da configuração FQDN do grupo para chamadas híbridas.

    Por exemplo, se a configuração FQDN existente no Cisco Unified Communications Manager for *.example.com *.example.org , adicione uma entrada exclusiva que não seja do curinga no início do campo: " cluster1.example.com *.example.com *.example.org"