Explication et Travail-autour de sur CSCvt73723 - Sessions disjointes de serveur de WebRTC après un grand nombre de sessions placées sur le serveur

Introduction

Ce document décrit la détection et travail-autour de sur l'id CSCvt73723 de bogue Cisco autour des sessions disjointes de serveur de WebRTC après un grand nombre de sessions placées sur le serveur. Cela peut par la suite entraîner des utilisateurs à incapable d'ouvrir une session ou se joindre comme invité sur le WebBridge.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Cisco rencontrant le serveur (CMS) (composant de CallBridge et de WebBridge)

Composants utilisés

Les informations dans ce document sont basées sur Cisco rencontrant le serveur et en particulier autour du composant de WebBridge 2/CMA WebRTC. Ce document ne s'applique pas pour le nouveau composant d'app de Web de WebBridge 3/CMS qui a été introduit dans la version 2.9.

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.

CSCvt73723 - Sessions disjointes de serveur de WebRTC après un grand nombre de sessions placées sur le serveur

Comment identifiez-vous cette bogue ?

Le symptôme d'un point de vue d'utilisateur final est une fois qu'ils ont frappé la limite dure et aucun autre utilisateur ne peut joindre une téléconférence. Dans les logs, repérant les stats de webbridge (selon cette Foire aux questions) frappent 149 n'implique pas nécessairement ces derniers sont tous des sessions coulées. Ceci signifie juste que la passerelle de Web a frappé sa limite dure et aucune nouvelle connexion n'est permise.

« webbridge » : INFORMATION : [Stats 149 de DÉBOGAGE], c:3477, d:3170

Le calcul lesquels de ces derniers sont des sessions coulées est un peu plus compliqué et peut être fait si vous n'utilisez pas le client de bureau de CMA ou le client IOS. De la version 2.8, la passerelle d'appel signale chaque 5 minute le nombre de sessions CMA (client de bureau CMA WebRTC + CMA + client IOS CMA). Notez ceci est signalé comme « CMA » : « X/Y » où X est le nombre en cours de sessions actives de CMA et Y est la crête dans les 5 dernières minutes.

INFORMATION : STATS : {« callLegsPS » : 1, « callLegs » : "20/24", « CMA » : "14/17", « sip » : {« DST » : "0/1", « pair » : "6/6"}}

Juste parce qu'une passerelle d'appel signale la session en cours 14 ne veut pas dire que la passerelle coïmplantée de Web signale également 14 sessions. Ce mappage est 1:1 sur un serveur combiné simple mais dans un déploiement groupé une session de passerelle de Web peut instancier un faire appel à une passerelle différente d'appel (particulièrement quand l'Équilibrage de charge est activé - que qui il est par défaut pour CMA).

Par conséquent, afin de calculer le nombre total de sessions coulées dans un déploiement vous avez besoin des sessions actives combinées de TOUS LES stats de passerelle de Web et comparez ceci aux stats combinés de passerelle d'appel de CMA qui sont signalés.

Comment pouvez-vous éviter cette question ?

Selon combien de fois votre déploiement frappe cette situation (une fois que chaque couple des jours ou une fois chaque couple des semaines), vous devez être informé redémarrer leurs passerelles de Web ce qui efface toutes les sessions coulées et remettre à l'état initial les sessions actives comptez à 0. tout naturellement que ceci peut être pénible si ceci devient une corvée quotidienne par conséquent pourquoi cette tâche peut être facilitée avec un script disponible ici :

Le script exige un certain petit édite (les qualifications sur ligne 29-30 et adresses IP des passerelles de Web dans le déploiement sur ligne 27) et doit SEULEMENT être exécuté quand il n'y a aucun chargement prévu ou pendant une fenêtre de maintenance. Le script ne vérifie pas des sessions actives et exécute simplement la commande « de reprise de webbridge » sur tous les serveurs répertoriés qui termine n'importe quelle session active de WebRTC.

Pour automatiser ce script, il peut être fait en installant un travail de cron ou sur un PC de Windows 10 avec le programmateur de tâche. Assumer le PC de la victoire 10 a le python 3.4+ les a installés peut suivre ces étapes :

    1. Ouvrez le programmateur de tâche

    2. Choisi « créez la tâche de base… »

    2.1 Écrivez un nom/description pour cette tâche

    2.2 Sélectionnez quelle fréquence et vous chronomètre veut exécuter cette tâche (recommandée pour avoir lieu seulement pendant des périodes creuses, ici affichées pour chaque samedi à 2AM)

    2.3 Action d'exécuter, choisi : « Commencez un programme »

    2.4 Action :

    * Programme/script :  <path de C:\ à python.exe>

    (si vous ne connaissez pas le chemin à python.exe, il peut être trouvé en allant au cmd et en tapant : système d'importation de python-C « ; print(sys.executable) ")

    * Ajoutez les arguments (facultatifs) : webbridge_restart.py (ou nom de script de python)

    * Début dedans (facultatif) : <path de C:\ à webbridge_restart.py>

Notez cet ordinateur qui exécute le travail de cron doit pouvoir accéder au MMP des serveurs CMS configurés. Après que le script ait fonctionné, il crée un fichier de webbridge_restart_logs.txt qui contient des détails sur les reprises du WebBridges différent aussi bien que de toutes les pannes potentielles. Un exemple est affiché avec une connexion réussie à 10.48.79.194 et à un un manquant à 127.0.0.1 (en tant qu'étant l'adresse de bouclage du PC réellement).

2020-06-08 14:53:18.149915+00:00 Webbridge on server: 10.48.79.194 restarted successfully 2020-06-08 14:53:19.165543+00:00 Failed to restart webbridge on server 127.0.0.1. Error: 2020-06-08 14:53:19.165543+00:00 [Errno None] Unable to connect to port 22 on 127.0.0.1