Configurer le proxy WebRTC de CMS surExpressway Contenu

IntroductionConditions préalablesConditions requises  Composants utilisésInformations généralesConfigurerDiagramme du réseauConfiguration StepsÉtape 1. Intégrez CMS WB dans Expressway-CÉtape 2. Activez le protocole TURN de Expressway-E et ajoutez l’information d’authentificationdans la base de données locale de l’authentificationÉtape 3. Modifiez le port d’administration de l’Expressway-E (facultatif)Étape 4. Ajoutez l’Expressway-E comme serveur(s) du protocole TURN pour la traverse NAT demédias sur le serveur CMSVérifierÉtape 1. Dans Expressway-C, vérifiez que le WB est correctement intégréÉtape 2. Vérifiez que le serveur du protocole TURN a été ajouté au serveur CMSÉtape 3. Vérifiez l’utilisation du relayage du protocole TURN pendant un appelDépannerLe client WebRTC externe se connecte, mais sans support (en raison de l’échec ICE)Le client WebRTC externe n’a pas accès à l’option pour participer à l’appel (Join Call).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.Il est impossible pour le client WebRTC de se joindre à l’espace partagé et il reçoit unavertissement lui indiquant que la connexion est impossible et qu’il devra réessayer plus tard(Unable to connect - try again later).Informations connexes

Introduction

Ce document décrit les étapes pour configurer, vérifier et dépanner WebRTC du serveur deré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’appelCallBridge doivent être configurés et activés sur CMS; cliquez ici pour le guide deconfiguration

●

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 del’Expressway-E

●

Le Port 3478 TCP et UDP (requêtes du protocole TURN) est ouvert sur le pare-feu del’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 IPpublique 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 toutefoisque 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'unenvironnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ontdémarré avec une configuration effacée (par défaut). Si votre réseau est en ligne, assurez-vousde 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. Celapermet aux utilisateurs hors lieux de naviguer vers un pont Web de serveur de réunion de Cisco.

https://www.cisco.com/c/fr_ca/support/unified-communications/expressway-series/products-installation-and-configuration-guides-list.html/content/dam/en/us/td/docs/conferencing/ciscoMeetingServer/Deployment_Guide/Version-2-2/Cisco-Meeting-Server-2-2-Single-Combined-Server-Deployment.pdfhttps://www.cisco.com/c/fr_ca/support/docs/security/ios-network-address-translation-nat/212392-configure-nat-reflection-on-the-asa-for.html

Les clients externes et les invités peuvent gérer des espaces ou s’y joindre sans avoir besoind’autre logiciel, à part un navigateur pris en charge. Cliquez ici pour obtenir la liste desnavigateurs pris en charge.

Configurer

Diagramme du réseau

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

https://www.cisco.com/c/fr_ca/support/conferencing/meeting-server/products-installation-and-configuration-guides-list.html

Remarque: Vous devez configurer votre pare-feu externe pour permettre une réflexion NATpour l’adresse IP publique sur Expressway-E (habituellement, les pare-feu ne tiennent paspour 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 CMSWebAdmin (interface GUI Web) sans le préfixe https:// .

Étape 2. Activez le protocole TURN de Expressway-E et ajoutez l’information d’authentificationdans 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 etajoutez 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 lesnœ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 ladeuxième instance turnServer devrait être semblable; pour la réaliser, il faudra toutefoisutiliser les adresses IP et les renseignements d’authentification du protocole TURN serattachant à l’autre serveur Expressway-E).

/content/dam/en/us/td/docs/telepresence/infrastructure/vcs/config_guide/X8-9/Cisco-VCS-Certificate-Creation-and-Use-Deployment-Guide-X8-9.pdf

É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 portde l’administrateur Web à 445 parmi les options de menu déroulant, puis sélectionnez la fonctiond’enregistrement (Save)

c. Répétez les étapes 3a à 3b pour tous les Expressway-E utilisés pour les services de proxyWebRTC

Remarque: Cisco recommande la modification du port d’administration, car les clientsWebRTC 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 demé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, parexemple : https://:445/api/v1/

c. Envoyer un message (POST) avec https://:445/api/v1/turnservers, après avoirajouté 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 :

https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop?hl=enhttps://%3cCallbridge_IP%3e:445/api/v1/recorders

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 vousdevriez voir l’adresse IP de WB :

