ProHoster > Blog > administração > Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Nesta edição mostrarei e explicarei algumas das complexidades da configuração de um servidor CMS no modo cluster de failover.
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

ТеорияEm geral, existem três tipos de implantação de servidor CMS:

  • Único Combinado(Único combinado), ou seja, este é um servidor no qual todos os serviços necessários estão em execução. Na maioria dos casos, este tipo de implantação é adequado apenas para acesso de clientes internos e em ambientes menores onde as limitações de escalabilidade e redundância de um único servidor não são um problema crítico, ou em situações onde o CMS executa apenas determinadas funções, como ad hoc conferências sobre Cisco UCM.

    Esquema aproximado de trabalho:
    Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

  • Divisão Única(Single Split) estende o tipo de implantação anterior adicionando um servidor separado para acesso externo. Em implantações legadas, isso significava implantar um servidor CMS em um segmento de rede desmilitarizado (DMZ), onde clientes externos pudessem acessá-lo, e um servidor CMS no núcleo da rede, onde clientes internos pudessem acessar o CMS. Este modelo de implantação específico está agora sendo substituído pelo chamado tipo Borda única, que consiste em servidores Via Expressa Cisco, que tem ou terá muitos dos mesmos recursos de desvio de firewall para que os clientes não precisem adicionar um servidor CMS de borda dedicado.

    Esquema aproximado de trabalho:
    Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

  • Escalável e Resiliente(Escalável e tolerante a falhas) Este tipo inclui redundância para cada componente, permitindo que o sistema cresça com suas necessidades até sua capacidade máxima, ao mesmo tempo que fornece redundância em caso de falha. Ele também usa o conceito Single Edge para fornecer acesso externo seguro. Este é o tipo que veremos neste episódio. Se entendermos como implantar esse tipo de cluster, não apenas entenderemos outros tipos de implantações, mas também seremos capazes de entender como criar clusters de servidores CMS para acomodar o crescimento potencial da demanda.

Antes de prosseguir para a implantação, você precisa entender algumas coisas básicas, nomeadamente

Principais componentes do software CMS:

  • banco de dados: Permite combinar algumas configurações, como plano de discagem, espaços de usuários e os próprios usuários. Suporta clustering apenas para alta disponibilidade (mestre único).
  • Ponte de chamada: serviço de áudio e videoconferência que oferece controle total sobre o gerenciamento e processamento de chamadas e processos multimídia. Suporta clustering para alta disponibilidade e escalabilidade.
  • servidor XMPP: responsável pelo registro e autenticação de clientes usando o Cisco Meeting Application e/ou WebRTC(comunicação em tempo real ou simplesmente no navegador), bem como sinalização intercomponente. Pode ser agrupado somente para alta disponibilidade.
  • Ponte da Web: fornece acesso do cliente ao WebRTC.
  • Balanceador de carga: fornece um único ponto de conexão para Cisco Meeting Apps no modo Single Split. Escuta a interface externa e a porta para conexões de entrada. Da mesma forma, o balanceador de carga aceita conexões TLS de entrada do servidor XMPP, por meio das quais pode alternar conexões TCP de clientes externos.
    Em nosso cenário não será necessário.
  • Servidor TURN: Fornece tecnologia de bypass de Firewall que permite
    coloque nosso CMS atrás de um Firewall ou NAT para conectar clientes externos usando o Cisco Meeting App ou dispositivos SIP. Em nosso cenário não será necessário.
  • Admin da Web: Interface administrativa e acesso API, inclusive para conferências especiais do Unified CM.

Modos de configuração

Ao contrário da maioria dos outros produtos Cisco, o Cisco Meeting Server oferece suporte a três métodos de configuração para acomodar qualquer tipo de implantação.

  • Linha de comando (CLI): interface de linha de comando conhecida como MMP para configuração inicial e tarefas de certificado.
  • Administrador da Web: principalmente para configurações relacionadas ao CallBridge, especialmente ao configurar um único servidor sem cluster.
  • API REST: usado para as tarefas de configuração mais complexas e tarefas relacionadas ao banco de dados clusterizado.

Além do acima, o protocolo é usado SFTP para transferir arquivos (geralmente licenças, certificados ou logs) de e para o servidor CMS.

Nos guias de implantação da Cisco está escrito em branco e inglês que o cluster precisa ser implantado pelo menos três servidores (nós) no contexto de bancos de dados. Porque Somente com um número ímpar de nós o mecanismo de seleção de um novo Database Master funcionará e, em geral, o Database Master tem conexão com a maior parte do banco de dados do servidor CMS.

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

E como mostra a prática, dois servidores (nós) não são suficientes. O mecanismo de seleção funciona quando o Master é reinicializado, o servidor Slave se torna Master somente após o servidor reinicializado ser acionado. No entanto, se em um cluster de dois servidores o servidor Master sair repentinamente, o servidor Slave não se tornará o Master, e se o Slave sair, o servidor Master restante se tornará o Slave.

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Mas no contexto do XMPP seria realmente necessário montar um cluster de três servidores, pois se, por exemplo, você desabilitar o serviço XMPP em um dos servidores em que o XMMP está no status Líder, no servidor restante o XMPP permanecerá no status Seguidor e as conexões CallBridge com o XMPP cairão, porque CallBridge se conecta exclusivamente ao XMPP com status de Líder. E isso é fundamental, porque... nem uma única chamada será completada.

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Também nos mesmos guias de implantação é demonstrado um cluster com um servidor XMPP.

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

