Configurer le proxy WebRTC de CMS 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

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes : 

• Expressway X8.9.2 et versions ultérieures
• Serveur CMS 2.1.4 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
• WebBridge (WB), le protocole Messagerie et présence extensibles (XMPP) et le pont d’appel CallBridge doivent être configurés et activés sur CMS; cliquez ici pour le 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 3478 TCP et UDP (requêtes du protocole TURN) est ouvert sur le pare-feu de l’Internet public à l’adresse IP publique de l’Expressway-E
• Le Port 3478 TCP et UDP (requêtes du protocole TURN) est ouvert sur le pare-feu de CMS à l’adresse IP privée de l’Expressway-E
• Des enregistrements DNS externes pour le FQDN de WebBridge, résolus pour l’adresse IP publique sur Expressway-E
• Un enregistrement DNS interne pour FQDN de WB, résolu pour l’adresse IP du serveur CMS
• Une réflexion NAT est autorisée sur le pare-feu externe pour l’adresse IP d’Expressway-E, cliquez ici pour un exemple de configuration

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

 Composants utilisés

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
• Postman (client API)
• 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. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Une prise en charge de proxy WebRTC a été ajoutée à Expressway de la version X8.9.2. Cela permet aux utilisateurs hors lieux de naviguer vers un pont Web de serveur de réunion de Cisco.

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.

Configurer

Diagramme du réseau

Cette image fournit un exemple de la circulation des connexions de Proxy Web pour WebRTC CMS :

Remarque: Vous devez configurer votre pare-feu externe pour permettre une réflexion NAT pour l’adresse IP publique sur Expressway-E (habituellement, les pare-feu ne tiennent pas pour sécuritaires les paquets qui ont la même adresse IP de source et de destination).

Configuration Steps

Étape 1. Intégrez CMS WB dans Expressway-C

a. Naviguez jusqu’à Configuration > Unified Communications > Cisco Meeting Server.

b. Activez Meeting Server Web Proxy

c. Entrez le FQDN de WB dans le Guest account client URI (URI de client du compte invité)

d.Cliquez sur Save (enregistrer)

e. Ajouter le FQDN de WB sur le certificat du serveur Expressway-E comme un autre nom d’objet (SAN, Subject Alternative Name), cliquez ici pour le guide de certificat Expressway.

Remarque: L’URI de client du compte invité doit être configuré sur le serveur CMS WebAdmin (interface GUI Web) sans le préfixe https:// .

Étape 2. Activez le protocole TURN de Expressway-E et ajoutez l’information d’authentification dans la base de données locale de l’authentification

a. Naviguez jusqu’à Configuration > Traversal > TURN

b. Activez les services du protocole TURN, de arrêt à mise en marche

c. Sélectionnez l’option de configuration Configure TURN client credentials on local database et ajoutez les renseignements d’identité (nom d’utilisateur et mot de passe)

  Remarque: Si vous avez un groupe d’Expressway-E et que tous les éléments sont destinés à servir de serveurs pour le protocole TURN, assurez-vous d’activer le groupe sur tous les nœuds. 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).

Étape 3. Modifiez le port d’administration de l’Expressway-E (facultatif)

a. Naviguez jusqu’à System > Administration

b. Sous la rubrique de configuration du serveur Web (Web server configuration), modifiez le port de l’administrateur Web à 445 parmi les options de menu déroulant, puis sélectionnez la fonction d’enregistrement (Save)

c. Répétez les étapes 3a à 3b pour tous les Expressway-E utilisés pour les services de 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 comme serveur(s) du protocole TURN pour la traverse NAT de médias sur le serveur CMS

a. Téléchargez et installez Postman ici.

b. Entrez l’URL d’accès avec l’API dans la barre d’adresse, par exemple : https://<Callbridge_fqdn>:445/api/v1/<entity>

c. Envoyer un message (POST) avec https://<Callbridge_fqdn>:445/api/v1/turnservers, après avoir ajouté ces champs dans le corps du message :

