Configurer le proxy CMS WebRTC ou Web App sur Expressway

Introduction

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.

Conditions préalables

Conditions requises

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Expressway X12.6.1 et versions ultérieures (x12.6.1 et versions ultérieures ne fonctionneront qu'avec CMS 2.9.2 ou versions ultérieures en raison de changements dans le comportement d'Exp TURN)
• Serveur CMS 2.9.3 et versions ultérieures
• Traduction d'adresses réseau (NAT)
• Traversée à l’aide de relais autour du NAT (TURN)
• Outil de traversée en session pour le NAT (STUN)
• Système de noms de domaine (DNS)

Prérequis pour la configuration :

• Les paramètres d’accès mobile et à distance (MRA) de base (zone UC, tunnels SSH) doivent être déjà activés et configurés sur l’Expressway; cliquez ici pour les guides de MRA
• Pour CMS 2.9.x - WebBridge (WB), XMPP et CallBridge configurés et activés sur CMS, reportez-vous au guide de configuration
• La touche d’option du protocole TURN est installée sur l’Expressway-E
• Le Port 443 TCP est ouvert sur le pare-feu de l’Internet public à l’adresse IP publique de l’Expressway-E
• Le port TCP et UDP 3478 (requêtes TURN) s’est ouvert sur le pare-feu depuis Internet public jusqu’à l’adresse IP publique de l’Expressway-E
  • TCP 3478 uniquement nécessaire si les 'serveurs tournants' de l'API CMS ont tcpPortNumberOverride défini sur 3478
• Le port UDP 3478 (requêtes TURN) s’est ouvert sur le pare-feu depuis CMS vers l’adresse IP privée de l’Expressway-E (si vous utilisez une carte réseau double sur l’Expressway-E)
  • CMS 2.9.2 et versions antérieures envoie des requêtes de liaison à Exp E, tandis que 2.9.3 envoie des requêtes d'allocation
• Enregistrements DNS externes pour l’URL de jointure pour le pont Web, pouvant être résolus à l’adresse IP publique de l’Expressway-E
• Enregistrement DNS interne pour l'URL de jointure résolvable à l'adresse IP du serveur WebBridge
• Si vous exécutez X12.5.2 ou une version antérieure, assurez-vous que la réflexion NAT est autorisée sur le pare-feu externe pour l’adresse IP publique d’Expressway-E, cliquez ici par exemple pour la configuration. Depuis X12.5.3, ce n’est plus nécessaire pour un Expressway autonome.
• Lorsque vous utilisez TURN443, vous devez toujours ouvrir le port UDP 3478 pour les supports sur le pare-feu externe

Remarque: Un jumelage Expressway qui est utilisé pour services d’invité de Jabber ne peut être utilisé pour les services de proxy WebRTC CMS.

Components Used

Ce document n’est pas limité à des versions spécifiques du logiciel et du matériel; il faut toutefois que les exigences en matière de version minimale du logiciel soient satisfaites.

• interface de programmation d’application (API) de CMS
• Expressway
• Serveur CMS

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. 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.

Informations générales

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 sur 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.

Depuis le 5 février 2021, voici les navigateurs pris en charge pour CMS 3.1.1 :

Configuration

Diagramme du réseau

Cette image fournit un exemple de la circulation des connexions de Proxy Web pour WebRTC CMS : (à partir du guide de configuration Exp IP Port Usage)

Remarque: Lors de l’exécution de X12.5.2 ou d’une version antérieure, vous devez configurer votre pare-feu externe pour permettre la réflexion NAT pour l’adresse IP publique et Expressway-E (les pare-feu méfient généralement les paquets qui ont la même adresse IP source et de destination). Depuis X12.5.3, ce n’est plus nécessaire pour un Expressway autonome.

Configuration Steps

Étape 1. Intégrer CMS WB à Expressway-C

a. Accédez à Configuration > Unified Communication > Cisco Meeting Server.

b. Activez le proxy Web Meeting Server.

c. Entrez l'URL de jointure dans le champ URI du client de compte invité.

d. Click Save.

e. Ajoutez l’URL de jointure CMS au certificat du serveur Expressway-E en tant que SAN (Subject Alternative Name). Reportez-vous au Guide de création et d'utilisation de certificats Cisco VCS.