E levando em consideração o exposto, fica claro o porquê: funciona porque está em modo failover.

No nosso caso, o servidor XMPP estará presente em todos os três nós.

Presume-se que todos os nossos três servidores estejam ativos.

Registros DNS

Antes de começar a configurar servidores, você precisa criar registros DNS А и SRV tipos:

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Observe que em nossos registros DNS existem dois domínios exemplo.com e conf.exemplo.com. Exemplo.com é um domínio que todos os assinantes do Cisco Unified Communication Manager podem usar para seus URIs, que provavelmente está presente em sua infraestrutura ou provavelmente estará presente. Ou exemplo.com corresponde ao mesmo domínio que os usuários usam para seus endereços de e-mail. Ou o cliente Jabber no seu laptop pode ter um URI [email protegido]. Domínio conf.example.com é o domínio que será configurado para usuários do Cisco Meeting Server. O domínio do Cisco Meeting Server será conf.example.com, portanto, para o mesmo usuário do Jabber, o URI user@ precisaria ser usado para fazer login no Cisco Meeting Serverconf.exemplo.com.

Configuração básica

Todas as configurações descritas abaixo são mostradas em um servidor, mas precisam ser feitas em cada servidor do cluster.

QoS

Como o CMS gera em tempo real tráfego sensível a atrasos e perda de pacotes, na maioria dos casos é recomendado configurar qualidade de serviço (QoS). Para conseguir isso, o CMS suporta a marcação de pacotes com os Códigos de Serviços Diferenciados (DSCPs) que ele gera. Embora a priorização de tráfego baseada em DSCP dependa de como o tráfego é processado pelos componentes de rede da sua infraestrutura, em nosso caso configuraremos nosso CMS com priorização DSCP típica baseada nas melhores práticas de QoS.

Em cada servidor iremos inserir estes comandos

dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1A

Assim, todo o tráfego de vídeo foi marcado como AF41 (DSCP 0x22), todo o tráfego de voz foi marcado como EF (DSCP 0x2E), outros tipos de tráfego de baixa latência como SIP e XMPP usam AF31 (DSCP 0x1A).

Verificamos:
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

NTP

O Network Time Protocol (NTP) é importante não apenas para fornecer carimbos de data e hora precisos de chamadas e conferências, mas também para verificar certificados.

Adicione servidores NTP à sua infraestrutura com um comando como

ntp server add <server>

No nosso caso, existem dois desses servidores, portanto haverá duas equipes.
Verificamos:
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência
E defina o fuso horário do nosso servidor
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

DNS

Adicionamos servidores DNS ao CMS com um comando como:

dns add forwardzone <domain-name> <server ip>

No nosso caso, existem dois desses servidores, portanto haverá duas equipes.
Verificamos:
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Configuração da interface de rede

Configuramos a interface com um comando como:

ipv4 <interface> add <address>/<prefix length> <gateway>

Verificamos:
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Nome do servidor (nome do host)

Definimos o nome do servidor com um comando como:

hostname <name>

E reiniciamos.
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Isso completa a configuração básica.

Certificados

ТеорияO Cisco Meeting Server requer comunicação criptografada entre vários componentes e, como resultado, certificados X.509 são necessários para todas as implantações de CMS. Eles ajudam a garantir que os serviços/servidor sejam confiáveis ​​por outros servidores/serviços.

Cada serviço requer um certificado, mas a criação de certificados separados para cada serviço pode causar confusão e complexidade desnecessária. Felizmente, podemos gerar um par de chaves pública-privada de um certificado e reutilizá-lo em vários serviços. No nosso caso, o mesmo certificado será utilizado para Call Bridge, XMPP Server, Web Bridge e Web Admin. Portanto, você precisa criar um par de chaves de certificado públicas e privadas para cada servidor no cluster.

O cluster de banco de dados, entretanto, possui alguns requisitos especiais de certificado e, portanto, requer certificados próprios, diferentes daqueles dos outros serviços. O CMS usa um certificado de servidor, que é semelhante aos certificados usados ​​por outros servidores, mas também há um certificado de cliente usado para conexões de banco de dados. Os certificados de banco de dados são usados ​​para autenticação e criptografia. Em vez de fornecer um nome de usuário e senha para o cliente se conectar ao banco de dados, ele apresenta um certificado de cliente confiável para o servidor. Cada servidor no cluster de banco de dados usará o mesmo par de chaves pública e privada. Isso permite que todos os servidores do cluster criptografem dados de forma que eles só possam ser descriptografados por outros servidores que também compartilhem o mesmo par de chaves.

Para que a redundância funcione, os clusters de banco de dados devem consistir em no mínimo 3 servidores, mas não mais que 5, com um tempo máximo de ida e volta de 200 ms entre quaisquer membros do cluster. Esse limite é mais restritivo do que para clustering de Call Bridge, por isso é frequentemente o fator limitante em implantações distribuídas geograficamente.

