Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Ce document décrit les étapes pour configurer, vérifier et dépanner WebRTC du serveur de réunion Cisco (CMS) par l’intermédiaire d’Expressway.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Prérequis pour la configuration :
Attention : lorsque le port TCP 443 est activé, l’Expressway ne peut plus répondre sur le port TCP 3478.
Remarque : la paire Expressway utilisée pour les services Jabber Guest ne peut pas être utilisée pour les services proxy WebRTC de CMS.
Remarque : si vous effectuez une mise à niveau vers la version 3.0 ou ultérieure à partir de versions précédentes, reportez-vous au Guide de mise à niveau en douceur de Cisco Meeting Server 2.9 vers la version 3.0 (et versions ultérieures)
Ce document n'est pas limité à des versions logicielles et matérielles spécifiques, mais les exigences minimales en matière de version logicielle doivent être satisfaites.
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. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
La prise en charge du proxy WebRTC a été ajoutée à Expressway à partir de la version X8.9.2, ce qui permet aux utilisateurs hors site de naviguer vers un pont Web Cisco Meeting Server.
Les clients externes et les invités peuvent gérer des espaces ou s’y joindre sans avoir besoin d’autre logiciel, à part un navigateur pris en charge. Cliquez ici pour obtenir la liste des navigateurs pris en charge.
À partir du 5 février 2021, voici les navigateurs pris en charge pour CMS 3.1.1 :
Cette image fournit un exemple du flux de connexions du proxy Web pour CMS WebRTC : (à partir du guide de configuration Exp IP port Usage).
Remarque : lorsque vous exécutez X12.5.2 ou une version antérieure, vous devez configurer votre pare-feu externe pour permettre la réflexion NAT pour l’adresse IP publique Expressway-E& (les pare-feu ne font généralement pas confiance aux paquets qui ont la même adresse IP source et de destination). À partir de X12.5.3, ce n’est plus nécessaire pour un Expressway autonome.
a. Accédez à Configuration > Unified Communication > Cisco Meeting Server.
b. Activez le proxy Web du serveur de téléconférence.
c. Saisissez l'URL de connexion dans le champ URI du client du compte invité.
d. Cliquez sur Enregistrer.
e. Ajoutez l’URL de connexion CMS au certificat du serveur Expressway-E en tant que nom alternatif du sujet (SAN). Reportez-vous au Guide de déploiement de création et d'utilisation de certificats Cisco VCS.
a. Accédez à Configuration > Traversal > TURN.
b. Activez les services TURN, de off à on.
c. Choisissez Configure TURN client credentials on local database et ajoutez les informations d'identification (nom d'utilisateur et mot de passe).
Remarque : si vous avez un cluster d’Expressway-Es et qu’ils doivent tous être utilisés comme serveurs TURN, assurez-vous de l’activer sur tous les noeuds. Vous devez configurer deux instances turnServer distinctes sur l’API et les diriger vers chacun des serveurs Expressway-E du cluster (selon le processus de configuration indiqué à l’étape 4, qui montre le processus pour un serveur Expressway-E ; la configuration du second turnServer serait similaire, en utilisant uniquement les adresses IP respectives et les identifiants de tour pour l’autre serveur Expressway-E).
Remarque : vous pouvez utiliser un équilibreur de charge réseau devant vos autoroutes pour le trafic TCP/HTTPS, mais le support TURN doit toujours passer de l'adresse IP publique du client aux serveurs TURN. Le support TURN ne doit pas passer par l'équilibreur de charge réseau
Cette étape est nécessaire car les connexions webrtc sont disponibles sur TCP 443, mais Exp 12.7 a introduit une nouvelle interface de gestion dédiée (DMI) qui peut être utilisée pour 443.
a. Accédez à Système > Administration.
b. Sous Web server configuration, remplacez le port d'administrateur Web par 445 dans les options de la liste déroulante, puis cliquez sur Save.
c. Répétez les étapes 3a à 3b sur tous les Expressway-E utilisés pour les services proxy WebRTC.
Remarque : Cisco recommande de modifier le port d'administration, car les clients WebRTC utilisent 443. Si le navigateur WebRTC tente d’accéder au port 80, l’Expressway-E redirige la connexion vers 443.
Dans CMS 2.9.x et les versions ultérieures, utilisez le menu Configuration —>API pour ajouter des serveurs tour :
d. Répétez l’étape 4c pour chaque serveur Expressway-E à utiliser pour TURN
Cette image fournit un exemple des étapes de configuration :
Utilisez cette section pour confirmer que votre configuration fonctionne correctement.
a. Accédez à Configuration > Unified Communication > Cisco Meeting Server. Vous devez voir l'adresse IP du WB :
b. Accédez à Configuration > Unified Communication > HTTP allow list > Automatically added rules. Vérifiez qu'il a été ajouté aux règles :
Meeting Server web bridges https 443 Prefix / GET, POST, PUT, HEAD, DELETE Meeting Server web bridges wss 443 Prefix / GET, POST, PUT, HEAD, DELETE
Remarque : il n'est pas prévu de trouver le WB dans les noeuds détectés, car les règles sont simplement d'autoriser le proxy du trafic HTTPS vers le WB, et pas nécessairement pour la communication unifiée.
c. Vérifiez que le tunnel Secure Shell (SSH) pour le FQDN WB a été construit sur Expressway-C vers l’Expressway-E et qu’il est actif. Accédez à Status > Unified Communications > Unified Communications SSH tunnels status. Vous devez voir le nom de domaine complet du WB et la cible doit être l’Expressway-E.
Dans le menu CMS API, recherchez les serveurs tour, puis cliquez sur chacun d'eux. Dans chaque objet, il y a un lien pour vérifier l'état :
Cela produira de l’information, dont la durée totale aller-retour (RTT) en millisecondes (Ms) qui est associée au serveur du protocole TURN. Cette information est importante dans la sélection de CB pour ce qui concerne le meilleur serveur du protocole TURN à utiliser.
Lors d’un appel en direct effectué avec le client WebRTC, vous pouvez afficher l’état du relais multimédia TURN sur l’Expressway. Accédez à Status > TURN relay usage, puis choisissez view.
Outils utiles :
Dans ce scénario, le client RTC est capable de résoudre l'ID d'appel en jalero.space, mais quand vous entrez votre nom et sélectionnez Join call, le client affiche Connecting, comme illustré dans cette image :
Après environ 30 secondes, il est redirigé vers la page de WB initiale.
Afin de dépanner, complétez ces étapes :
Accédez à Logs > Event logs sur le CMS WebAdmin.
Dans le traces Wireshark, vous verrez que le client envoie Allocate Request et les renseignements d’authentification configurés au serveur TURN Expressway-E ACTIVATION sur le port 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
Le serveur répond avec Allocate Error :
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
Dans les journaux CMS, ce message de journal s'affiche :
2017-04-15 10:34:56.536 Warning call 7: ICE failure 4 (unauthorized - check credentials)
Solution :
Vérifiez les informations d’identification TURN configurées sur le CMS et assurez-vous qu’elles correspondent à celles configurées sur la base de données d’authentification locale d’Expressway-E.
Dans la page Callbridge Status > Generalpage, l’information suivante s’affiche :
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)
Solution :
Solution :
Accédez à Maintenance > Diagnostics > Diagnostic logging et assurez-vous que Take tcpdump while logging est coché, comme illustré dans cette image, avant de sélectionner Start new log :
Remarque : assurez-vous que la capture Wireshark sur le périphérique du client et la connexion sur l’Expressway-E sont démarrées avant de reproduire l’appel défaillant. Lorsque l’appel qui a échoué est reproduit, arrêtez et téléchargez la journalisation sur l’Expressway-E ainsi que la capture sur le client.
Dans ce scénario, le client RTC peut résoudre l'ID d'appel en jalero.space, mais lorsque vous entrez votre nom et sélectionnez Join call, l'avertissement Unable to connect - try again later s'affiche immédiatement :
Solution :
Vérifiez que CMS, sur le réseau interne, est en mesure de toujours résoudre l’enregistrement SRV _xmpp client pour le domaine CB.
Révision | Date de publication | Commentaires |
---|---|---|
2.0 |
21-Jun-2023 |
Mise à jour PII, SEO, Alt Text, Machine Translation, Style Requirements, Orthographe et Mise en forme. |
1.0 |
20-Oct-2017 |
Première publication |