Toepassingsgebruikers vanuit ruimtes/vergaderingen in CMS verplaatsen

Inleiding

Dit document beschrijft de mogelijkheid om deelnemers van één vergadering naar een andere vergadering door Cisco Meeting Management (CMM) te verplaatsen. CMM-beheerder kan deelnemers van web-app verplaatsen tussen vergaderingen van een of andere callbruggen.

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• Cisco Meeting Server (CMS) basiskennis.
• CMM basiskennis.
• CMS web app basis kennis.

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

• CMS versie 3.2
• CMM versie 3.2
• CMS web app versie 3.2.
• Webbrowser, chrome 91.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk levend is, zorg er dan voor dat u de mogelijke impact van om het even welke opdracht begrijpt.

Configureren

Achtergrondinformatie

Het vermogen om deelnemers van een vergadering naar een andere vergadering van CMM te verplaatsen is oorspronkelijk voorzien in CMS 2.6, maar met enige beperkingen, dat wil zeggen, de vorm van een vergaderapp, webapp en Skype voor Business (SfB) deelnemers kunnen niet worden verplaatst. Start met CMS 3.2 kan de CMM-beheerder webapp deelnemers verplaatsen tussen vergaderingen van dezelfde of andere callbruggen.

Opmerking: Deze optie betekent niet dat deelnemers aan web app een beroep kunnen doen op andere deelnemers. In een eerder stadium waarin werd geprobeerd deelnemers aan web app te verplaatsen, had CMM dit voorkomen met een waarschuwing. Deze beperking wordt automatisch door CMM gedetecteerd, indien de vergadering wordt gehouden op CMS 3.2 en zou kunnen bewegen.

Netwerkdiagram

Configuraties

Stap 1. CMM maakt Application Programing Interface (API) bellen naar Callbridge B met methode POST/Call/<Call_X_id>/deelnemers/ met "MoveParticipant"=participant_A_guid.

Stap 2. Callbridge B stuurt deelnemersverzoeken om verplaatsing naar Callbridge A.

Stap 3. Callbridge A reageert met de verplaatsingsaanvraag terug naar Callbridge B.

Stap 4: Callbridge B laadt de balans op en besluit nieuwe deelnemers aan Callbridge C te plaatsen.

Stap 5. Callbridge B stuurt een verzoek naar Callbridge C om nieuwe deelnemersinstantie en deelnemer te creëren. Voor gasten wordt er een nieuwe gast-id gemaakt. De nieuwe deelnemersinstantie heeft een nieuwe JASON Web Tokens (JWT).

Stap 6. Callbridge C stuurt API-bericht van bewegingswebsocket via Call Bridge naar Web Bridge (C2W) naar Webbridge A.

Stap 7. Webbridge A stuurt het bericht van de websocket naar de Webbridge Client (WC3) in de browser.

Stap 8. WC3 in browser stuurt end web socket bericht naar Webbridge A.

Stap 9. Webbridge A forwards end sessie to Callbridge A.

Stap 10. Callbridge A vernietigt de deelnemersinstantie en de oude JWT.

Stap 11. WC3 client in browser authenticeert in nieuwe web socket bericht aan Webbridge A en gebruikt een nieuwe JWT.

Verifiëren

Hieronder staan de voorbeeldlogberichten waarin de gastwebdeelnemer wordt overgeplaatst van ruimte 1 (webapp.com) naar ruimte 2 (webapp.com). Om de stroom te vereenvoudigen blijft de stap naar verschillende ruimte op dezelfde aanroep-brug cbcms2 (de cluster is geladen).

Eerst begint de bewegingsstroom met API POST /gesprekken/<call id>/deelnemers.

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

Verplaats de deelnemer aan een andere vraag, creëer eerst een nieuwe gastrekening (gast2316075499).

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"

Verwijdert de oude gast van de gebruiker, 921953266 en verwijder de vorige oproep, vraag 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"

Stel mediasessie voor de nieuwe oproep met succes in, kies 20.

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

Wanneer de web app een verhuisaanvraag ontvangt, sluit deze de huidige oproep af en start deze dan opnieuw om mee te doen met de nieuwe JWT. Na de beweging ziet de deelnemer het bericht U bent verplaatst naar een nieuwe oproep in de rechterbenedenhoek, wat aangeeft dat de oproep nu in een nieuwe vergadering plaatsvindt, zoals in de volgende afbeelding wordt weergegeven. De tekst na het bericht Nu in bericht, is de ruimtenaam in dit geval Space 2.

Sommige lokale web-app vergaderstatus, zoals muziek en lay-out, worden overgedragen van de vorige oproep. Bijvoorbeeld, als deelnemer lokaal mutes dan het in de nieuwe vraag gemuteerd blijft.

De volgende functies worden niet naar de nieuwe oproep overgebracht:

• Presentatie - Als deelnemer wordt verplaatst, wordt de actieve presentatie ingetrokken. In de nieuwe vergadering na de stap deelt de deelnemer niet.
• Chatberichten - Eerdere chatberichten worden uit de chat verwijderd en worden niet overgebracht naar de nieuwe vergadering.

Problemen oplossen

Eenheid: Web app participant wordt niet verplaatst.

Het kan veel betekenen:

1. Er is niets gebeurd. Het gesprek is nog verbonden met het eerste gesprek.
2. Gestopt maar niet opnieuw aangesloten. De oproep is gevallen maar heeft geen verbinding met de tweede oproep.
3. Connect met de verkeerde vergadering.

Voor scenario a. Er is niets gebeurd:

• Zorg ervoor dat de call bridge het verzoek om van CMM te verplaatsen ontvangt. Zie de CMS logberichten voor specifiek sleutelwoord zoals bewegende deelnemer handeling. Als CMS geen API van CMM ontvangt, moet u eerst de fundamentele probleemoplossing tussen CMM en CMS omvatten toegelaten API-overtrekken aan beide zijden, DNS-controles (Domain Name Service) en een connectiviteit-controle.
• Zie of de canMove parameter in / deelnemers/<participant id> of /callLegs/<callBeen id> is ingesteld op True.

Voor scenario b. gevallen maar niet opnieuw aansluiten:

• Zorg ervoor dat de verbroken verbinding te wijten is aan een beweging, d.w.z., zoek naar bewegende deelnemer in het logbestand.
• In CMS-logboeken, zoek dan naar fouten/blokkades op de callbridge die het proces van het creëren van de deelnemer kunnen verhinderen.
• Heeft de deelnemer toestemming om zich aan te sluiten bij de nieuwe cospace?
• Is er een fout met JWT?
• Probeer je handmatig bij de vergadering aan te sluiten.

Voor scenario c. Sluit aan op de verkeerde vergadering:

In het archiefbestand HAR (Hyper Text Transport Protocol) van het Hyper-Text Transport Protocol (HTTP), kijk naar het web socket van de eerste oproep, de gegevens van de toegangsmethode voor de POST/api/call/sessie/Move toont de numerieke ID die wordt gebruikt om verbinding te maken met de nieuwe oproep. Zorg ervoor dat deze numerieke ID degene is die de bedoelde vergadering is.