A função de banco de dados de um CMS possui vários requisitos exclusivos. Ao contrário de outras funções, requer um certificado de cliente e servidor, onde o certificado do cliente possui um campo CN específico que é apresentado ao servidor.

O CMS usa um banco de dados postgres com um mestre e várias réplicas completamente idênticas. Existe apenas um banco de dados primário por vez (o “servidor de banco de dados”). Os membros restantes do cluster são réplicas ou “clientes de banco de dados”.

Um cluster de banco de dados requer um certificado de servidor dedicado e um certificado de cliente. Eles devem ser assinados por certificados, geralmente uma autoridade de certificação privada interna. Como qualquer membro do cluster de banco de dados pode se tornar o mestre, os pares de certificado de cliente e servidor de banco de dados (contendo as chaves pública e privada) devem ser copiados para todos os servidores para que possam assumir a identidade do cliente ou servidor de banco de dados. Além disso, o certificado raiz da CA deve ser carregado para garantir que os certificados do cliente e do servidor possam ser verificados.

Assim, criamos uma solicitação de certificado que será utilizado por todos os serviços do servidor exceto o banco de dados (haverá uma solicitação separada para isso) com um comando como:

pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com

Em CN escrevemos o nome geral dos nossos servidores. Por exemplo, se os nomes de host dos nossos servidores Server01, Server02, Server03, então CN será servidor.exemplo.com

Fazemos o mesmo nos dois servidores restantes com a diferença de que os comandos conterão os “nomes de host” correspondentes

Geramos duas solicitações de certificados que serão utilizados pelo serviço de banco de dados com comandos como:

pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

pki csr dbclusterclient CN:postgres

onde servidordbcluster и dbclustercliente nomes de nossas solicitações e certificados futuros, nome do host1(2)(3) nomes dos servidores correspondentes.

Realizamos este procedimento apenas em um servidor (!), e faremos o upload dos certificados e dos arquivos .key correspondentes para outros servidores.

Habilitar o modo de certificado de cliente no AD CSServidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Você também precisa mesclar os certificados de cada servidor em um arquivo.Em *NIX: 

cat server01.cer server02.cer server03.cer > server.cer

No Windows/DOS: 

copy server01.cer + server02.cer + server03.cer  server.cer

E faça upload para cada servidor:
1. Certificado de servidor “individual”.
2. Certificado raiz (juntamente com os intermediários, se houver).
3. Certificados de banco de dados (“servidor” e “cliente”) e arquivos com extensão .key, que foram gerados na criação de uma solicitação de certificados de banco de dados “servidor” e “cliente”. Esses arquivos devem ser iguais em todos os servidores.
4. Arquivo dos três certificados “individuais”.

Como resultado, você deverá obter algo parecido com esta imagem de arquivo em cada servidor.

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Cluster de banco de dados

Agora que todos os certificados foram carregados nos servidores CMS, você pode configurar e ativar o clustering de banco de dados entre os três nós. A primeira etapa é selecionar um servidor como nó mestre do cluster de banco de dados e configurá-lo totalmente.

Banco de dados mestre

A primeira etapa na configuração da replicação do banco de dados é especificar os certificados que serão usados ​​para o banco de dados. Isso é feito usando um comando como:

database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>

Agora vamos dizer ao CMS qual interface usar para clustering de banco de dados com o comando:

database cluster localnode a

Em seguida, inicializamos o banco de dados do cluster no servidor principal com o comando:

database cluster initialize

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Nós do banco de dados cliente

Fazemos o mesmo procedimento, só que em vez do comando inicialização do cluster de banco de dados digite um comando como:

database cluster join <ip address existing master>

onde endereço IP endereço IP mestre existente do servidor CMS no qual o cluster foi inicializado, simplesmente Mestre.

Verificamos como nosso cluster de banco de dados funciona em todos os servidores com o comando:

database cluster status

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Fazemos o mesmo no terceiro servidor restante.

Como resultado, nosso primeiro servidor é o Master, os demais são Slaves.

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Serviço de administração da web

Habilite o serviço de administrador da web:

webadmin listen a 445

A porta 445 foi escolhida porque a porta 443 é usada para acesso do usuário ao web client

Configuramos o serviço Web Admin com arquivos de certificado com um comando como:

webadmin certs <keyfile> <certificatefile> <ca bundle>

E habilite o Web Admin com o comando:

webadmin enable

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Se tudo estiver bem, receberemos linhas de SUCCESS indicando que o Web Admin está configurado corretamente para a rede e certificado. Verificamos a funcionalidade do serviço usando um navegador web e inserimos o endereço do administrador web, por exemplo: cms.exemplo.com: 445

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Cluster de ponte de chamada

Call Bridge é o único serviço presente em todas as implantações de CMS. Call Bridge é o principal mecanismo de conferência. Ele também fornece uma interface SIP para que as chamadas possam ser roteadas de ou para ele, por exemplo, por um Cisco Unified CM.

Os comandos descritos abaixo devem ser executados em cada servidor com os certificados apropriados.
Assim:

