Comment déplacer les utilisateurs d'application Web des espaces/téléconférences dans CMS

Introduction

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

Conditions préalables

Conditions requises

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.

Components Used

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.

Configuration

Informations générales

La possibilité de déplacer des participants d'une réunion à une autre par CMM est initialement proposée dans CMS 2.6, mais avec certaines restrictions, c'est-à-dire qu'il est impossible de déplacer les participants à l'application Meeting, à l'application Web et à Skype Entreprise (SfB). À partir de CMS 3.2, l'administrateur CMM peut déplacer des participants d'application Web entre des réunions de ponts d'appel identiques ou différents.

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

Diagramme du réseau

Configurations

Étape 1. CMM passe l'appel de l'interface de programmation d'application (API) à Callbridge B avec la méthode POST /appels/<call_X_id>/participants/ avec “ déplacementParticipant ”=participant_A_guid.

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

Étape 3. Callbridge A répond avec la demande de déplacement vers Callbridge B.

Étape 4. Callbridge B équilibre la charge et décide de placer le nouveau participant à Callbridge C.

Étape 5. Callbridge B envoie une demande à 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 JASON Web Tokens (JWT).

Étape 6. Callbridge C envoie un message de socket Web de transfert API via Call Bridge vers Web Bridge (C2W) vers Webbridge A.

Étape 7. Webbridge A envoie le message de transfert de socket Web au client Webbridge (WC3) dans le navigateur.

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

Étape 9. Webbridge A transmet le message de fin de session à Callbridge A.

Étape 10. Callbridge A détruit l'instance du participant et l'ancien JWT.

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

Vérification

Ci-dessous se trouvent les exemples de messages de journal dans lesquels le participant invité est déplacé de l'espace 1 (webapp.com) vers l'espace 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 /appels/<id d'appel>/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 d'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, appelez le 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"

Configuration de la session multimédia pour le nouvel appel, 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 indiqué dans l'image suivante. Le texte qui suit 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 mise en page, sont reportés de l'appel précédent. Par exemple, si le participant est mis en sourdine localement, il reste mis en sourdine dans le nouvel appel.

Les fonctions suivantes ne sont pas reportées au nouvel appel :

• Présentation - Lorsque le participant est déplacé, la présentation active est supprimé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 téléconférence.

Dépannage

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

Cela peut signifier beaucoup de choses :

1. Rien ne s'est passé. L'appel est toujours connecté au premier appel.
2. Abandonné mais non reconnecté. L'appel est abandonné mais ne se connecte pas au deuxième appel.
3. Connectez-vous à la téléconférence incorrecte.

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

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

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

• Assurez-vous que la déconnexion est due à un déplacement, c'est-à-dire, recherchez l'opération du participant au déplacement 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 des participants.
• Le participant a-t-il l'autorisation de rejoindre le nouvel espace cospatial ?
• Y a-t-il une erreur avec JWT ?
• Essayez de vous connecter manuellement à la téléconférence.

Pour le scénario c. Se connecter à la téléconférence incorrecte :

Dans le fichier HAR (Hyper Text Transport Protocol), regardez 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 qui correspond à la téléconférence prévue.