Étape 2. Activez TURN sur l’Expressway-E et ajoutez les informations d’identification à la base de données d’authentification locale

a. Accédez à Configuration > Traversée > TURN.

b. Activez les services TURN, de off à on.

c. Choisissez Configurer les informations d'identification du client TURN sur la base de données locale 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 devrez configurer deux instances deturnServer distinctes sur l’API et les relier à chacun des serveurs Expressway-E du groupe (selon le processus de configuration illustré à l’Étape 4, qui montre le processus pour un serveur Expressway-E; la configuration de la deuxième instance turnServer devrait être semblable; pour la réaliser, il faudra toutefois utiliser les adresses IP et les renseignements d’authentification du protocole TURN se rattachant à 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 du client au serveur TURN IP public.  Le support TURN ne doit pas passer par l'équilibreur de charge réseau

Étape 3. Modifier le port d’administration de l’Expressway-E

Cette étape est requise car les connexions Web arrivent 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 à System > Administration.

b. Sous Configuration du serveur Web, définissez le port administrateur Web sur 445 dans les options déroulantes, puis cliquez sur Enregistrer

c. Répétez les étapes 3a à 3b sur tous les Expressway-Es utilisés pour les services proxy WebRTC

Remarque: Cisco recommande la modification du port d’administration, car les clients WebRTC utilisent le 443. Si le navigateur WebRTC tente d’accéder au port 80, l’Expressway-E redirige la connexion vers 443.

Étape 4. Ajoutez l’Expressway-E en tant que serveur(s) TURN pour la traversée NAT sur le serveur CMS

Dans CMS 2.9.x ultérieur, utilisez le menu Configuration —> API pour ajouter des serveurs tournants :

• serverAddress: (adresse IP privée d’Expressway)
• clientAddress: (adresse IP publique d’Expressway)
• type : (expressway)
• username (nom d’utilisateur) : (selon le mot de passe configuré à l’étape 2c)
• password (mot de passe) : (selon le mot de passe configuré à l’étape 2c)
• tcpPortNumberOverride : 3478

d. Répétez l’étape 4c pour chaque serveur Expressway-E qui sera utilisé dans le serveur TURN

Cette image fournit des exemples des étapes de configuration :

Vérification

Utilisez cette section pour confirmer que votre configuration fonctionne correctement.

Étape 1. Dans Expressway-C, vérifiez que le WB est correctement intégré

a. Naviguez jusqu’à Configuration > Unified Communications > Cisco Meeting Server, puis vous devriez voir l’adresse IP de WB :

b. Naviguez jusqu’à Configuration > Unified Communication > HTTP allow list > Automatically added rules et vérifiez que cela 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: Normalement, le WB ne doit pas se trouver dans les nœuds découverts (Discovered nodes), car les règles prévoient simplement le proxy du trafic HTTPS pour le WB et pas nécessairement les communications unifiées.

c. Vérifiez que le tunnel Secure Shell (SSH) pour le FQDN de WB a été créé dans l’Expressway-C pour l’Expressway-E et qu’il est actif. Naviguez jusqu’à Status > Unified Communications > Unified Communications SSH tunnels status; vous devriez voir le FQDN de WB et la cible doit être l’Expressway-E :

Étape 2. Vérifiez que le serveur TURN a été ajouté au serveur CMS

Dans le menu API CMS, recherchez les serveurs tour, puis cliquez sur chacun d'eux. Dans chaque objet, un lien permet de 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.

Étape 3. Vérifier l'utilisation du relais TURN et pendant l'appel en cours

Au moment où un appel en direct est effectué à l’aide du client WebRTC, vous pouvez afficher l’état du relais de support TURN sur l’Expressway. Accédez à Status > TURN relay usage, puis choisissez view.

Dépannage

Outils utiles :

• Fichier HAR des navigateurs (Comment générer un fichier HAR dans Chrome ou Firefox)
• Débordement interne de WebRTC à partir du navigateur - chrome://webrtc-internals ou edge://webrtc-internals - Créer un vidage dès la tentative de jointure
• Les journaux de la console du navigateur peuvent également être utiles
• Capture Wireshark du client, Exp E, Exp C et CMS
• Exp E network.http.traffic.server aide au dépannage des connecteurs Web