Associamos certificados ao serviço Call Bridge com um comando como:

callbridge certs <keyfile> <certificatefile>[<cert-bundle>]

Vinculamos os serviços CallBridge à interface necessária com o comando:

callbridge listen a

E reinicie o serviço com o comando:

callbridge restart

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Agora que configuramos nossas Call Bridges, podemos configurar o clustering de Call Bridge. O clustering do Call Bridge é diferente do clustering de banco de dados ou XMPP. O Call Bridge Cluster pode suportar de 2 a 8 nós sem quaisquer restrições. Ele fornece não apenas redundância, mas também balanceamento de carga para que as conferências possam ser distribuídas ativamente entre servidores Call Bridge usando distribuição inteligente de chamadas. O CMS possui recursos adicionais, grupos de Call Bridge e recursos relacionados que podem ser usados ​​para gerenciamento posterior.

O clustering de ponte de chamada é configurado principalmente por meio da interface de administração da web
O procedimento descrito a seguir deve ser realizado em cada servidor do cluster.
Assim,

1. Acesse a web até Configuração > Cluster.
2. Em Identidade da ponte de chamada Como nome exclusivo, insira callbridge[01,02,03] correspondente ao nome do servidor. Esses nomes são arbitrários, mas devem ser exclusivos para este cluster. Eles são de natureza descritiva porque indicam que são identificadores de servidor [01,02,03].
3.B Pontes de chamadas agrupadas insira os URLs do administrador da web de nossos servidores no cluster, cms[01,02,03].example.com:445, no campo Endereço. Certifique-se de especificar a porta. Você pode deixar o domínio SIP do peer link vazio.
4. Adicione um certificado ao trust CallBridge de cada servidor, cujo arquivo contém todos os certificados de nossos servidores, que mesclamos neste arquivo no início, com um comando como: 

callbridge trust cluster <trusted cluster certificate bundle>

E reinicie o serviço com o comando:

callbridge restart

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Como resultado, em cada servidor você deverá obter esta imagem:
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Cluster XMPP

O serviço XMPP no CMS é usado para lidar com todo o registro e autenticação para Cisco Meeting Apps (CMA), incluindo o cliente web CMA WebRTC. O próprio Call Bridge também atua como um cliente XMPP para fins de autenticação e, portanto, deve ser configurado como outros clientes. A tolerância a falhas XMPP é um recurso suportado em ambientes de produção desde a versão 2.1

Os comandos descritos abaixo devem ser executados em cada servidor com os certificados apropriados.
Assim:

Associamos certificados ao serviço XMPP com um comando como:

xmpp certs <keyfile> <certificatefile>[<cert-bundle>]

Em seguida, defina a interface de escuta com o comando:

xmpp listen a

O serviço XMPP requer um domínio exclusivo. Este é o login dos usuários. Em outras palavras, quando um usuário tenta fazer login usando o aplicativo CMA (ou por meio do cliente WebRTC), ele insere userID@logindomain. No nosso caso será userid@conf.exemplo.com. Por que não é apenas example.com? Em nossa implantação específica, selecionamos nosso domínio Unified CM que os usuários do Jabber usarão no Unified CM como example.com, portanto, precisávamos de um domínio diferente para os usuários do CMS rotearem chamadas de e para o CMS por meio de domínios SIP.

Configure um domínio XMPP usando um comando como:

xmpp domain <domain>

E habilite o serviço XMPP com o comando:

xmpp enable

No serviço XMPP, você deve criar credenciais para cada Call Bridge que será utilizada no registro no serviço XMPP. Esses nomes são arbitrários (e não estão relacionados aos nomes exclusivos configurados para clustering de ponte de chamada). Você deve adicionar três pontes de chamada em um servidor XMPP e, em seguida, inserir essas credenciais em outros servidores XMPP no cluster porque essa configuração não cabe no banco de dados do cluster. Posteriormente iremos configurar cada Call Bridge para usar este nome e segredo para se registrar no serviço XMPP.

Agora precisamos configurar o serviço XMPP no primeiro servidor com três Call Bridges callbridge01, callbridge02 e callbridge03. Cada conta receberá senhas aleatórias. Posteriormente, eles serão inseridos em outros servidores Call Bridge para fazer login neste servidor XMPP. Digite os seguintes comandos:

xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03

Como resultado, verificamos o que aconteceu com o comando:

xmpp callbridge list

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência
Exatamente a mesma imagem deve aparecer nos servidores restantes após as etapas descritas abaixo.

A seguir, adicionamos exatamente as mesmas configurações nos dois servidores restantes, apenas com os comandos

xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03

Adicionamos Secret com muito cuidado para que, por exemplo, não haja espaços extras nele.
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Como resultado, cada servidor deverá ter a mesma imagem:

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

A seguir, em todos os servidores do cluster, especificamos como confiável o arquivo que contém todos os três certificados, criado anteriormente com um comando como este:

xmpp cluster trust <trust bundle>

Habilitamos o modo cluster xmpp em todos os servidores de cluster com o comando:

xmpp cluster enable

