Cette section couvre l’outil de test de connectivité hybride. Vous pouvez accéder à cet outil de dépannage à partir de Control Hub.

Vous pouvez également accéder aux problèmes connus à partir des articles connexes.

Outil de test de connectivité hybride (Control Hub)

Vous pouvez accéder à l’outil de test de connectivité hybride à partir du Control Hub : à partir de l’affichage du client dans , allez à Services > Hybride , cliquez sur Modifier les paramètres dans la carte Appel hybride, faites défiler jusqu’à Destination SIP par défaut , puis cliquez sur Tester à côté de la Destination SIP que vous avez https://admin.webex.com saisie.

Ce tableau répertorie les erreurs courantes qui peuvent apparaître lorsque vous testez une Destination SIP pour l’appel hybride. Le tableau fournit également quelques étapes de dépannage, y compris des liens vers les détails pertinents dans le Guide de dépannage du service d'appel hybride.

Tableau 1. Erreurs courantes et étapes de dépannage pour tester une adresse de destination SIP pour l’appel hybride

Erreur

Mot clé

Informations supplémentaires et étapes de dépannage

Aucune adresse DNS n'a été trouvée

DNS SRV

Échec de la recherche DNS. Vérifiez qu'un enregistrement DNS ou SRV existe pour votre destination SIP et qu'il résout une ou plusieurs adresses IP valides.

Voir Impossible de résoudre le problème Expressway DNS SRV/nom d’hôte dans le guide de dépannage pour plus d’informations.

Expiration de la connexion

Échec du socket

Expiration de la connexion du réseau et/ou TLS mutuel. Vérifier la connectivité réseau, la vitesse de connexion, la configuration du pare-feu et la configuration TLS mutuelle.

Voir les sections suivantes du guide de dépannage pour plus d’informations :

Échec TLS

Échecs de connexion TLS mutuel

Erreur du port TLS mutuel : Vérifiez la configuration TLS mutuel dans les deux Expressway et que les certificats TLS mutuel sont présents et valides dans leshttps://admin.webex.comdeux emplacements.

Voir Échec des connexions TLS mutuel dans le guide de dépannage pour plus d'informations.

Échec de connexion

Échec du socket

Échec de la connexion TCP : Vérifiez la connectivité réseau, la vitesse de connexion, et/ou la configuration du pare-feu.

Voir les sections suivantes du guide de dépannage pour plus d’informations :

Panne de lecture/écriture TCP

Échec du socket

Panne de lecture/écriture TCP : Veuillez réessayer. Si l’erreur persiste, vérifiez la connectivité réseau, la configuration du pare-feu et la configuration TLS mutuelle.

Voir les sections suivantes du guide de dépannage pour plus d’informations :

Panne TCP

Échec du socket

Panne TCP : Panne de lecture/écriture TCP : Veuillez réessayer. Si l’erreur persiste, vérifiez la connectivité réseau, la configuration du pare-feu et la configuration TLS mutuelle.

Voir les sections suivantes du guide de dépannage pour plus d’informations :

Cette section couvre les listes de vérification et les tâches que vous pouvez parcourir avant de contacter l’assistance.

Page de statut Webex

Si les appels de Webex vers votre entreprise ne sonnent pas du côté de l’entreprise, passage en revue les points de cette liste pour vérifier votre configuration.

Avant de passer en revue ces suggestions de dépannage, consultez la section pour obtenir les dernières informations sur les pannes du Cloud.https://status.webex.com À partir de cette page d'état, vous pouvez également souscrire aux notifications.

TLS mutuel et destination SIP

Vérifiez ces points de dépannage liés à la connexion TLS mutuelle et aux certificats :

  • Installez le groupe de serveurs certificat racine Webex sur le Expressway-E.

  • Configurez un port TLS mutuel dédié sur Expressway-E.

  • Configurer la zone DNS sur le Cloud pour l'organisateur Expressway-E.

  • Ouvrez le numéro de port TLS mutuel dans votre pare-feu—5062, qui ne peut pas être ouvert par défaut.

  • Déterminez l certificat racine option que vous utilisez dans le Cloud Webex—L’option est utilisée pour vérifier le certificat TLS SIP de votre Expressway-E.

    • Magasin par défaut—Votre certificat Expressway est-il signé par l'une des autorités publiques ? Si vous n'êtes pas sûr, utilisez l'option magasin personnalisé.

    • Magasin personnalisé—Votre certificat Expressway-E ou son signataire est-il installé dans le Cloud? Le certificat contient-il des noms d'organisateurs vérifiés Expressway-E?