Le client WebRTC externe se connecte, mais sans support (en raison de l’échec ICE)

Dans ce scénario, le client RTC peut résoudre l'ID d'appel sur jalero.space, mais lorsque vous entrez votre nom et sélectionnez Joindre l'appel, le client affiche Connexion, comme illustré dans cette image :

Après environ 30 secondes, il est redirigé vers la page de WB initiale.

Pour résoudre les problèmes, procédez comme suit :

• Lancez Wireshark sur le client RTC lorsque vous tentez d’établir un appel et lorsque la défaillance se produit, arrêtez la capture.
• Une fois que le problème se produit, consultez les journaux d’événements CMS:

Naviguez jusqu’à Logs > Event logs sur le WebAdmin de CMS

• Filtrez les traces Wireshark avec stun. Reportez-vous à l’exemple suivant :

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 renseignements d’authentification du protocole TURN configurés sur CMS et vérifiez qu’ils correspondent à l’information configurée dans la base de données locale d’authentification d’Expressway-E.

Le client WebRTC externe n’a pas accès à l’option pour participer à l’appel (Join Call).

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 :

• Assurez-vous que le pont d’appel peut résoudre l’URL de jointure en FQDN du pont Web (le pont d’appel ne doit pas résoudre ce problème en l’adresse IP de l’Expressway-E).
• Videz le cache DNS sur Callbridge, via l'interface de ligne de commande (CLI), avec la commande dns flush.
• Assurez-vous que WB fait confiance au certificat du serveur Callbridge (et non à l'émetteur).

Le client WebRTC externe est resté bloqué (en chargement des médias) lors de la connexion à l’espace partagé. Il est ensuite redirigé vers la page initiale WB.

Solution :

• Assurez-vous que CMS peut résoudre l'enregistrement SRV _xmpp-client sur le réseau interne pour le domaine CB et assurez-vous que les connexions WebRTC fonctionnent en interne.
• Collecter une capture Wireshark sur le client et la journalisation de diagnostic y compris tcpdump sur l’Expressway-E lors d’une tentative de connexion avec le client externe :

Accédez à Maintenance > Diagnostics > Diagnostic logging et assurez-vous que Take tcpdump when 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 journalisation sur Expressway-E ont été lancées avant la reproduction de l’appel qui a échoué. 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.

• Extrayez/décompressez le lot de journaux téléchargé à partir de l’Expressway-E et ouvrez le fichier .pcap pris sur l’interface Public.
• Filtrer sur les deux captures de paquets avec stun :
  • Recherchez ensuite la demande de liaison du client externe à l’adresse IP publique Expressway-E, cliquez avec le bouton droit de la souris et sélectionnez Suivre > Flux UDP.
  • Habituellement, le port de destination de la requête de liaison du client se situerait dans la plage de 24000-29999, qui est la plage de ports de relais TURN sur l’Expressway-E.
• Si aucune réponse aux demandes de liaison n’est reçue du côté du client, vérifiez la capture de l’Expressway-E si les demandes arrivent.
• Si les demandes arrivent et que l’Expressway-E répond au client, vérifiez si le transfert externe (External FW) permet le trafic UDP sortant.
• Si les demandes n’arrivent pas, examinez FW pour vérifier que la plage de ports précisée ci-dessous n’est pas bloquée.
• Si l’Expressway-E est déployé avec un contrôleur d’interface réseau double (DUAL-NIC) avec le mode NAT statique activé et est X12.5.2 ou antérieur, assurez-vous que la réflexion NAT est prise en charge et configurée sur votre pare-feu externe. Depuis X12.5.3, ce n’est plus nécessaire pour un Expressway autonome.

Il est impossible pour le client WebRTC de se joindre à l’espace partagé et il reçoit un avertissement lui indiquant que la connexion est impossible et qu’il devra réessayer plus tard (Unable to connect - try again later).

Dans ce scénario, le client RTC est en mesure de résoudre l'ID d'appel à jalero.space, mais lorsque vous entrez votre nom et sélectionnez Joindre l'appel, l'avertissement Impossible de se connecter - réessayez plus tard 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.

Informations connexes

• Guide d’utilisation du port IP pour VCS/Expressway
• Support et documentation techniques - Cisco Systems