No primeiro servidor do cluster, iniciamos a criação de um cluster xmpp com o comando:

xmpp cluster initialize

Em outros servidores, adicione um cluster ao xmpp com um comando como:

xmpp cluster join <ip address head xmpp server>

Verificamos em cada servidor o sucesso da criação de um cluster XMPP em cada servidor com os comandos:

xmpp status
xmpp cluster status

Primeiro servidor:
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência
Segundo servidor:
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência
Terceiro servidor:
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Conectando Call Bridge ao XMPP

Agora que o cluster XMPP está em execução, é necessário configurar os serviços Call Bridge para se conectar ao cluster XMPP. Esta configuração é feita através do administrador web.

Em cada servidor, vá em Configuração > Geral e no campo Nome exclusivo da ponte de chamada escreva nomes exclusivos correspondentes ao servidor Call Bridge ponte de chamada[01,02,03]... Em campo Domínio conf.exemplo.ru e senhas correspondentes, você pode espioná-los
em qualquer servidor do cluster com o comando:

xmpp callbridge list

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Deixe o campo “Servidor” vazio Ponte de chamada realizará uma pesquisa DNS SRV para _xmpp-component._tcp.conf.example.compara encontrar um servidor XMPP disponível. Os endereços IP para conectar callbridges ao XMPP podem diferir em cada servidor, depende de quais valores são retornados para a solicitação de registro _xmpp-component._tcp.conf.example.com callbridge, que por sua vez depende das configurações de prioridade para um determinado registro DNS.

Em seguida, vá para Status > Geral para verificar se o serviço Call Bride está conectado com sucesso ao serviço XMPP.

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Ponte da Web

Em cada servidor do cluster, habilite o serviço Web Bridge com o comando:

webbridge listen a:443

Configuramos o serviço Web Bridge com arquivos de certificado com um comando como:

webbridge  certs <keyfile> <certificatefile> <ca bundle>

Web Bridge suporta HTTPS. Ele redirecionará HTTP para HTTPS se configurado para usar "http-redirect".
Para ativar o redirecionamento HTTP, use o seguinte comando:

webbridge http-redirect enable

Para informar ao Call Bridge que o Web Bridge pode confiar nas conexões do Call Bridge, use o comando:

webbridge trust <certfile>

onde este é um arquivo contendo todos os três certificados de cada servidor no cluster.

Esta imagem deve estar em todos os servidores do cluster.
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Agora precisamos criar um usuário com a função “appadmin”, precisamos dele para que possamos configurar nosso cluster(!), e não cada servidor do cluster separadamente, desta forma as configurações serão aplicadas igualmente a cada servidor apesar do fato de que eles serão feitos uma vez.
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Para configuração adicional, usaremos Postman.

Para autorização, selecione Básico na seção Autorização

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Para enviar comandos corretamente ao servidor CMS, você precisa definir a codificação necessária

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Especificamos Webbridge com o comando POST com parâmetro url e significado cms.exemplo.com

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Na própria webbridge indicamos os parâmetros necessários: acesso de convidado, acesso protegido, etc.

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Grupos de pontes de chamada

Por padrão, o CMS nem sempre faz o uso mais eficiente dos recursos de conferência disponíveis.

Por exemplo, para uma reunião com três participantes, cada participante pode acabar em três Call Bridges diferentes. Para que estes três participantes possam comunicar entre si, Call Bridges estabelecerá automaticamente ligações entre todos os servidores e clientes no mesmo Espaço, para que tudo pareça como se todos os clientes estivessem no mesmo servidor. Infelizmente, a desvantagem disso é que uma única conferência de 3 pessoas consumirá agora 9 portas de mídia. Isto é obviamente um uso ineficiente de recursos. Além disso, quando uma Call Bridge está realmente sobrecarregada, o mecanismo padrão é continuar a aceitar chamadas e fornecer serviço de qualidade reduzida a todos os assinantes dessa Call Bridge.

Esses problemas são resolvidos usando o recurso Call Bridge Group. Esse recurso foi introduzido na versão 2.1 do software Cisco Meeting Server e foi estendido para oferecer suporte ao balanceamento de carga para chamadas de entrada e saída do Cisco Meeting App (CMA), incluindo participantes WebRTC.

Para resolver o problema de reconexão, foram introduzidos três limites de carga configuráveis ​​para cada Call Bridge:

Limite de carga — esta é a carga numérica máxima para uma Call Bridge específica. Cada plataforma tem um limite de carga recomendado, como 96000 para o CMS1000 e 1.25 GHz por vCPU para a máquina virtual. Diferentes chamadas consomem uma certa quantidade de recursos dependendo da resolução e da taxa de quadros do participante.
NewConferenceLoadLimitBasisPoints (padrão 50% loadLimit) - define o limite de carga do servidor, após o qual novas conferências são rejeitadas.
PontosConferenceLoadLimitBasis existentes (padrão 80% de loadLimit) - o valor de carga do servidor após o qual os participantes que ingressarem em uma conferência existente serão rejeitados.

