Avez-vous un compte?
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 et dépanner Cisco rencontrant le serveur (CMS) WebRTC au-dessus d'Expressway.
Cisco vous recommande de prendre connaissance des rubriques suivantes :
Conditions préalables à la configuration :
Note: Des paires d'Expressway qui sont utilisées pour des services d'invité de Jabber ne peuvent pas être utilisées pour des services proxys CMS WebRTC.
Ce document n'est pas limité au logiciel et aux versions de matériel spécifiques, toutefois les exigences de version logicielle minimale doivent être répondues.
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 vivant, assurez-vous que vous comprenez l'impact potentiel de n'importe quelle commande.
Le support de proxy de WebRTC a été ajouté à Expressway de la version X8.9.2, qui permet aux utilisateurs hors-lieu de parcourir à Cisco rencontrant la passerelle de Web de serveur.
Les clients externes et les invités peuvent gérer ou joindre les espaces sans besoin de n'importe quel logiciel autre qu'un navigateur pris en charge. A cliquez ici pour une liste de navigateurs pris en charge.
Cette image fournit un exemple des connexions circulent du proxy de Web pour CMS WebRTC :
Note: Vous devez configurer votre pare-feu externe pour permettre la réflexion NAT pour l'IP address public d'Expressway-e (les Pare-feu se méfient typiquement des paquets qui ont le même IP address de source et de destination).
a. Naviguez vers la configuration > transmission unifiée > Cisco rencontrant le serveur
b. Proxy de Web de serveur de téléconférence d'enable
c. Écrivez le FQDN du WB dans le domaine d'URI de client de compte d'invité
d. Cliquez sur en fonction la sauvegarde
e. Ajoutez le FQDN du WB sur le certificat de serveur d'Expressway-e comme nom alternatif soumis (SAN), avez cliquez ici pour le guide de certificat d'Expressway.
Note: L'URI de client de compte d'invité doit être comme configuré sur le serveur WebAdmin (interface gui CMS de Web) sans préfixe de https://.
a. Naviguez vers la configuration > la traversée > le TOUR
b. Activez les services de TOUR, d'hors fonction à en fonction
c. Choisi configurez les qualifications de client de TOUR sur la base de données locale et ajoutez les qualifications (le nom d'utilisateur et mot de passe)
Note: Si vous avez une batterie d'Expressway-e et ils sont tous à utiliser comme serveurs de TOUR, alors assurez pour l'activer sur tous les Noeuds.
a. Naviguez vers le système > la gestion
b. Sous la configuration de serveur Web, changez le port d'administrateur Web à 445 des options de déroulant, puis sélectionnez la sauvegarde
c. Répétez les étapes 3a à 3b sur tout l'Expressway-e utilisé pour des services proxys de WebRTC
Note: Cisco recommande la gestion que le port soit changé parce que l'utilisation 443 de clients de WebRTC. Si les essais de navigateur de WebRTC au port d'accès 80, Expressway-e réoriente la connexion à 443.
a. Téléchargez et installez le facteur d'ici.
b. Écrivez l'URL d'accès API dans la barre d'adresses, par exemple ; https://<Callbridge_fqdn>:445/api/v1/<entity>
c. Envoyez un POST avec https://<Callbridge_fqdn>:445/api/v1/turnservers, après que vous ajoutiez ces champs dans le corps :
d. Répétez l'étape 4c pour que chaque serveur d'Expressway-e soit utilisé pour le TOUR
Ces images fournissent des exemples des étapes basées sur la configuration :
Utilisez cette section pour confirmer que votre configuration fonctionne correctement.
a. Naviguez vers la configuration > transmission unifiée > Cisco rencontrant le serveur, et vous devez voir l'adresse IP du WB :
b. Naviguez vers la configuration > transmission unifiée > HTTP permettent la liste > a automatiquement ajouté des règles, contrôle que ceci 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: On ne s'attend pas à ce qu'il trouve le WB dans les Noeuds découverts parce que les règles sont simplement de tenir compte du proxy du trafic HTTPS au WB, et pas nécessairement pour la transmission unifiée.
c. Vérifiez que le tunnel de Protocole Secure Shell (SSH) pour le FQDN WB a été construit sur Expressway-C à Expressway-e et qu'il est en activité. Naviguez vers l'état > des transmissions unifiées > état unifié de tunnels de SSH de transmissions, vous devez voir que le FQDN du WB et de la cible doit être Expressway-e :
a. Sur le WebUI, si vous utilisez un serveur simple d'Expressway, naviguez vers des logs > des journaux d'événements, la sortie affiche l'adresse IP du serveur de TOUR, 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 de plusieurs serveurs de TOUR d'Expressway, envoyez une demande GET avec un api client avec cette commande :
https://<Callbridge_IP>:445/api/v1/turnservers
Note: Cette commande peut également être utilisée si vous avez un serveur simple de TOUR d'Expressway.
La sortie, dans le cas de plusieurs serveurs de TOUR d'Expressway, est semblable à celle dans cet exemple :
<?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 de TOUR faites ce qui suit :
https://<Callbridge_IP>:445/api/v1/turnservers/<turnServer id>/status
L'affiche des informations de sortie qui inclut le Round-Trip Time (DURÉE DE TRANSMISSION) en quelques millisecondes (ms) a associé le serveur de TOUR. Il est importante pour la sélection de CB du meilleur serveur de TOUR l'utiliser ces informations.
La sortie ci-dessous affiche l'état pour le serveur de TOUR 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>
La sortie ci-dessous affiche l'état pour le serveur de TOUR 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>
Au moment d'un appel vivant qui est fait avec l'utilisation du client de WebRTC, vous pouvez visualiser l'état de relais de medias de TOUR sur Expressway. Naviguez vers l'utilisation de relais d'état > de TOUR, puis sélectionnez la vue.
Cette section fournit les informations que vous pouvez employer pour dépanner votre configuration, quelques questions typiques de WebRTC et pannes possibles.
Des logs pour les connexions WB et la découverte de DN peuvent être activés sur le WebAdmin du serveur CMS :
a. Connectez au WebAdmin
b. Naviguez vers des logs > a détaillé le suivi
c. Activez le suivi et les DN de montage en pont de Web traçant pour la durée désirée :
Le debug logging de console de Chrome et de Firefox peut être utilisé pour dépanner des pannes de connexion client de WebRTC, telles que des questions avec des medias et la Connectivité au WB. Ceci peut être rendu visible avec l'utilisation de la combinaison Ctrl+Shift+C. de clavier.
Sur Chrome, utilisation chrome://webrtc-internals/ ou environ : webrtc sur Firefox, sur un onglet distinct au moment d'un appel vivant pour afficher les diagnostics avancés, qui est utile pour dépanner des questions de medias avec WebRTC.
La capture de paquet de Whireshark sur le client de WebRTC fournissent également à quelques informations utiles au sujet du relais de medias le serveur de TOUR.
Dans ce scénario, le client RTC peut résoudre l'ID d'appel à jalero.space, mais quand vous entrez dans votre nom et Joincall choisi, le client affiche se connecter, comme affiché sur l'image ci-dessous :
Après environ 30 secondes, il est réorienté à la page WB d'initiale.
Pour dépanner, faites ce qui suit :
Naviguez vers des logs > l'événement ouvre une session le CMS WebAdmin
Dans les suivis de Wireshark, vous voyez que le client envoie allouent la demande avec les qualifications configurées, au serveur de TOUR d'Expressway-e 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 allouent l'erreur :
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 logs CMS, le message de log ci-dessous est affiché :
2017-04-15 10:34:56.536 Warning call 7: ICE failure 4 (unauthorized - check credentials)
Solution :
Vérifiez les qualifications de TOUR configurées sur le CMS et assurez-vous qu'il apparie cela qui est configuré sur la base de données d'authentification locale d'Expressway-e.
Sur l'état de Callbridge > la page générale, ceci est affichée :
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 :
Naviguez vers la maintenance > les diagnostics > le diagnostic se connectant et assurez-vous que tcpdump de prise tout en se connectant est vérifié comme affiché sur l'image ci-dessous, avant que vous sélectionniez le nouveau log de début :
Note: Assurez-vous que la capture Wireshark sur le périphérique du client et ouvrir une session Expressway-e sont commencés avant de reproduire l'appel manquant. Quand l'appel manquant a été reproduit, arrêtez et téléchargez ouvrir une session Expressway-e et la capture sur le client.
Dans ce scénario, le client RTC peut résoudre l'ID d'appel à jalero.space, mais quand vous entrez dans votre nom et Joincall choisi, l'Unableto d'avertissement se connectent - l'essai de nouveau plus tard est affiché immédiatement :
Solution :
Vérifiez que le CMS, sur le réseau interne, peut résoudre toujours l'enregistrement SRV _xmpp-client pour le domaine de CB.