Cómo mover usuarios de aplicaciones web de espacios/reuniones en CMS

Introducción

Este documento describe la capacidad de trasladar participantes de una reunión a otra mediante Cisco Meeting Management (CMM). El administrador de CMM puede mover a los participantes de la aplicación web entre reuniones de uno o varios puentes de llamadas.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Conocimiento básico de Cisco Meeting Server (CMS).
• Conocimiento básico de CMM.
• Conocimiento básico de la aplicación web CMS.

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

• Versión 3.2 de CMS.
• CMM Versión 3.2.
• Aplicación web CMS versión 3.2.
• Navegador web cromado 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 tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Configurar

Antecedentes

La capacidad de trasladar a los participantes de una reunión a otra de CMM aparece originalmente en CMS 2.6, pero con algunas restricciones, es decir, aplicaciones para reuniones, aplicaciones web y participantes de Skype for Business (SfB), no se pueden mover. A partir de CMS 3.2, el administrador de CMM puede mover a los participantes de la aplicación web entre reuniones de los mismos puentes de llamadas o de diferentes.

Nota: Esta función no significa que los participantes de la aplicación web puedan invocar un movimiento de otros participantes. Anteriormente, cuando se intentaba mover a los participantes de la aplicación web, CMM lo evitaba con una alerta. CMM detecta automáticamente esta restricción si la reunión se aloja en CMS 3.2 y se le permite moverse.

Diagrama de la red

Configuraciones

Paso 1. CMM realiza una llamada de la interfaz de programación de aplicaciones (API) a Callbridge B con el método POST/calls/<call_X_id>/participantes/ con "movantParticipant"=participante_A_guid.

Paso 2. Callbridge B envía solicitudes de movimiento de participantes a Callbridge A.

Paso 3. Callbridge A responde con la solicitud de traslado de regreso a Callbridge B.

Paso 4. Callbridge B hace el balance de carga y decide colocar un nuevo participante en Callbridge C.

Paso 5. Callbridge B envía una solicitud a Callbridge C para crear una nueva instancia de participante y un nuevo participante. Para el invitado, se crea una nueva ID de invitado. La nueva instancia del participante tiene un nuevo JASON Web Tokens (JWT).

Paso 6. Callbridge C envía el mensaje de traslado de socket web API a través de Call Bridge a Web Bridge (C2W) a Webbridge A.

Paso 7. Webbridge A envía el mensaje mover el socket web al cliente Webbridge (WC3) en el navegador.

Paso 8. WC3 en el navegador envía el mensaje de socket web final a Webbridge A.

Paso 9. Webbridge A reenvía el mensaje de sesión final a Callbridge A.

Paso 10. Callbridge A destruye la instancia del participante y el antiguo JWT.

Paso 11. El cliente WC3 en el navegador se autentica en el nuevo mensaje de socket web a Webbridge A y utiliza un nuevo JWT.

Verificación

A continuación se muestran los ejemplos de mensajes de registro en los que se mueve el participante de la Web invitada desde el espacio Space 1 (webapp.com) al espacio 2 (webapp.com). Para simplificar el flujo, el movimiento a diferentes espacios permanece en el mismo cbcms2 del puente de llamadas (el clúster está equilibrado de carga).

En primer lugar, el flujo de movimiento comienza con API POST /calls/<call id>/entries.

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

Mover participante a otra llamada, primero crea una nueva cuenta de invitado (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"

Elimine el usuario antiguo guest921953266 y elimine la llamada anterior, llame al 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"

Configuración correcta de la sesión multimedia para la nueva llamada, llamada 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

Cuando la aplicación web recibe una solicitud de movimiento, desconecta la llamada actual y, a continuación, inicia de nuevo el proceso de unión con el nuevo JWT. Después del movimiento, el participante ve el mensaje Ha sido transferido a una nueva llamada en la esquina inferior derecha, lo que indica que la llamada está ahora en una nueva reunión, como se muestra en la siguiente imagen. El texto después del mensaje Now in, es el nombre de espacio en este caso Space 2.

Algunos estados de reunión de aplicaciones web locales, como silencio y diseño, se trasladan desde la llamada anterior. Por ejemplo, si el participante se silencia localmente, permanece en silencio en la nueva llamada.

Las siguientes funciones no se trasladan a la nueva llamada:

• Presentación: cuando se mueve el participante, se elimina la presentación activa. En la nueva reunión después del traslado, el participante no comparte.
• Mensajes de conversación: los mensajes de conversación anteriores se eliminan del chat y no se transfieren a la nueva reunión.

Troubleshoot

Problema: El participante de la aplicación web no se mueve.

Podría significar muchas cosas:

1. No pasó nada. La llamada sigue conectada a la primera llamada.
2. Descartado pero no reconectado. La llamada se interrumpe pero no se conecta a la segunda llamada.
3. Conéctese a la reunión incorrecta.

Para el escenario a. No pasó nada:

• Asegúrese de que el puente de llamada recibe la solicitud para moverse de CMM. Vea los Mensajes de Registro de CMS para una palabra clave específica como mover la operación del participante. Si CMS no recibe la API de CMM, realice la resolución de problemas básica entre CMM y CMS, que incluya el seguimiento de API habilitado en ambos lados, las comprobaciones del servicio de nombres de dominio (DNS) y la comprobación de conectividad.
• Vea si el parámetro canMove en /participantes/<id de participante> o /callLegs/<id de callLeg> se establece en true.

Para el escenario b. Descartado pero no reconectado:

• Asegúrese de que la desconexión se debe a un movimiento, es decir, busque mover la operación del participante en el registro.
• En los registros de CMS, busque errores/bloqueo de recursos en el puente de llamadas que podrían impedir que se lleve a cabo el proceso de creación del participante.
• ¿Tiene el participante permiso para unirse al nuevo espacio?
• ¿Hay algún error con JWT?
• Intente unirse manualmente a la reunión.

Para el escenario c. Conéctese a la reunión incorrecta:

En el archivo HAR (del inglés Hyper Text Transport Protocol, protocolo de transporte de hipertexto), observe el socket web de la primera llamada, los datos del método de acceso para el POST /api/call/session/motion muestran el identificador numérico que se utiliza para conectarse a la nueva llamada. Asegúrese de que esta ID numérica es la que corresponde a la reunión prevista.