Embora esse recurso tenha sido projetado para distribuição de chamadas e balanceamento de carga, outros grupos, como servidores TURN, servidores Web Bridge e gravadores, também podem ser atribuídos a grupos de Call Bridge para que também possam ser agrupados adequadamente para uso ideal. Se algum destes objetos não for atribuído a um grupo de chamadas, presume-se que esteja disponível para todos os servidores sem qualquer prioridade específica.

Esses parâmetros são configurados aqui: cms.exemplo.com:445/api/v1/sistema/configuração/cluster

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

A seguir, indicamos a cada callbridge a qual grupo de callbridge ele pertence:

Primeira ponte de chamada
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência
Segunda ponte de chamada
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência
Terceira ponte de chamada
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Assim, configuramos o grupo Call Bridge para utilizar com mais eficiência os recursos do cluster Cisco Meeting Server.

Importando usuários do Active Directory

O serviço Web Admin possui uma seção de configuração LDAP, mas não fornece opções de configuração complexas e as informações não são armazenadas no banco de dados do cluster, portanto a configuração deverá ser feita manualmente em cada servidor através da interface Web ou através a API, e para que “três vezes “Não nos levantemos” ainda definiremos os dados através da API.

Usando URL para acessar cms01.exemplo.com:445/api/v1/ldapServers criam um objeto Servidor LDAP, especificando parâmetros como:

  • Endereço IP do servidor
  • número da porta
  • username
  • senha
  • seguro

Seguro - selecione verdadeiro ou falso dependendo da porta, 389 - não seguro, 636 - protegido.
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Mapeando parâmetros de origem LDAP para atributos no Cisco Meeting Server.
O mapeamento LDAP mapeia os atributos do diretório LDAP para os atributos do CMS. Os atributos reais:

  • jidMapping
  • nameMapping
  • coSpaceNameMapping
  • coSpaceUriMapping
  • coSpaceSecondaryUriMapping

Descrição dos atributosJID representa o ID de login do usuário no CMS. Como este é um servidor LDAP do Microsoft Active Directory, o JID do CMS é mapeado para sAMAccountName no LDAP, que é essencialmente o ID de login do usuário no Active Directory. Observe também que você pega sAMAccountName e adiciona o domínio conf.pod6.cms.lab ao final dele porque este é o login que seus usuários usarão para fazer login no CMS.

nameMapping corresponde ao que está contido no campo displayName do Active Directory com o campo de nome do CMS do usuário.

coSpaceNameMapping cria um nome de espaço CMS com base no campo displayName. Este atributo, juntamente com o atributo coSpaceUriMapping, é o necessário para criar um espaço para cada usuário.

coSpaceUriMapping define a parte do usuário do URI associada ao espaço pessoal do usuário. Alguns domínios podem ser configurados para serem discados para o espaço. Se a parte do usuário corresponder a este campo para um desses domínios, a chamada será direcionada para o espaço desse usuário.

coSpaceSecondaryUriMapping define um segundo URI para alcançar o espaço. Isso pode ser usado para adicionar um alias numérico para rotear chamadas para o espaço do usuário importado como uma alternativa ao URI alfanumérico definido no parâmetro coSpaceUriMapping.

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

O servidor LDAP e o mapeamento LDAP estão configurados. Agora você precisa vinculá-los criando uma fonte LDAP.

Usando URL para acessar cms01.exemplo.com:445/api/v1/ldapSource cria um objeto de origem LDAP, especificando parâmetros como:

  • servidor
  • mapeamento
  • baseDn
  • filtro

Agora que a configuração do LDAP foi concluída, você pode executar a operação de sincronização manual.

Fazemos isso na interface Web de cada servidor clicando em Sincronize agora seção Active Directory
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

ou através da API com o comando POST usando URL para acessar cms01.exemplo.com:445/api/v1/ldapSyncs

Conferências ad hoc

O que é isso?No conceito tradicional, uma conferência é quando dois participantes estão conversando entre si, e um dos participantes (usando um dispositivo cadastrado no Unified CM) pressiona o botão “Conferência”, liga para a outra pessoa e após falar com esse terceiro , pressiona novamente o botão "Conferência" para juntar todos os participantes na conferência tripartida.

O que distingue uma conferência Ad-Hoc de uma conferência agendada em um CMS é que uma conferência Ad-Hoc não é apenas uma chamada SIP para um CMS. Quando o iniciador da conferência clica no botão Conferência uma segunda vez para convidar todos para a mesma reunião, o Unified CM deve fazer uma chamada de API para o CMS para criar uma conferência dinâmica para a qual todas as chamadas serão transferidas. Tudo isso acontece despercebido pelos participantes.

Isso significa que o Unified CM deve configurar as credenciais da API e o endereço/porta WebAdmin do serviço, bem como o tronco SIP diretamente para o servidor CMS para continuar a chamada.

Se necessário, o CUCM pode criar dinamicamente um espaço no CMS para que cada chamada possa chegar ao CMS e corresponder à regra de chamada recebida destinada aos espaços.

Integração com CUCM configurado da mesma forma descrita no artigo mais cedo exceto que no Cisco UCM você precisa criar três troncos para o CMS, três pontes de conferência, no perfil de segurança SIP especificar três nomes de assuntos, grupos de rotas, listas de rotas, grupos de recursos de mídia e listas de grupos de recursos de mídia e adicionar algumas regras de roteamento para o Cisco Meeting Server.

