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

Introducción

En este documento se describe la capacidad de Cisco Meeting Management (CMM) de trasladar participantes de una reunión a otra. El administrador de CMM puede mover participantes de aplicaciones web entre reuniones de puentes de llamadas iguales o diferentes.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Conocimientos básicos de Cisco Meeting Server (CMS).
• Conocimientos básicos 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.

• CMS versión 3.2.
• CMM Versión 3.2.
• Aplicación web CMS versión 3.2.
• Navegador web chrome 91.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Configurar

Antecedentes

La capacidad de CMM de trasladar participantes de una reunión a otra se incluía originalmente en CMS 2.6, pero con algunas restricciones, es decir, los participantes de Meeting App, Web App y Skype Empresarial (SfB) no se pueden mover. A partir de CMS 3.2, el administrador de CMM puede mover participantes de aplicaciones web entre reuniones de puentes de llamadas iguales o 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 participantes de aplicaciones web, CMM lo evitaba con una alerta. CMM detecta automáticamente esa 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>/participate/ con "moveParticipant"=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 movimiento de vuelta a Callbridge B.

Paso 4. Callbridge B hace 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 y un nuevo participante. Para invitado, se crea un nuevo ID de invitado. La nueva instancia de participante tiene un nuevo JASON Web Tokens (JWT).

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

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

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

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

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

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

Verificación

A continuación se muestran los mensajes de registro de ejemplo en los que el participante web invitado se mueve desde el espacio Space 1 (webapp.com) al espacio Space 2 (webapp.com). Para simplificar el flujo, el traslado a un espacio diferente permanece en el mismo call bridge cbcms2 (el clúster tiene la carga equilibrada).

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

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 antiguo usuario guest921953266 y desconecte la llamada anterior, llamada 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"

Se ha configurado correctamente 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, vuelve a iniciar el proceso de unión con el nuevo JWT. Después del traslado, el participante verá el mensaje Usted ha sido trasladado a una nueva llamada en la esquina inferior derecha, que indica que la llamada se encuentra ahora en una nueva reunión, como se muestra en la siguiente imagen. El texto después del mensaje Now in, es el nombre del espacio en este caso Space 2.

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

Las siguientes funciones no se trasladan a la nueva llamada:

• Presentación: cuando se mueve un participante, la presentación activa se suprime. En la nueva reunión después del traslado, el participante no comparte información.
• 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: Los participantes de la aplicación web no se mueven.

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

Para el escenario a. No pasó nada:

• Asegúrese de que el puente de llamadas reciba la solicitud de movimiento desde CMM. Consulte los mensajes de registro de CMS para obtener información sobre palabras clave específicas como operación de movimiento de participantes. Si CMS no recibe API de CMM, realice la resolución de problemas básica entre CMM y CMS e 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 /participate/<id de participante> o /callLegs/<id de callLeg> está configurado 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 la operación de movimiento del participante en el registro.
• En los registros de CMS, busque errores/bloqueos de recursos en el puente de llamadas que podrían impedir que se lleve a cabo el proceso de creación de participantes.
• ¿Tiene el participante permiso para unirse al nuevo cospace?
• ¿Hay algún error con JWT?
• Intente unirse manualmente a la reunión.

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

En el archivo de formato de archivo (HAR) del protocolo de transferencia de hipertexto (HTTP), observe el socket web de la primera llamada; los datos del método de acceso para POST /api/call/session/move 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.