À partir de l’affichage du client dans , allez à Services > appel > https://admin.webex.com hybride > Paramètres. Vérifiez ces points qui sont liées à votre Destination SIP que vous définissez pendant le processus de déploiement :

  • La valeur correspond à votre port TLS mutuel dédié Expressway-E.

  • Essayez de vous connecter à l'adresse IP : port. (Plusieurs adresses si vous avez configuré un SRV.)

  • Si vous avez configuré une adresse IP ou un nom d'organisateur, spécifiez le port TLS mutuel.

  • Si vous avez utilisé un SRV, vérifiez qu'il est au format _sips._tcp.<domaine que vous mettez en tant que destination SIP>.

  • Si vous ne souhaitez pas configurer un SRV, vous pouvez entrer l'adresse IP : port ou nom d'organisateur : port comme destination SIP de votre organisation.

Configuration du pair Expressway

  • Si les appels de l’Expressway-E vers le Cloud échouent et que vous utilisez la méthode de gestion manuelle des certificats, vérifiez que vous suivez les étapes contenues dans Mise à jour du certificat de l’AC racine Webex et téléchargez le certificat IdenTrust sur vos périphériques Expressway dès que possible.

  • Pour les appels acheminés depuis Webex vers l’entreprise, consultez l’historique de recherche et les journaux réseau sur Expressway-E. Cette étape permet d'isoler le problème sur le Cloud ou sur l'entreprise.

  • Si vous réutilisez une zone B2B existante et des règles de recherche, pensez plutôt à créer des zones dédiées et des règles de recherche. Cette configuration évite les interférences avec les paramètres de zone existants pour B2B / MRA, évite les boucles de routage et facilite le dépannage.

  • Vérifiez l'historique de recherche et les journaux de réseau sur Expressway-E. Vérifiez que l'INVITE SIP du Cloud arrive à l'Expressway-E et correspond à la zone DNS que vous avez configurée pour le Cloud.

    • Si l'INVITE SIP n'arrive pas ou ne correspond pas à la zone DNS configurée, suivez le routage de l'appel vers Unified Communications Manager. Cette étape vous aide à trouver où l'appel échoue ou s'il est perdu.

    • Voir la liste de contrôle de dépannage TLS mutuelle.

  • Vérifiez le titre du routage. Vérifiez qu'il contient la valeur FQDN (nom de domaine complet qualifié de cluster) configurée dans les paramètres d'entreprise Unified Communications Manager et dans les règles de recherche Expressway. Voir cet exemple d'en-tête d'itinéraire et au FQDN de cluster mis en évidence :

    • Routage : ,

      • Dans cet exemple, le FQDN du cluster d'accueil est myucmcluster.example.com.

Configuration d’Unified CM

  • Les courriers électroniques dans Unified Communications Manager doivent correspondre exactement au courrier électronique (synchronisé à partir d’Active Directory ou de toute autre source) dans le Cloud Webex.

  • Les URL des répertoires doivent correspondre à tous les domaines que vous avez vérifiés dans votre organisation.

  • Vérifiez la configuration de votre codec.

    Les services Webex supportent les codecs suivants :

    • Audio—G.711, G.722, AAC-LD

    • Vidéo—H.264

    Nous prenons en charge G.729 pour rejoindre une réunion Webex, une réunion Salle personnelle ou une réunion Application Webex à partir d'un périphérique SIP. Nous ne prenons pas en charge G.729 pour la numérotation 1 à 1 de l'application Webex vers un périphérique ou un pont SIP.

  • Sur le cluster d'accueil Unified Communications Manager des utilisateurs affectés, choisissez Système > Paramètres d'entreprise ; sous Clusterwide Domain Configuration, vérifiez le paramètre du nom de domaine entièrement qualifié (FQDN) du cluster. La valeur FQDN que vous avez utilisée doit suivre ces lignes directrices :

    Instructions FDQN

    Description et exemple

    Plusieurs clusters

    L’entrée doit être unique pour chaque cluster avec appel hybride — par exemple, CLUSTER1.example.com, cluster2.example.com, etc.

    Aucun des caractères génériques

    N’utilisez pas les entrées avec des caractères génériques, tels que *.example.com ou example*.com.

    Première entrée FDQN hybride appelé

    Dans la liste des entrées multiples, le Cloud Webex utilise la première entrée sur la gauche pour l’appel hybride et cette première entrée ne doit pas contenir de caractère générique.

    Voir cet exemple de trois entrées FDQN de gauche à droite (le premier étant pour l’appel hybride): cluster1.exemple.com *.exemple.com exemple*.com

    Différent de l’Expressway-E

    Doit être différent du nom de domaine, DNS et système Expressway-E. Dans le cas contraire, Expressway-E supprime l’en-tête de routage.

    Nouvelle entrée pour l'appel Hybride

    Si votre saisie de FDQN actuelle dans Unified CM ne répond pas aux exigences listées ci-dessus, vous pouvez ajouter un nouvel élément au début du paramètre du cluster FDQN pour l’appel hybride.

    Par exemple, si votre paramètre FQDN existant dans Cisco Unified Communications Manager est *.example.com *.example.org, ajoutez une entrée unique, non générique au début du champ : « cluster1.example.com *.example.com *.example.org »