Introduzione
Questo documento descrive la possibilità di spostare partecipanti da una riunione a un'altra da Cisco Meeting Management (CMM). L'amministratore CMM può spostare i partecipanti dell'app Web tra riunioni dello stesso bridge chiamate o di bridge chiamate diversi.
Prerequisiti
Requisiti
Cisco raccomanda la conoscenza dei seguenti argomenti:
- Conoscenze base di Cisco Meeting Server (CMS).
- CMM - Conoscenze di base.
- Conoscenze di base dell'app Web CMS.
Componenti usati
Le informazioni fornite in questo documento si basano sulle seguenti versioni software e hardware:
- CMS versione 3.2.1
- CMM versione 3.2.
- CMS web app versione 3.2.1
- Browser web chrome 91.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Configurazione
Premesse
La possibilità di spostare i partecipanti da una riunione a un'altra da CMM è descritta originariamente in CMS 2.6, ma con alcune restrizioni, ovvero Meeting App, app Web e Skype for Business (SfB) i partecipanti non possono essere spostati. A partire da CMS 3.2, l'amministratore di CMM può spostare i partecipanti all'app Web tra riunioni dello stesso bridge chiamate o di bridge chiamate diversi.
Nota: Questa funzionalità non consente ai partecipanti all'app Web di richiamare uno spostamento di altri partecipanti. In precedenza, se si tenta di spostare i partecipanti all'app Web, CMM impedirebbe l'operazione con un avviso. Tale restrizione viene rilevata automaticamente da CMM se la riunione è ospitata in CMS 3.2 e può essere spostata.
Esempio di rete
Configurazioni
Passaggio 1. CMM esegue una chiamata API (Application Programing Interface) a Callbridge B con il metodo POST /calling/<call_X_id>/Participants/ con "moveParticipant"=Participant_A_guid.
Passaggio 2. Callbridge B invia le richieste di spostamento dei partecipanti a Callbridge A.
Passaggio 3. Callbridge A risponde con la richiesta di spostamento nuovamente a Callbridge B.
Passaggio 4. Callbridge B esegue il bilanciamento del carico e decide di assegnare un nuovo partecipante a Callbridge C.
Passaggio 5. Callbridge B invia una richiesta a Callbridge C per creare una nuova istanza di partecipante e un nuovo partecipante. Per gli ospiti, viene creato un nuovo ID ospite. La nuova istanza partecipante ha un nuovo JASON Web Tokens (JWT).
Passaggio 6. Callbridge C invia il messaggio di spostamento del socket Web dell'API tramite Call Bridge a Web Bridge (C2W) a Webbridge A.
Passaggio 7. Webbridge A invia il messaggio di spostamento del socket Web al client Webbridge (WC3) nel browser.
Passaggio 8. WC3 nel browser invia un messaggio di fine socket Web a Webbridge A.
Passaggio 9. Webbridge A inoltra il messaggio di fine sessione a Callbridge A.
Passaggio 10. Callbridge A elimina l'istanza del partecipante e la vecchia JWT.
Passaggio 11. Il client WC3 nel browser esegue l'autenticazione nel nuovo messaggio socket Web a Webbridge A e utilizza un nuovo JWT.
Verifica
Di seguito sono riportati alcuni messaggi di log di esempio in cui il partecipante Web guest viene spostato dallo spazio Space 1 (webapp.com) allo spazio Space 2 (webapp.com). Per semplificare il flusso, lo spostamento in uno spazio diverso rimane sullo stesso call bridge cbcms2 (il cluster è con carico bilanciato).
In primo luogo, il flusso di spostamento inizia con POST /chiamate/<id chiamata>/partecipanti API.
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
Sposta il partecipante in un'altra chiamata, crea prima un nuovo account guest (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"
Eliminare il vecchio utente guest921953266 e interrompere la chiamata precedente, chiamare 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"
Sessione multimediale configurata per la nuova chiamata, chiamata 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
Quando l'app Web riceve una richiesta di spostamento, disconnette la chiamata corrente e quindi avvia di nuovo il processo di unione con il nuovo JWT. Dopo lo spostamento, il partecipante visualizza il messaggio You have been move to a new call nell'angolo in basso a destra che indica che la chiamata è ora in una nuova riunione, come mostrato nell'immagine seguente. Il testo che segue il messaggio Now in è il nome dello spazio in questo caso Space 2.
Alcuni stati di riunione dell'app Web locale, ad esempio disattiva e layout, sono riportati dalla chiamata precedente. Ad esempio, se il partecipante esegue l'audio localmente, rimane disattivato nella nuova chiamata.
Le funzionalità successive non verranno trasferite al nuovo invito:
- Presentazione: quando un partecipante viene spostato, la presentazione attiva viene eliminata. Nella nuova riunione successiva al trasferimento, il partecipante non condivide.
- Messaggi di chat - I messaggi di chat precedenti vengono rimossi dalla chat e non vengono trasferiti alla nuova riunione.
Risoluzione dei problemi
Problema: Il partecipante all'app Web non viene spostato.
Potrebbe significare molte cose:
- Non è successo niente. La chiamata è ancora connessa alla prima chiamata.
- Interrotto ma non riconnesso. La chiamata viene interrotta ma non si connette alla seconda chiamata.
- Connettersi alla riunione sbagliata.
Per lo scenario a. Non è successo nulla:
- Assicurarsi che il bridge di chiamate riceva la richiesta di spostamento da CMM. Vedere i messaggi di log del CMS per una parola chiave specifica come operazione di spostamento dei partecipanti. Se CMS non riceve l'API da CMM, eseguire la risoluzione dei problemi di base tra CMM e CMS includendo la traccia dell'API abilitata su entrambi i lati, i controlli DNS (Domain Name Service) e il controllo della connettività.
- Verificare se il parametro canMove in /Participant/<Participid> o /callLegs/<callLeg id> è impostato su true.
Per lo scenario b. Interrotto ma non riconnesso:
- Verificare che la disconnessione sia dovuta a uno spostamento, ovvero cercare l'operazione di spostamento dei partecipanti nel registro.
- Nei registri CMS, cercare errori/blocchi delle risorse sul bridge di chiamate che potrebbero impedire lo svolgimento del processo di creazione dei partecipanti.
- Il partecipante è autorizzato a unirsi al nuovo cospazio?
- C'è un errore con JWT?
- Provare a partecipare manualmente alla riunione.
Per lo scenario c. Connettersi alla riunione sbagliata:
Nel file HAR (Hyper Text Transport Protocol), osservare il socket Web della prima chiamata. I dati del metodo di accesso per POST /api/call/session/move mostrano l'ID numerico utilizzato per connettersi alla nuova chiamata. Verificare che questo ID numerico sia quello della riunione desiderata.