Erläuterung und Problemumgehung zu CSCvt73723 - WebRTC Server-Leaking-Sitzungen nach einer großen Anzahl von Sitzungen auf dem Server platziert

Einleitung

Dieses Dokument beschreibt die Erkennung und Problemumgehung bei der Cisco Bug-ID CSCvt73723 rund um WebRTC Server-Leaking-Sitzungen nach einer großen Anzahl von Sitzungen auf dem Server platziert. Dies kann dazu führen, dass sich Benutzer nicht mehr als Gast bei WebBridge anmelden können.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

• Cisco Meeting Server (CMS) (CallBridge- und WebBridge-Komponente)

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf Cisco Meeting Server und insbesondere auf der WebBridge 2/CMA WebRTC Komponente. Dieses Dokument gilt nicht für die neue WebBridge 3 / CMS Web-App-Komponente, die in Version 2.9 eingeführt wurde.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.

CSCvt73723 - WebRTC-Server verlässt Sitzungen nach großen Mengen von Sitzungen auf dem Server

Wie erkennt man diesen Fehler?

Aus Endbenutzersicht besteht das Symptom darin, dass keine weiteren Benutzer mehr an einem Meeting teilnehmen können, wenn sie die maximale Anzahl erreicht haben. In den Logs, Spotting der Webbridge-Statistiken (wie in dieser FAQ) schlagen 149 NICHT unbedingt bedeuten, dass diese alle geleakten Sitzungen. Das bedeutet nur, dass die Web Bridge an ihre Grenzen stößt und keine neuen Verbindungen erlaubt sind.

"webbridge": INFO : [DEBUGGING] Statistiken 149, c:3477, d:3170

Die Berechnung, wie viele dieser Sitzungen sind durchgesickert ist ein wenig komplizierter und kann durchgeführt werden, wenn Sie NICHT mit dem CMA-Desktop-Client oder iOS-Client. Ab Version 2.8 meldet die Call Bridge alle 5 Minuten die Anzahl der CMA-Sitzungen (CMA WebRTC + CMA Desktop Client + CMA iOS Client). Beachten Sie, dass dies als "CMA" gemeldet wird: "X/Y" wobei X die aktuelle Anzahl aktiver CMA-Sitzungen und Y der Spitzenwert in den letzten 5 Minuten ist.

INFO : STATS: {"callLegsPS": 1, "callLegs": "20/24", "CMA": "14/17", "sip": {"std": "0/1", "peer": "6/6"}}

Nur weil eine Call Bridge 14 aktuelle Sitzungen meldet, bedeutet das nicht, dass die am gleichen Standort befindliche Web Bridge auch 14 Sitzungen meldet. Diese Zuordnung erfolgt auf einem einzelnen kombinierten Server im Verhältnis 1:1. In einer geclusterten Bereitstellung kann eine Web Bridge-Sitzung jedoch einen Anruf auf einer anderen Call Bridge instanziieren (insbesondere, wenn Load Balancing aktiviert ist, was bei CMA standardmäßig der Fall ist).

Um die Gesamtzahl der geleakten Sitzungen in einer Bereitstellung zu berechnen, benötigen Sie daher die kombinierten aktiven Sitzungen aus ALL den Web Bridge-Statistiken, und vergleichen Sie diese mit den kombinierten CMA Call Bridge-Statistiken, die gemeldet werden.

Wie können Sie dieses Problem vermeiden?

Abhängig davon, wie oft Ihre Bereitstellung diese Situation erreicht (einmal alle paar Tage oder einmal alle paar Wochen), müssen Sie angewiesen werden, ihre Web Bridge(s) neu zu starten, die alle geleakten Sitzungen löscht und die Anzahl der aktiven Sitzungen auf 0 zurücksetzt. Verständlicherweise kann dies mühsam sein, wenn dies zu einer täglichen Aufgabe wird, weshalb diese Aufgabe mit einem Skript gemäß dem Code-Block erleichtert werden kann.

################################################################
#### Cisco Meeting Server ####
#### Webbridge restart ####
#### Workaround for CSCvt73723 ####
#### feedback: willwoo@cisco.com ####
################################################################
#--------------------------------------------------------------
# ---------- DISCLAIMER ----------
#--------------------------------------------------------------
# Please note this script is NOT maintained or supported by Cisco.
# This is to be run at entirely your own risk.
# This script is not intended for redistribution
# Tested with python 3.7.4
#--------------------------------------------------------------
#--------------------------------------------------------------
# ---------- Libraries to import ----------
#--------------------------------------------------------------
import paramiko
import time
import datetime
#--------------------------------------------------------------
#--------------------------------------------------------------
# ---------- Deployment parameters to change ----------
#--------------------------------------------------------------
# WB Inventory - just extend or modify the below to match your deployment requirements.
# Enter the MMP IP of the server (can differ from interface webbridge service is running)
webbridges ={1:"127.0.0.1",2:"127.0.0.1",3:"127.0.0.1",4:"127.0.0.1"}