b. Naviguez jusqu’à Configuration > Unified Communication > HTTP allow list > Automaticallyadded 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 leWB 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-Cpour l’Expressway-E et qu’il est actif. Naviguez jusqu’à Status > Unified Communications > UnifiedCommunications SSH tunnels status; vous devriez voir le FQDN de WB et la cible doit êtrel’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 pourconsulter les journaux d’événement. Vous pourrez consulter l’adresse IP du serveur TURN,comme dans l’exemple :

2017-04-1509:37:26.864InfoTURN 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êteGET request auprès d’un client d’API au moyen de cette commande :

https://:445/api/v1/turnservers

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

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

10.48.79.129

175.6.7.9

10.48.36.248

175.6.7.8

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://:445/api/v1/turnservers//status

Cela produira de l’information, dont la durée totale aller-retour (RTT) en millisecondes (Ms) qui estassociée au serveur du protocole TURN. Cette information est importante dans la sélection de CBpour 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 :

success

10.48.36.248

3478

true

37

10.48.36.5

44920

L’information ci-dessous présente l’état du serveur du protocole TURN avec l’ID eef94a2b-3bfa-40f7-b83c-ece8df424e15:

success

10.48.79.129

3478

true

48

10.48.36.5

44920

É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’étatdu 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 dedépannage liées à votre configuration, à certains problèmes WebRTC standard et auxdéfaillances possibles.

Il est possible d’activer les journaux pour les connexions de WB et le traçage DNS sur leWebAdmin 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 échecsde connexion client WebRTC, comme les enjeux liés aux médias ou à la connectivité de WB. Il estpossible 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 ongletdistinct au moment d’un appel en direct, pour afficher les diagnostics avancés, qui sont utiles pourrésoudre les problèmes de médias avec WebRTC.

La saisie de paquets Whireshark sur le client WebRTC offre également certains renseignementsutiles 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, maislorsque vous entrez votre nom et sélectionnez Joincall, le client affiche Connecting (en cours deconnexion), 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 ladé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 lesrenseignements d’authentification configurés au serveur TURN Expressway-E ACTIVATION sur leport 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 :

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

Solution :

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

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

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éseauinterne pour le domaine CB

●

Recueillez la capture Wireshark sur le client et la journalisation de diagnostic (Diagnosticlogging) , y compris tcpdump sur l’Expressway-E tout en tentant d’établir une connexion avecle client externe

●

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

Remarque: Assurez-vous que la capture Wireshark sur le périphérique du client et lajournalisation 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 journalisationsur 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 lefichier .pcap tiré de l’interface publique

●

Procédez à un filtrage des deux captures de paquets au moyen de stun Ensuite, faites unerecherche pour repérer la demande contraignante provenant du client externe vers l’adresseIP publique d’Expressway-E, et cliquez avec le bouton droit pour sélectionner Follow > UDPStreamDe façon générale, le port de destination de la demande contraignante (Bindingrequest) provenant du client s’inscrirait dans la plage de 24000-29999, qui correspond à laplage 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é duclient, 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 transfertexterne (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éseaudouble) avec un mode NAT statique activé, vérifiez que la réflexion NAT est prise en chargeet 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, maislorsque vous entrez votre nom et sélectionnez Joincall, l’avertissement Unabletoconnect - tryagain 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●

/content/dam/en/us/td/docs/voice_ip_comm/expressway/config_guide/X8-9/Cisco-Expressway-IP-Port-Usage-for-Firewall-Traversal-Deployment-Guide-X8-9-2.pdfhttps://www.cisco.com/c/fr_ca/support/index.html

Configurer le proxy WebRTC de CMS sur ExpresswayContenuIntroductionConditions préalablesExigences Composants utilisés

Informations généralesConfigurerDiagramme du réseauConfiguration StepsÉtape 1. Intégrez CMS WB dans Expressway-CÉ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Étape 3. Modifiez le port d’administration de l’Expressway-E (facultatif)Étape 4. Ajoutez l’Expressway-E comme serveur(s) du protocole TURN pour la traverse NAT de médias sur le serveur CMS

VérifiezÉtape 1. Dans Expressway-C, vérifiez que le WB est correctement intégréÉtape 2. Vérifiez que le serveur du protocole TURN a été ajouté au serveur CMSÉtape 3. Vérifiez l’utilisation du relayage du protocole TURN pendant un appel

DépannerLe client WebRTC externe se connecte, mais sans support (en raison de l’échec ICE)Le client WebRTC externe n’a pas accès à l’option pour participer à l’appel (Join Call).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.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).

Informations connexes