Introduction
Este documento descreve a capacidade de mover participantes de uma reunião para outra pelo Cisco Meeting Management (CMM). O administrador do CMM pode mover participantes de aplicativos da Web entre reuniões do mesmo ou de diferentes pontes de chamadas.
Prerequisites
Requirements
A Cisco recomenda que você tenha conhecimento destes tópicos:
- Conhecimento básico do Cisco Meeting Server (CMS).
- Conhecimento Básico do CMM.
- Conhecimento Básico do aplicativo da Web CMS.
Componentes Utilizados
As informações neste documento são baseadas nestas versões de software e hardware:
- CMS versão 3.2.
- CMM versão 3.2.
- CMS Web app Versão 3.2.
- Navegador da Web cromo 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. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando.
Configurar
Informações de Apoio
A capacidade de mover participantes de uma reunião para outra pelo CMM é originalmente apresentada no CMS 2.6, mas com algumas restrições, ou seja, o Meeting App, o aplicativo da Web e os participantes do Skype for Business (SfB) não podem ser movidos. Comece com o CMS 3.2, o administrador do CMM pode mover participantes de aplicativos da Web entre reuniões de pontes de chamada iguais ou diferentes.
Note: Este recurso não significa que os participantes do aplicativo da Web possam invocar uma movimentação de outros participantes. Anteriormente, ao tentar mover participantes de aplicativos da Web, o CMM evitaria isso com um alerta. Essa restrição é detectada automaticamente pelo CMM quando a reunião é hospedada no CMS 3.2 e pode ser movida.
Diagrama de Rede
Configurações
Etapa 1. O CMM faz a chamada da API (Application Programing Interface, Interface de Programação de Aplicações) para a Callbridge B com o método POST /calls/<call_X_id>/participantes/ com "moveParticipant"=participante_A_guid.
Etapa 2. O Callbridge B envia solicitações de movimentação de participantes ao Callbridge A.
Etapa 3. A Callbridge A responde com a solicitação de movimentação de volta para Callbridge B.
Etapa 4. O Callbridge B faz o balanceamento de carga e decide colocar o novo participante no Callbridge C.
Etapa 5. O Callbridge B envia uma solicitação ao Callbridge C para criar uma nova instância de participante e um novo participante. Para convidado, uma nova ID de convidado é criada. A nova instância de participante tem um novo JASON Web Tokens (JWT).
Etapa 6. O Callbridge C envia mensagem de transferência de API de soquete da Web sobre Call Bridge para Web Bridge (C2W) para Webbridge A.
Passo 7. O Webbridge A envia a mensagem move o soquete da Web para o cliente Webbridge (WC3) no navegador.
Etapa 8. WC3 no navegador envia mensagem de soquete da Web final para a Webbridge A.
Etapa 9. O Webbridge A encaminha a mensagem de fim de sessão para o Callbridge A.
Etapa 10. O Callbridge A destrói a instância do participante e o JWT antigo.
Etapa 11. O cliente WC3 no navegador autentica na nova mensagem de soquete da Web para a Webbridge A e usa um novo JWT.
Verificar
Abaixo estão exemplos de mensagens de log em que o participante da web convidado é movido do espaço 1 (webapp.com) para o espaço 2 (webapp.com). Para simplificar o fluxo, a mudança para um espaço diferente permanece no mesmo call bridge cbcms2 (o cluster tem balanceamento de carga).
Primeiro, o fluxo de movimentação começa com API POST /calls/<call id>/participantes.
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 para outra chamada, primeiro cria uma nova conta de convidado (convidado2316075499).
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"
Exclua o antigo convidado de usuário 921953266 e retire a chamada anterior, ligue para 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"
Sessão de mídia configurada com êxito para a nova chamada, ligue para 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 o aplicativo da Web recebe uma solicitação de movimentação, ele desconecta a chamada atual e, em seguida, inicia o processo de união novamente com o novo JWT. Após a movimentação, o participante vê a mensagem Você foi movido para uma nova chamada no canto inferior direito, indicando que a chamada está agora em uma nova reunião, como mostrado na imagem seguinte. O texto após a mensagem Agora em, é o nome do espaço neste caso Espaço 2.
Alguns estados da reunião do aplicativo Web local, como silenciar e layout, são transferidos da chamada anterior. Por exemplo, se o participante silenciar localmente, ele permanecerá silenciado na nova chamada.
Os recursos seguintes não são transferidos para a nova chamada:
- Apresentação - Quando o participante é movido, a apresentação ativa é removida. Na nova reunião após a movimentação, o participante não compartilha.
- Mensagens de bate-papo - As mensagens de bate-papo anteriores são removidas do bate-papo e não são transferidas para a nova reunião.
Troubleshoot
Problema: O participante do aplicativo da Web não é movido.
Pode significar muitas coisas:
- Nada aconteceu. A chamada ainda está conectada à primeira chamada.
- Desconectado, mas não reconectado. A chamada é perdida, mas não se conecta à segunda chamada.
- Conecte-se à reunião errada.
Para o cenário a. Nada aconteceu:
- Certifique-se de que a ponte de chamada receba a solicitação para se mover do CMM. Consulte Mensagens de log do CMS para obter uma palavra-chave específica como mover a operação do participante. Se o CMS não receber a API do CMM, faça a solução básica de problemas entre o CMM e o CMS inclui rastreamento de API habilitado em ambos os lados, verificações do Domain Name Service (DNS) e verificação de conectividade.
- Veja se o parâmetro canMove em /participantes/<id do participante> ou /callLegs/<callLeg id> está definido como verdadeiro.
Para o cenário b. Desconectado, mas não reconectado:
- Certifique-se de que a desconexão se deve a uma movimentação, ou seja, procure a operação mover o participante no registro.
- Nos registros do CMS, procure erros/bloqueio de recursos na ponte de chamada que poderiam impedir que o processo de criação do participante ocorresse.
- O participante tem permissão para ingressar no novo espaço?
- Há um erro com JWT?
- Tente ingressar manualmente na reunião.
Para o cenário c. Conecte-se à reunião errada:
No arquivo HAR (Hyper Text Transport Protocol), examine o soquete da Web da primeira chamada, os dados do método de acesso para POST /api/call/session/move mostram a ID numérica usada para se conectar à nova chamada. Certifique-se de que essa ID numérica seja a reunião pretendida.