Verschieben von Web-App-Benutzern aus Räumen/Meetings in CMS

Einleitung

In diesem Dokument wird die Möglichkeit beschrieben, Teilnehmer mithilfe von Cisco Meeting Management (CMM) von einem Meeting zu einem anderen zu verschieben. CMM-Administratoren können Teilnehmer von Web-Anwendungen zwischen Meetings mit derselben oder mit unterschiedlichen Anrufbrücken verschieben.

Voraussetzungen

Anforderungen

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

• Grundlegendes Wissen zu Cisco Meeting Server (CMS)
• CMM - Grundlegendes Wissen.
• CMS Web-App Grundlegendes Wissen.

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

• CMS-Version 3.2
• CMM-Version 3.2
• CMS-Webanwendung Version 3.2.
• Webbrowser Chrom 91.

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.

Konfigurieren

Hintergrundinformationen

Die Möglichkeit, Teilnehmer von einem Meeting zu einem anderen Meeting per CMM zu verschieben, wurde ursprünglich in CMS 2.6 vorgestellt, es gelten jedoch einige Einschränkungen, d. h. Meeting-App, Web-App und Skype for Business (SfB)-Teilnehmer können nicht verschoben werden. Ab CMS 3.2 kann der CMM-Administrator Web-App-Teilnehmer zwischen Meetings mit derselben oder unterschiedlichen Anrufbrücken verschieben.

Anmerkung: Diese Funktion bedeutet nicht, dass Web-App-Teilnehmer einen Zug anderer Teilnehmer auslösen können. Bislang verhinderte CMM dies durch eine Warnung, wenn versucht wurde, Web-App-Teilnehmer zu verschieben. Diese Einschränkung wird von CMM automatisch erkannt, wenn das Meeting auf CMS 3.2 gehostet wird und verschoben werden kann.

Netzwerkdiagramm

Konfigurationen

Schritt 1: CMM führt einen API-Aufruf für Callbridge B mit der Methode POST /calls/<call_X_id>/participants/ mit "moveParticipant"=participant_A_guid durch.

Schritt 2: Callbridge B sendet Teilnehmer-Verschiebungsanforderungen an Callbridge A.

Schritt 3: Callbridge A antwortet mit der Verschiebungsanforderung zurück zu Callbridge B.

Schritt 4: Callbridge B führt einen Lastenausgleich durch und beschließt, einen neuen Teilnehmer für Callbridge C zu platzieren.

Schritt 5: Callbridge B sendet eine Anfrage an Callbridge C, um eine neue Teilnehmerinstanz und einen neuen Teilnehmer zu erstellen. Für guest wird eine neue Gast-ID erstellt. Die neue Teilnehmerinstanz hat ein neues JASON Web Token (JWT).

Schritt 6: Callbridge C sendet API-Move-Web-Socket-Nachricht über Call Bridge to Web Bridge (C2W) an Webbridge A.

Schritt 7: Webbridge A sendet die Move Web Socket Nachricht an den Webbridge Client (WC3) im Browser.

Schritt 8. WC3 im Browser sendet End-Web-Socket-Nachricht an Webbridge A.

Schritt 9: Webbridge A leitet die End Session-Nachricht an Callbridge A weiter.

Schritt 10: Callbridge A zerstört die Teilnehmerinstanz und den alten JWT.

Schritt 11. Der WC3-Client im Browser authentifiziert sich in einer neuen Web-Socket-Nachricht an Webbridge A und verwendet eine neue JWT.

Überprüfung

Nachfolgend finden Sie die Beispiel-Protokollmeldungen, in denen der Gast-Webteilnehmer aus dem Space 1- (webapp.com) in den Space 2- (webapp.com) verschoben wird. Um den Fluss zu vereinfachen, bleibt der Wechsel zu einem anderen Speicherplatz auf derselben Anrufbrücke "cbcms2" (Cluster hat Lastenausgleich).

Der Umzugsfluss beginnt mit dem API-POST/Anrufen/<Anruf-ID>/den Teilnehmern.