mmp_username = "admin" # MMP username
mmp_password = "password" # MMP password
#--------------------------------------------------------------
def mmp_webbridge_restart(mmp_address,uname,pword):
conn = paramiko.SSHClient()
conn.set_missing_host_key_policy(paramiko.AutoAddPolicy())
try:
conn.connect(mmp_address, 22, uname, pword)
stdin, stdout, stderr = conn.exec_command('webbridge restart')
time.sleep(1)
conn.close()
print_log_message('Webbridge on server: ' + mmp_address + ' restarted successfully')
except Exception as error:
print_log_message('Failed to restart webbridge on server ' + mmp_address + '. Error:')
print_log_message(str(error))
pass
def print_log_message(message):
time_stamp = datetime.datetime.now(datetime.timezone.utc)
time_stamp = str(time_stamp)
file = open('webbridge_restart_logs.txt', 'a')
file.write(time_stamp + " " + message + "\n")
file.close()
if __name__ == '__main__':
for wb in webbridges:
mmp_webbridge_restart(webbridges[wb], mmp_username, mmp_password)
################################################################

Das Skript erfordert einige kleine Änderungen (die Anmeldeinformationen in Zeile 29-30 und die IP-Adressen der Web Bridges in der Bereitstellung in Zeile 27) und muss NUR ausgeführt werden, wenn keine erwartete Auslastung vorliegt oder während eines Wartungsfensters. Das Skript sucht nicht nach aktiven Sitzungen und führt einfach den Befehl 'webbridge restart' auf allen aufgeführten Servern aus, wodurch keine aktive WebRTC-Sitzung beendet wird.

Um dieses Skript zu automatisieren, können Sie einen Cron-Auftrag einrichten oder einen Windows 10-PC mit der Aufgabenplanung verwenden. Wenn auf dem Windows 10-PC Python 3.4+ installiert ist, können Sie wie folgt vorgehen:

    1. Aufgabenplanung öffnen

    2. Wählen Sie 'Einfache Aufgabe erstellen...'.

    2.1 Geben Sie einen Namen/eine Beschreibung für diese Aufgabe ein.

    2.2 Wählen Sie aus, wie oft und zu welchen Zeiten diese Aufgabe ausgeführt werden soll (nur zu Zeiten außerhalb der Spitzenzeiten empfohlen, hier für jeden Samstag um 2 Uhr angezeigt)

    2.3 Wählen Sie die gewünschte Aktion aus: 'Programm starten'

    2.4 Maßnahmen:

    * Programm/Skript:  C:\<Pfad zu python.exe>

    (Wenn Sie den Pfad zu python.exe nicht kennen, finden Sie ihn, indem Sie cmd aufrufen und Folgendes eingeben: python -c "import sys; print(sys.executable)")

    * Argumente hinzufügen (optional): webbridge_restart.py (oder Name des Python-Skripts)

    * Start in (optional): C:\<Pfad zu webbridge_restart.py>

Beachten Sie, dass Computer, auf denen der Cron-Auftrag ausgeführt wird, auf die MMP der konfigurierten CMS-Server zugreifen können müssen. Nachdem das Skript ausgeführt wurde, erstellt es eine Datei webbridge_restart_logs.txt, die Details zu den Neustarts der verschiedenen WebBridges sowie zu möglichen Fehlern enthält. Ein Beispiel zeigt eine erfolgreiche Verbindung mit 10.48.79.194 und eine fehlgeschlagene Verbindung mit 127.0.0.1 (als Loopback-Adresse des PCs).

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

Wie kann ich testen, ob das Skript gut funktioniert?

Wenn Sie Python auf dem PC installiert haben, von dem aus Sie das Skript ausführen möchten, können Sie es manuell zuerst mit den folgenden Schritten ausführen:

1. Öffnen Sie cmd, und navigieren Sie mit dem Befehl 'cd' zum Speicherort des Skripts.
   
   
   
   
2. Führen Sie die Python-Datei mit dem Befehl 'python webbridge_restart.py' aus.
   
   
   
   
3. Falls Sie einen Fehler sehen, der anzeigt, dass das 'paramiko' Modul nicht installiert ist, müssen Sie eine zusätzliche Bibliothek mit dem Befehl 'pip install paramiko' installieren.
   
   
   
   
4. Nach Abschluss dieses Vorgangs können Sie das Skript erneut mit 'python webbridge_restart.py' ausführen (HINWEIS: Damit wird die Webbridge neu gestartet und die laufenden WebRTC-Verbindungen werden getrennt).
   
   Wenn es erfolgreich ausgeführt wurde, können Sie das Ergebnis in der Datei webbridge_restart_logs.txt überprüfen.

Wann soll dies behoben werden?

Dies ist kein neuer Fehler und es gibt keinen Plan, dies auf der Web Bridge 2 / CMA WebRTC zu beheben. Die neue Web Bridge 3 / CMS Web-App (ab 2.9 verfügbar) ist von diesem Bug nicht betroffen, da sie komplett neu gestaltet wurde. Kunden, die davon stark betroffen sind, müssen den Umstieg auf die neue CMS-Web-App in Betracht ziehen (obwohl dies noch nicht mit Web Bridge 2 in der Version 2.9 vergleichbar ist). Weitere Informationen hierzu finden Sie in den Versionshinweisen für CMS 2.9 und die Web-App von CMS.)

Zugehörige Informationen

• Hinweise zu Defekten: https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvt73723
• Versionshinweise: https://www.cisco.com/c/en/us/support/conferencing/meeting-server/products-release-notes-list.html
• Häufig gestellte Fragen
  • https://meeting-infohub.cisco.com/faq/content/43/450/en/how-do-you-check-the-number-of-active-sessions-on-a-web-bridge.html