Perfil de segurança SIP:
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Roupa de baixo:
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Cada tronco parece igual:
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Ponte de Conferência
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Cada Conference Bridge tem a mesma aparência:
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Grupo de rotas
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Lista de rotas
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Grupo de recursos de mídia
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Lista de grupos de recursos de mídia
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Regras de chamada

Ao contrário dos sistemas de gerenciamento de chamadas mais avançados, como Unified CM ou Expressway, o CMS apenas procura o domínio no campo SIP Request-URI para novas chamadas. Então se SIP INVITE for para gole: [email protegido]O CMS só se preocupa com domínio.com. O CMS segue estas regras para determinar para onde encaminhar uma chamada:

1. O CMS primeiro tenta combinar o domínio SIP com os domínios configurados nas regras de chamadas recebidas. Essas chamadas podem então ser roteadas para espaços (“direcionados”) ou usuários específicos, URAs internas ou destinos Microsoft Lync/Skype for Business (S4B) integrados diretamente.
2. Se não houver correspondência nas regras de chamadas recebidas, o CMS tentará corresponder ao domínio configurado na tabela de encaminhamento de chamadas. Se for feita uma correspondência, a regra poderá rejeitar explicitamente a chamada ou encaminhá-la. Neste momento, o CMS pode reescrever o domínio, o que às vezes é útil para chamar domínios do Lync. Você também pode optar por passar, o que significa que nenhum dos campos será modificado posteriormente, ou usar um plano de discagem interno do CMS. Se não houver correspondência nas regras de encaminhamento de chamadas, o padrão é rejeitar a chamada. Tenha em mente que no CMS, embora a chamada seja “encaminhada”, a mídia ainda está vinculada ao CMS, o que significa que estará no caminho de sinalização e tráfego de mídia.
Assim, apenas as chamadas encaminhadas estarão sujeitas às regras de chamadas de saída. Essas configurações determinam os destinos para onde as chamadas são enviadas, o tipo de tronco (seja uma nova chamada do Lync ou uma chamada SIP padrão) e quaisquer conversões que possam ser realizadas se a transferência não estiver selecionada na regra de encaminhamento de chamadas.

Aqui está o registro real do que acontece durante uma conferência Ad-Hoc

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

A captura de tela mostra mal (não sei como melhorar), então escreverei o log assim:

Info	127.0.0.1:35870: API user "api" created new space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call create failed to find coSpace -- attempting to retrieve from database

Info	API "001036270012" Space GUID: 7986bb6c-af4e-488d-9190-a75f16844e44 <--> Call GUID: 93bfb890-646c-4364-8795-9587bfdc55ba <--> Call Correlator GUID: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 <--> Internal G

Info	127.0.0.1:35872: API user "api" created new call 93bfb890-646c-4364-8795-9587bfdc55ba

Info	call 7: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg bc0be45e-ce8f-411c-be04-594e0220c38e in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 has control/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d

Info	conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 named "001036270012"

Info	call 7: configured - API call leg bc0be45e-ce8f-411c-be04-594e0220c38e with SIP call ID "[email protected]"

Info	call 7: setting up UDT RTP session for DTLS (combined media and control)
Info	conference "001036270012": unencrypted call legs now present

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 8: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg db61b242-1c6f-49bd-8339-091f62f5777a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 8: configured - API call leg db61b242-1c6f-49bd-8339-091f62f5777a with SIP call ID "[email protected]"

Info	call 8: setting up UDT RTP session for DTLS (combined media and control)

Info	call 9: incoming SIP call from "sip:[email protected]" to local URI "sip:[email protected]:5060" / "sip:[email protected]"

Info	API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a in call 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (API call 93bfb890-646c-4364-8795-9587bfdc55ba)

Info	call 9: configured - API call leg 37a6e86d-d457-47cf-be24-1dbe20ccf98a with SIP call ID "[email protected]"

Info	call 9: setting up UDT RTP session for DTLS (combined media and control)
Info	call 8: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (289e823d-6da8-486c-a7df-fe177f05e010) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 7: compensating for far end not matching payload types
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: compensating for far end not matching payload types

Info	participant "[email protected]" joined space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	participant "[email protected]" (d27e9a53-2c8a-4e9c-9363-0415cd812767) joined conference 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP

Info	call 9: BFCP (client role) now active
Info	call 9: sending BFCP hello as client following receipt of hello when BFCP not active
Info	call 9: BFCP (client role) now active
Info	call 7: ending; remote SIP teardown - connected for 0:13
Info	call 7: destroying API call leg bc0be45e-ce8f-411c-be04-594e0220c38e

Info	participant "[email protected]" left space 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)

Info	call 9: on hold
Info	call 9: non matching payload types mode 1/0
Info	call 9: answering offer in non matching payload types mode
Info	call 8: on hold
Info	call 8: follow-up single codec offer received
Info	call 8: non matching payload types mode 1/0
Info	call 8: answering offer in non matching payload types mode
Info	call 8: sending response to single-codec additional offer
Info	call 9: ending; remote SIP teardown - connected for 0:12