• serverAddress: (adresse IP privée d’Expressway)
• clientAddress: (adresse IP publique d’Expressway)
• type : (expressway)
• username (nom d’utilisateur) : (selon le nom configuré à l’étape 2c)
• password (mot de passe) : (selon le nom 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

Ces images montrent des exemples des étapes de configuration :

Vérifiez

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 du protocole TURN a été ajouté au serveur CMS

a. Sur la WebUI, si vous utilisez un seul serveur Expressway, accédez à Logs > Event logs pour consulter les journaux d’événement. Vous pourrez consulter l’adresse IP du serveur TURN, comme dans l’exemple :

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. Si vous utilisez plusieurs serveurs Expressway pour le protocole TURN, envoyez une requête GET request auprès d’un client d’API au moyen de cette commande :

https://<Callbridge_IP>:445/api/v1/turnservers

Remarque: Cette commande peut également servir si vous avez un seul serveur Expressway du protocole TURN.

Comme dans le cas des différents serveurs Expressway du protocole TURN, cela vous permettra de consulter de l’information semblable à l’exemple suivant :

<?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. Pour vérifier l’état de chaque serveur du protocole TURN, procédez comme suit :

• Copiez l’information identifiante sur le serveur (turnServer id ) à l’étape 2b
• Envoyez une requête GET request avec le client d’API au moyen de cette commande :

https://<Callbridge_IP>:445/api/v1/turnservers/<turnServer id>/status

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.

 L’information ci-dessous présente l’état du serveur du protocole TURN avec l’ID 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>

L’information ci-dessous présente l’état du serveur du protocole TURN avec l’ID 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>

Étape 3. Vérifiez l’utilisation du relayage du protocole TURN pendant un appel

Lorsqu’un appel en direct est passé au moyen d’un client WebRTC, vous pouvez visualiser l’état du relayage du protocole TURN sur l’Expressway. Naviguez jusqu’à Status > TURN relay usage,, puis sélectionnez view (Afficher).

Dépanner

Cette section présente des renseignements que vous pouvez utiliser pour faire des démarches de dépannage liées à votre configuration, à certains problèmes WebRTC standard et aux défaillances possibles.

Il est possible d’activer les journaux pour les connexions de WB et le traçage DNS sur le WebAdmin du serveur CMS :

a. Connectez-vous à WebAdmin

b. Naviguez jusqu’à Logs > Detailed Tracing

c. Activez le traçage de connexion du pont Web et le traçage de DNS pour la durée souhaitée :

Les journaux de débogage de la console Chrome et Firefox peuvent servir à dépanner les échecs de connexion client WebRTC, comme les enjeux liés aux médias ou à la connectivité de WB. Il est possible de les afficher au moyen de la combinaison de touches Ctrl+Shift+C.

Sur Chrome, utilisez chrome://webrtc-internals/ ou about: webrtc sur Firefox, sous un onglet distinct au moment d’un appel en direct, pour afficher les diagnostics avancés, qui sont utiles pour résoudre les problèmes de médias avec WebRTC.

La saisie de paquets Whireshark sur le client WebRTC offre également certains renseignements utiles sur le relais de médias avec le serveur TURN.

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

Dans ce cas, le client RTC est en mesure de résoudre l’ID de l’appel pour jalero.space, mais lorsque vous entrez votre nom et sélectionnez Joincall, le client affiche Connecting (en cours de connexion), comme l’indique l’image ci-dessous :

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

Voici les étapes à suivre pour procéder au dépannage :

• 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, comme dans l’exemple ci-dessous :

  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 de CMS, le message de journal ci-dessous 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 :

• Vérifiez que Callbridge est en mesure de résoudre le FQDN de WB pour l’adresse IP interne (Callbridge ne doit pas l’établir selon l’adresse IP d’Expressway-E)
• Videz la mémoire cache DNS sur Callbridge, au moyen de l’interface de ligne de commande (CLI), avec la commande dns flush
• Vérifiez que WB tient pour fiable le certificat du serveur Callbridge (et pas son é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 de SRV _xmpp client sur le réseau interne pour le domaine CB
• Recueillez la capture Wireshark sur le client et la journalisation de diagnostic (Diagnostic logging) , y compris tcpdump sur l’Expressway-E tout en tentant d’établir une connexion avec le client externe

Naviguez jusqu’à Maintenance > Diagnostics > Diagnostic logging et assurez-vous que l’élément Take tcpdump while logging (récupérer tcpdump pendant la journalisation) est coché, comme l’indique l’image ci-dessous, avant de sélectionner Start new log (débuter un nouveau journal.) :

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 groupe de journaux téléchargés sur Expressway-E et ouvrez le fichier .pcap tiré de l’interface publique
• Procédez à un filtrage des deux captures de paquets au moyen de stun
  • Ensuite, faites une recherche pour repérer la demande contraignante provenant du client externe vers l’adresse IP publique d’Expressway-E, et cliquez avec le bouton droit pour sélectionner Follow > UDP Stream
  • De façon générale, le port de destination de la demande contraignante (Binding request) provenant du client s’inscrirait dans la plage de 24000-29999, qui correspond à la plage de ports de relais du protocole TURN sur l’Expressway-E
• Si aucune réponse aux demandes contraignantes (Binding requests) n’est reçue du côté du client, vérifiez dans 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é au moyen d’un DUAL-NIC (contrôleur d’interface réseau double) avec un mode NAT statique activé, vérifiez que la réflexion NAT est prise en charge et configurée dans votre fonction de transfert externe (External FW)

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 cas, le client RTC est en mesure de résoudre l’ID de l’appel pour jalero.space, mais lorsque vous entrez votre nom et sélectionnez Joincall, l’avertissement Unabletoconnect - try again later (connexion impossible - 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