Comment déplacer des utilisateurs Web App à partir d'espaces/de réunions dans CMS

Introduction

Ce document décrit la possibilité de déplacer des participants d'une téléconférence à une autre par Cisco Meeting Management (CMM). L'administrateur CMM peut déplacer les participants de l'application Web entre des téléconférences de ponts d'appel identiques ou différents.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• Connaissances de base de Cisco Meeting Server (CMS).
• Connaissances de base de CMM.
• Connaissances de base de l'application Web CMS.

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• CMS Version 3.2.
• CMM Version 3.2.
• Application Web CMS Version 3.2.
• Navigateur Web chrome 91.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Configurer

Informations générales

La possibilité de déplacer des participants d'une téléconférence à une autre par CMM est à l'origine proposée dans CMS 2.6, mais avec certaines restrictions, c'est-à-dire que les participants aux applications Meeting, Web et Skype Entreprise (SfB) ne peuvent pas être déplacés. À partir de CMS 3.2, l'administrateur CMM peut déplacer les participants de l'application Web entre des téléconférences de ponts d'appel identiques ou différents.

Remarque : Cette fonctionnalité ne signifie pas que les participants à une application Web peuvent appeler un déplacement d'autres participants. Auparavant, lorsque vous tentiez de déplacer des participants à une application Web, CMM l'empêchait par une alerte. Cette restriction est automatiquement détectée par CMM si la téléconférence est hébergée sur CMS 3.2 et est autorisée à se déplacer.

Diagramme du réseau

Configurations

Étape 1. CMM effectue un appel de l'interface de programmation d'application (API) vers Callbridge B avec la méthode POST /calls/<call_X_id>/participants/ avec «moveParticipant»=participant_A_guid.

Étape 2. Callbridge B envoie des demandes de déplacement de participants à Callbridge A.

Étape 3. Callbridge A répond en envoyant la requête de déplacement à Callbridge B.

Étape 4. Callbridge B effectue l’équilibrage de charge et décide de placer un nouveau participant sur Callbridge C.

Étape 5. Callbridge B envoie une requête à Callbridge C pour créer une instance de participant et un participant. Pour l'invité, un nouvel ID d'invité est créé. La nouvelle instance de participant a un nouveau JWT (JASON Web Tokens).

Étape 6. Callbridge C envoie un message API move web socket sur Call Bridge to Web Bridge (C2W) vers Webbridge A.

Étape 7. Webbridge A envoie le message move web socket au client Webbridge (WC3) dans le navigateur.

Étape 8. WC3 dans le navigateur envoie un message de fin de connexion Web à Webbridge A.

Étape 9. Webbridge A transfère le message de fin de session à Callbridge A.

Étape 10. Callbridge A détruit l’instance de participant et l’ancien JWT.

Étape 11. Le client WC3 du navigateur authentifie un nouveau message de socket Web sur Webbridge A et utilise un nouveau JWT.

Vérifier

Vous trouverez ci-dessous des exemples de messages de journal dans lesquels le participant Web invité est déplacé de l'espace Space 1 (webapp.com) vers l'espace Space 2 (webapp.com). Pour simplifier le flux, le déplacement vers un espace différent reste sur le même pont d'appel cbcms2 (le cluster est équilibré en charge).

Tout d'abord, le flux de déplacement commence par l'API POST /calls/<call id>/participants.

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

Déplacer le participant vers un autre appel, crée d'abord un nouveau compte invité (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"

Supprimez l'ancien utilisateur guest921953266 et supprimez l'appel précédent, l'appel 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"

Une session multimédia a été correctement configurée pour le nouvel appel, l'appel 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

Lorsque l'application web reçoit une demande de déplacement, elle déconnecte l'appel en cours, puis redémarre le processus de jointure avec le nouveau JWT. Après le déplacement, le participant voit le message « Vous avez été déplacé vers un nouvel appel » dans le coin inférieur droit, ce qui indique que l'appel est maintenant dans une nouvelle téléconférence, comme illustré dans l'image suivante. Le texte après le message Maintenant dans, est le nom de l'espace dans ce cas Espace 2.

Certains états de téléconférence de l'application Web locale, tels que le mode muet et la disposition, sont reportés de l'appel précédent. Par exemple, si le participant est mis en sourdine localement, il reste en sourdine dans le nouvel appel.

Les fonctionnalités suivantes ne sont pas transférées au nouvel appel :

• Présentation - Lorsque le participant est déplacé, la présentation active est abandonnée. Dans la nouvelle téléconférence après le déplacement, le participant ne partage pas.
• Messages de discussion - Les messages de discussion précédents sont supprimés de la discussion et ne sont pas transférés vers la nouvelle réunion.

Dépannage

Problème : Le participant à l'application Web n'est pas déplacé.

Cela peut signifier beaucoup de choses :

1. Rien ne se produisit. L'appel est toujours connecté au premier appel.
2. Abandonné mais pas reconnecté. L'appel est abandonné mais ne se connecte pas au deuxième appel.
3. Se connecter à la mauvaise téléconférence.

Pour le scénario a. Rien ne s'est passé :

• Assurez-vous que le pont d'appel reçoit la demande de déplacement de CMM. Consultez les messages du journal CMS pour un mot clé spécifique comme l'opération de déplacement de participant. Si CMS ne reçoit pas d'API de CMM, effectuez un dépannage de base entre CMM et CMS en incluant une trace d'API activée des deux côtés, des vérifications DNS (Domain Name Service), une vérification de connectivité.
• Vérifiez si le paramètre canMove dans /participants/<id du participant> ou /callLegs/<id du segment d'appel> est défini sur true.

Pour le scénario b. Abandonné mais pas reconnecté :

• Assurez-vous que la déconnexion est due à un déplacement, c'est-à-dire recherchez l'opération de déplacement du participant dans le journal.
• Dans les journaux CMS, recherchez les erreurs/blocages de ressources sur le pont d'appel qui pourraient empêcher le processus de création du participant de se produire.
• Le participant a-t-il l'autorisation de rejoindre le nouvel espace virtuel ?
• Y a-t-il une erreur avec JWT ?
• Essayez de vous connecter manuellement à la téléconférence.

Pour le scénario c. Connectez-vous à la mauvaise téléconférence :

Dans le fichier HAR (Hyper Text Transport Protocol) Archive Format (HAR), examinez le socket Web du premier appel. Les données de la méthode d'accès pour le POST /api/call/session/move indiquent l'ID numérique utilisé pour se connecter au nouvel appel. Assurez-vous que cet ID numérique est celui de la téléconférence prévue.