A própria conferência Ad-Hoc:
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Regras de chamadas recebidas
A configuração dos parâmetros das chamadas recebidas é necessária para poder receber uma chamada no CMS. Como você viu na configuração do LDAP, todos os usuários foram importados com o domínio conf.pod6.cms.lab. Portanto, no mínimo, você deseja que as chamadas para esse domínio sejam direcionadas a espaços. Você também precisará configurar regras para tudo o que se destina ao nome de domínio totalmente qualificado (e talvez até ao endereço IP) de cada um dos servidores CMS. Nosso controle de chamadas externo, Unified CM, configurará troncos SIP dedicados a cada um dos servidores CMS individualmente. Dependendo se o destino desses troncos SIP é um endereço IP ou o FQDN do servidor determinará se o CMS precisa ser configurado para aceitar chamadas direcionadas ao seu endereço IP ou FQDN.

O domínio que tem a regra de entrada de prioridade mais alta é usado como domínio para quaisquer espaços de usuário. Quando os usuários sincronizam via LDAP, o CMS cria espaços automaticamente, mas apenas a parte do usuário do URI (coSpaceUriMapping), por exemplo, user.space. Papel domínio O URI completo é gerado com base nesta regra. Na verdade, se você fizesse login no Web Bridge neste momento, veria que o Space URI não possui um domínio. Ao definir esta regra como a prioridade mais alta, você está definindo o domínio para que os espaços gerados sejam conf.exemplo. com.
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Regras de chamadas de saída

Para permitir que os usuários façam chamadas de saída para o cluster do Unified CM, você deve configurar regras de saída. O domínio dos endpoints registrados no Unified CM, como Jabber, é example.com. As chamadas para esse domínio devem ser roteadas como chamadas SIP padrão para nós de processamento de chamadas do Unified CM. O servidor principal é cucm-01.example.com e o servidor adicional é cucm-02.example.com.

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência
A primeira regra descreve o roteamento mais simples de chamadas entre servidores de cluster.

Campo Local do domínio é responsável pelo que será exibido no SIP-URI do chamador para a pessoa que está sendo chamada após o símbolo “@”. Se deixarmos em branco, depois do símbolo “@” estará o endereço IP do CUCM pelo qual esta chamada passa. Se especificarmos um domínio, após o símbolo “@” haverá realmente um domínio. Isto é necessário para poder retornar a chamada, caso contrário não será possível retornar a chamada via nome SIP-URI@endereçoip.

Ligue quando especificado Local do domínio
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Ligue quando NÃO indicado Local do domínio
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Certifique-se de especificar explicitamente Criptografado ou Não Criptografado para chamadas de saída, pois nada funciona com o parâmetro Auto.

Gravação

As videoconferências são gravadas pelo servidor Record. O gravador é exatamente igual ao Cisco Meeting Server. O gravador não requer instalação de nenhuma licença. Licenças de gravação são necessárias para servidores que executam serviços CallBridge, ou seja, uma licença de gravação é necessária e deve ser aplicada ao componente CallBridge, e não ao servidor que executa o Recorder. O gravador se comporta como um cliente Extensible Messaging and Presence Protocol (XMPP), portanto, o servidor XMPP deve estar habilitado no servidor que hospeda o CallBridge.

Porque Temos um cluster e a licença precisa ser “estendida” por todos os três servidores do cluster. Depois, basta associar (adicionar) os endereços MAC das interfaces a de todos os servidores CMS incluídos no cluster na sua conta pessoal nas licenças.

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

E esta é a imagem que deveria estar em todos os servidores do cluster

Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Em geral, existem vários cenários para colocar o Recorder, mas vamos nos ater a isto:
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

Antes de configurar o Gravador, é necessário preparar um local onde as videoconferências serão realmente gravadas. Na verdade aqui link, como configurar todas as gravações. Eu me concentro em pontos e detalhes importantes:

1. É melhor retirar o certificado do primeiro servidor do cluster.
2. O erro “Gravador indisponível” pode ocorrer porque o certificado errado foi especificado no Recorder Trust.
3. A gravação pode não funcionar se o diretório NFS especificado para gravação não for o diretório raiz.

Às vezes, é necessário gravar automaticamente uma conferência de um usuário ou espaço específico.

Para isso, são criados dois CallProfiles:
Com gravação desativada
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

E com função de gravação automática
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

A seguir, “anexamos” um CallProfile com função de gravação automática ao espaço desejado.
Servidor de reunião Cisco 2.5.2. Cluster em modo Escalável e Resiliente com função de gravação de videoconferência

No CMS está estabelecido que se um CallProfile estiver explicitamente vinculado a qualquer espaço ou espaço, então este CallProfile funciona apenas em relação a esses espaços específicos. E se o CallProfile não estiver vinculado a nenhum espaço, por padrão ele será aplicado aos espaços aos quais nenhum CallProfile está explicitamente vinculado.

Da próxima vez tentarei descrever como o CMS é acessado fora da rede interna da organização.

Fontes:

Fonte: habr.com

Adicionar um comentário