2021-03-04  15:50:03.915  Info     API trace 42003: POST for "/api/v1/calls/ae778701-7fed-410c-b3e6-c2860907a3f4/participants" (from 172.19.233.174)
2021-03-04  15:50:03.915  Info     API trace 42003: content data size 75, type "application/x-www-form-urlencoded":
2021-03-04  15:50:03.915  Info     API trace 42003:  movedParticipant=26de0160-30b5-4d7b-8a05-304472a
2021-03-04  15:50:03.915  Info     API trace 42003:      f284a&
2021-03-04  15:50:03.915  Info     API trace 42003:  needsActivation=false

Verschieben Sie den Teilnehmer zu einem anderen Anruf. Erstellen Sie zunächst ein neues Gastkonto (guest2316075499).

2021-03-04  15:50:03.915  Info     move participant operation: moving WC3 participant 26de0160-30b5-4d7b-8a05-304472af284a (guest921953266) (homed on this callbridge) to call ae778701-7fed-410c-b3e6-c2860907a3f4
2021-03-04  15:50:03.915  Info     guest login request 0: credential storage scheduled (queue length: 1)
2021-03-04  15:50:03.915  Info     created guest account with user ID "guest2316075499"
2021-03-04  15:50:03.915  Info     guest login request 0: credential storage executed
2021-03-04  15:50:03.915  Info     guest login request 0: credential storage in progress
2021-03-04  15:50:03.921  Info     guest login request 0: successfully stored credentials
2021-03-04  15:50:03.921  Info     replace query for conference c3958a89-3007-4959-99e7-f6ea84609aac: response from 'cbcms2' (priority: 0, load level: 0, conference is running: 1)
2021-03-04  15:50:03.921  Info     replace query for conference c3958a89-3007-4959-99e7-f6ea84609aac: using local server 'cbcms2' (priority: 0, load level: 0, conference is running: 1)
2021-03-04  15:50:03.921  Info     API call leg dd2bc8c6-fa80-495f-9a20-1da19010cfab in call c0cc4e15-bb74-4af3-948b-672c9571c7fc (API call ae778701-7fed-410c-b3e6-c2860907a3f4)
2021-03-04  15:50:03.922  Info     172.19.233.174: API user "admin" created new participant dd2bc8c6-fa80-495f-9a20-1da19010cfab, call ae778701-7fed-410c-b3e6-c2860907a3f4
2021-03-04  15:50:03.922  Info     API trace 42003: sending 200 response, size 0
2021-03-04  15:50:03.922  Info     API trace 42003: Location: /api/v1/participants/dd2bc8c6-fa80-495f-9a20-1da19010cfab
2021-03-04  15:50:03.923  Info     new session created for user "guest2316075499"
2021-03-04  15:50:03.923  Info     instantiating user "guest2316075499"

Löschen Sie den alten Benutzer guest921953266, und beenden Sie den vorherigen Anruf, Anruf 19.

2021-03-04  15:50:03.947  Info     user "guest921953266": deactivating due to session resource teardown
2021-03-04  15:50:03.948  Info     call 19: tearing down ("guest921953266" conference media)
2021-03-04  15:50:03.948  Info     participant "guest921953266" left space 89eae70d-5b67-41fc-97f7-38a655fa6467 (Space 1 (webapp.com))
2021-03-04  15:50:03.948  Info     call 19: destroying API call leg 26de0160-30b5-4d7b-8a05-304472af284a
2021-03-04  15:50:03.948  Info     removing guest account 'guest921953266' (name 'User X') on call drop
2021-03-04  15:50:03.948  Info     destroying guest account with user ID "guest921953266"

Mediensitzung für den neuen Anruf (Anruf 20) wurde erfolgreich eingerichtet.

2021-03-04  15:50:04.106  Info     call 20: allocated for guest2316075499 / "User X" conference participation (Chrome)
2021-03-04  15:50:04.106  Info     call 20: removing h264 from video codec bitmask, because it's Chrome web client and we're using a compatibility profile
2021-03-04  15:50:04.106  Info     call 20: configured - API call leg dd2bc8c6-fa80-495f-9a20-1da19010cfab
2021-03-04  15:50:04.107  Info     call 20: setting up combined RTP session for DTLS (combined media and control)
2021-03-04  15:50:04.108  Info     participant "guest2316075499" joined space 59b9e43e-b277-4d33-a244-e896d20f2049 (Space 2 (webapp.com))
2021-03-04  15:50:04.108  Info     participant "guest2316075499" (dd2bc8c6-fa80-495f-9a20-1da19010cfab) joined conference c0cc4e15-bb74-4af3-948b-672c9571c7fc via WB3

