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 :
Note: Un jumelage Expressway qui est utilisé pour services d’invité de Jabber ne peut être utilisé pour les services de proxy WebRTC CMS.
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.
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.
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.
Depuis le 5 février 2021, voici les navigateurs pris en charge pour CMS 3.1.1 :
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)
Note: 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.
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.
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).
Note: 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).
Note: 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
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
Note: 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.
Dans CMS 2.9.x ultérieur, utilisez le menu Configuration —> API pour ajouter des serveurs tournants :
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 :
Utilisez cette section pour confirmer que votre configuration fonctionne correctement.
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
Note: 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 :
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.
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.
Outils utiles :
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 :
Naviguez jusqu’à Logs > Event logs sur le WebAdmin de CMS
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.
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 when logging est coché, comme illustré dans cette image, avant de sélectionner Start new log :
Note: 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.
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.