Sommario

Introduzione

Prerequisiti

Requisiti

Componenti usati

Configurazione

Premesse

Esempio di rete

Configurazioni

Verifica

Risoluzione dei problemi

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:

1. Non è successo niente. La chiamata è ancora connessa alla prima chiamata.

2. Interrotto ma non riconnesso. La chiamata viene interrotta ma non si connette alla seconda chiamata.

3. 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.