Wenn die Web-App eine Verschiebungsanforderung empfängt, trennt sie den aktuellen Anruf und startet dann den Join-Prozess mit dem neuen JWT erneut. Nach dem Umzug sieht der Teilnehmer die Nachricht Sie wurden zu einem neuen Anruf in der rechten unteren Ecke verschoben. Dies bedeutet, dass sich der Anruf nun in einem neuen Meeting befindet, wie im nächsten Bild gezeigt. Der Text nach der Nachricht Now in (Jetzt in) ist der Leerzeichenname in diesem Fall Space 2.

Einige lokale Web-App-Meeting-Status wie Stummschaltung und Layout werden vom vorherigen Anruf übernommen. Wenn ein Teilnehmer beispielsweise lokal stummgeschaltet wird, bleibt er während des neuen Anrufs stummgeschaltet.

Die nächsten Funktionen werden nicht auf den neuen Anruf übertragen:

• Präsentation: Wenn ein Teilnehmer verschoben wird, wird die aktive Präsentation verworfen. In der neuen Besprechung, die nach dem Umzug stattfindet, wird die Freigabe nicht vom Teilnehmer freigegeben.
• Chatnachrichten: Ältere Chatnachrichten werden aus dem Chat entfernt und nicht in das neue Meeting übertragen.

Fehlerbehebung

Problem: Die Teilnehmer der Web-App bleiben unbewegt.

Es könnte viele Dinge bedeuten:

1. Nichts geschah. Der Anruf ist immer noch mit dem ersten Anruf verbunden.
2. Verworfen, aber keine erneute Verbindung hergestellt. Der Anruf wird fallen gelassen, es wird jedoch keine Verbindung zum zweiten Anruf hergestellt.
3. Stellt eine Verbindung zum falschen Meeting her.

Für Szenario a. Es ist nichts passiert:

• Stellen Sie sicher, dass die Anrufbrücke die Anforderung zum Wechseln von CMM erhält. Informationen zu bestimmten Schlüsselwörtern, z. B. zum Verschieben von Teilnehmern, finden Sie in den CMS-Protokollmeldungen. Wenn CMS keine API von CMM empfängt, führen Sie eine grundlegende Fehlerbehebung zwischen CMM und CMS durch, indem Sie API-Ablaufverfolgung auf beiden Seiten, DNS-Prüfungen (Domain Name Service) und Konnektivitätsprüfungen aktivieren.
• Überprüfen Sie, ob der canMove-Parameter in /participants/<Teilnehmer-ID> oder /callLegs/<CallLeg-ID> auf true festgelegt ist.

Bei Szenario b. Verworfen, aber keine erneute Verbindung hergestellt:

• Stellen Sie sicher, dass die Verbindung aufgrund einer Verschiebung getrennt wird, d. h. suchen Sie im Protokoll nach der Aktion des Verschiebungsteilnehmers.
• Suchen Sie in CMS-Protokollen nach Ressourcenfehlern/Blockierungen auf der Anrufbrücke, die die Erstellung der Teilnehmer verhindern könnten.
• Hat der Teilnehmer die Berechtigung, dem neuen Cospace beizutreten?
• Ist bei JWT ein Fehler aufgetreten?
• Versuchen Sie, dem Meeting manuell beizutreten.

Für Szenario c. Stellen Sie eine Verbindung mit dem falschen Meeting her:

Schauen Sie sich in der HAR-Datei (Hyper Text Transport Protocol (HTTP) Archive Format) den Web-Socket des ersten Anrufs an. Die Daten der Zugriffsmethode für POST /api/call/session/move zeigen die numerische ID an, die für die Verbindung mit dem neuen Anruf verwendet wird. Stellen Sie sicher, dass es sich bei dieser numerischen ID um die beabsichtigte Konferenz handelt.