Neste episódio, vou mostrar e explicar algumas nuances da configuração do servidor CMS em modo de cluster com alta disponibilidade.
TeoriaExistem três tipos de implantação do servidor CMS:
- Single Combined(Único combinado), ou seja, é um único servidor onde todos os serviços necessários estão em execução. Na maioria das vezes, esse tipo de implantação é aplicável apenas para acesso a clientes internos e em ambientes pequenos, 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 em que o CMS executa apenas funções específicas, como conferências especiais no Cisco UCM.
Diagrama aproximado de funcionamento:
- Single Split(Único dividido) expande o tipo de implantação anterior, adicionando um servidor separado para acesso externo. Em implantações mais antigas, isso significava a implementação de um servidor CMS em um segmento de rede desmilitarizado (DMZ), onde clientes externos poderiam acessá-lo, e um servidor CMS no núcleo da rede, onde clientes internos acessam o CMS. Esse modelo específico de implantação está sendo gradualmente substituído pelo chamado tipo Single Edge, que consiste em servidores Cisco Expressway, que possuem ou terão muitas das funcionalidades de contorno de Firewall, portanto, os clientes não precisam adicionar um servidor de borda CMS dedicado.
Diagrama aproximado de funcionamento:
- Scalable and Resilient(Escalável e Resiliente) esse tipo inclui redundância para cada componente, permitindo que o sistema cresça com suas necessidades até a capacidade máxima, garantindo também redundância em caso de falha. Ele também utiliza o conceito de Single Edge para garantir acesso externo seguro. Este é o tipo que vamos abordar neste episódio. Se entendermos como implantar um cluster desse tipo, não apenas compreenderemos outros tipos de implantação, mas também poderemos entender como criar clusters de servidores CMS considerando o crescimento potencial das necessidades.
Antes de prosseguir com a implantação, é importante entender algumas coisas básicas, a saber:
Componentes de software principais do CMS:
- Banco de dados: permite combinar algumas configurações, como grupo de assinantes, espaços de usuários e os próprios usuários. Suporta clusterização apenas para alta disponibilidade (um mestre).
- Call Bridge: um serviço para conferências de áudio e vídeo que oferece controle total sobre a gestão e o processamento de chamadas e processos multimídia. Suporta a clusterização para alta disponibilidade e escalabilidade.
- Servidor XMPP: é responsável pelo registro e autenticação de clientes utilizando o aplicativo Cisco Meeting Application e/ou WebRTC (comunicação em tempo real, ou simplesmente no navegador), bem como pela sinalização intercomponentes. Pode ser clusterizado apenas para alta disponibilidade.
- Web Bridge: fornece acesso dos clientes no WebRTC.
- Loadbalancer: garante um único ponto de conexão para aplicativos Cisco Meeting App no modo Single Split. Escuta a interface externa e a porta para conexões de entrada. De forma igual, o balanceador de carga aceita conexões TLS de entrada do servidor XMPP, através do qual ele pode alternar conexões TCP de clientes externos.
No nosso cenário, ele não será necessário. - Servidor TURN: fornece tecnologia para contornar firewalls, permitindo
expor nosso CMS fora do firewall ou NAT para conectar clientes externos utilizando o Cisco Meeting App ou dispositivos SIP. No nosso cenário, ele não será necessário. - Web Admin: interface administrativa e acesso à API, incluindo para conferências especiais Unified CM.
Modos de configuração
Ao contrário da maioria dos outros produtos Cisco, o Cisco Meeting Server suporta três métodos de configuração, permitindo implantar qualquer tipo de implantação.
- Linha de comando (CLI): interface de linha de comando, conhecida como MMP, para tarefas de configuração inicial e certificados.
- Web Admin: principalmente para configuração relacionada ao CallBridge, especialmente ao configurar um único servidor não clusterizado.
- REST API: utilizado para as tarefas de configuração mais complexas e tarefas relacionadas à base de dados em cluster.
Além do acima mencionado, utiliza o protocolo SFTP para transferência de arquivos — geralmente licenças, certificados ou registros — para o servidor CMS e a partir dele.
Nos guias de implantação da Cisco está claramente mencionado que o cluster precisa ser implantado com um mínimo de três servidores (nós) no contexto de bases de dados. Pois apenas com um número ímpar de nós funcionará o mecanismo de escolha de um novo Master de base de dados, e de fato o Master de base de dados tem relação com grande parte da base de dados do servidor CMS.
E como a prática mostra, dois servidores (nós) realmente não são suficientes. O mecanismo de escolha atua durante a reinicialização do Master, o servidor Slave só se torna Master após a ativação do servidor reinicializado. No entanto, se em um cluster de dois servidores o servidor Master 'apagou', o servidor Slave não se tornará Master, e se o Slave 'apagou', o Master restante se tornará um Slave.
No contexto do XMPP, realmente seria necessário montar um cluster de três servidores, pois, se por exemplo, a serviço XMPP em um dos servidores que está com o status de Líder for desativado, o restante permanecerá com o status de Seguidor e as conexões CallBridge ao XMPP serão perdidas, já que o CallBridge conecta-se exclusivamente ao XMPP com o status de Líder. Isso é crítico, pois nenhuma chamada será atendida.
Além disso, nesses mesmos guias de implantação é demonstrado um cluster com um único servidor XMPP.
E com isso, fica claro porque: funciona porque está em modo failover.
No nosso caso, o servidor XMPP estará presente em todos os três nós.
Supõe-se que nossos três servidores estejam ativos.
Registros DNS
Antes de começar a configurar os servidores, é necessário criar registros DNS. A e SRV tipos:
Observe que em nossos registros DNS existem dois domínios example.com e conf.example.com. Example.com é o domínio que pode ser utilizado para seus URIs por todos os assinantes do Cisco Unified Communication Manager, que provavelmente está presente em sua infraestrutura ou tem uma alta probabilidade de ser. Ou então o domínio example.com corresponde ao mesmo domínio que os usuários usam para seus endereços de e-mail. Ou o cliente Jabber em seu laptop pode ter o URI user@example.com. O domínio conf.example.com é o domínio que será configurado para os usuários do Cisco Meeting Server. O domínio do Cisco Meeting Server será conf.example.com, portanto, para o mesmo usuário Jabber, o acesso ao Cisco Meeting Server precisará usar o URI user@conf.example.com.
Configuração básica
Todas as configurações descritas abaixo são mostradas em um servidor, mas devem ser realizadas em cada servidor do cluster.
QoS
Uma vez que o CMS gera streaming). Portanto, é necessário um cenário de inserção diferente, e as próprias consultas têm suas particularidades. O tráfego sensível à latência e perda de pacotes, na maioria dos casos, deve ter a qualidade de serviço (QoS) configurada. Para isso, o CMS suporta a marcação de pacotes com códigos de serviços diferenciados (DSCP) que ele gera. Embora a priorização do tráfego baseado em DSCP dependa de como o tráfego é tratado pelos componentes de rede de sua infraestrutura, neste caso configuraremos o nosso CMS com uma distribuição típica de prioridades DSCP com base nas melhores práticas de QoS.
Em cada servidor, vamos inserir os seguintes comandos
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1AAssim, 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), e outros tipos de tráfego de baixa latência, como SIP e XMPP, usam AF31 (DSCP 0x1A).
Verificamos:
NTP
O Protocolo de Tempo de Rede (NTP) é crucial não apenas para fornecer registros de horário precisos para chamadas e conferências, mas também para a verificação de certificados.
Adicionamos servidores NTP à sua infraestrutura com um comando do tipo
ntp server add Neste caso, temos dois servidores, então teremos dois comandos.
Verificamos:
E definimos o fuso horário para o nosso servidor
DNS
Adicionamos servidores DNS no CMS com o comando do tipo:
dns add forwardzone Neste caso, temos dois servidores, então teremos dois comandos.
Verificamos:
Configuração da interface de rede
Configuramos a interface com um comando do tipo:
ipv4 add / Verificamos:
Nome do servidor (Hostname)
Definimos o nome do servidor com um comando do tipo:
hostname E reiniciamos.
Com isso, a configuração básica está concluída.
Certificados
TeoriaO Cisco Meeting Server requer comunicação criptografada entre diferentes componentes e, por isso, certificados X.509 são necessários para todas as implementações do CMS. Eles ajudam a garantir a confiança dos serviços/servidores para outros serviços/servidores.
Um certificado é necessário para cada serviço, no entanto, criar certificados separados para cada serviço pode levar a confusões e complexidade desnecessária. Felizmente, podemos gerar um par de chaves públicas e privadas para o certificado e, em seguida, reutilizá-las para vários serviços. Neste caso, o mesmo certificado será utilizado para o Call Bridge, servidor XMPP, Web Bridge e Web Admin. Assim, precisamos criar um par de chaves públicas e privadas para cada servidor no cluster.
A clusterização de banco de dados, no entanto, possui alguns requisitos especiais em relação aos certificados e, portanto, exige seus próprios certificados, distintos dos certificados de outros serviços. O CMS utiliza um certificado de servidor que é semelhante aos certificados usados por outros servidores, mas também existe um certificado de cliente, que é utilizado para conexões com o banco de dados. Os certificados de banco de dados são usados tanto para autenticação quanto para criptografia. Em vez de fornecer um nome de usuário e senha para a conexão do cliente ao banco de dados, é apresentado um certificado de cliente, confiável pelo 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 no cluster criptografem dados de uma forma que apenas outros servidores, que também utilizam o mesmo par de chaves, consigam descriptografá-los.
Para que a redundância funcione, os clusters de banco de dados devem consistir em pelo menos 3 servidores, mas não mais que 5, com um tempo máximo de latência em ambas as direções de 200 ms entre quaisquer membros do cluster. Este limite é mais restritivo do que o da clusterização do Call Bridge, portanto, muitas vezes é um fator limitante em implantações geograficamente distribuídas.
O papel do banco de dados para o CMS tem uma série de requisitos únicos. Ao contrário de outras funções, ele exige um certificado de cliente e de servidor, onde o certificado de cliente possui um campo CN específico, que é apresentado ao servidor.
O CMS utiliza um banco de dados postgres com um principal e várias réplicas idênticas. Em qualquer momento, existe apenas um banco de dados principal ("servidor de banco de dados"). Os demais membros do cluster são réplicas ou "clientes de banco de dados".
Para o cluster de banco de dados, são necessários um certificado de servidor dedicado e um certificado de cliente. Eles devem ser assinados por certificados, geralmente de uma autoridade certificadora interna privada. Como qualquer um dos membros do cluster de banco de dados pode se tornar o principal, os pares de certificados do servidor de banco de dados e do cliente (contendo as chaves pública e privada) devem ser copiados em todos os servidores, para que possam aceitar a identidade do cliente ou do 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, formamos um pedido para o certificado que será usado por todos os serviços do servidor, exceto pelo database (para isso haverá um pedido separado), com o comando do tipo:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
No CN, escrevemos um nome genérico para nossos servidores. Por exemplo, se os nomes hosts dos nossos servidores server01, server02, server03, então o CN será server.example.com
Fazemos o mesmo nos outros dois servidores, com a diferença de que os comandos terão os respectivos 'nomes hosts'
Formamos dois pedidos para os certificados que serão usados pelo serviço de database, com os comandos do tipo:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgresonde dbclusterserver e dbclusterclient os nomes de nossos pedidos e futuros certificados, hostname1(2)(3) os nomes dos servidores correspondentes.
Esta procedimento deve ser realizado apenas em um servidor (!), e os certificados e os respectivos arquivos .key serão carregados nos outros servidores.
Ativando o modo de certificado de cliente no AD CS
Ainda precisamos combinar em um arquivo os certificados para cada servidorEm *NIX:
cat server01.cer server02.cer server03.cer > server.cerEm Windows/DOS:
copy server01.cer + server02.cer + server03.cer server.cer E carregar em cada servidor:
1. O certificado 'individual' do servidor.
2. O certificado raiz (junto com intermediários, se houver).
3. Os certificados para o banco de dados ('servidor' e 'cliente') e arquivos com extensão .key, que foram gerados ao criar o pedido para o certificado 'servidor' e 'cliente' do banco de dados. Estes arquivos devem ser os mesmos em todos os servidores.
4. O arquivo de todos os três certificados 'individuais'.
No final, deve resultar em uma estrutura de arquivos aproximadamente assim em cada servidor.
Cluster de Banco de Dados
Agora que você tem todos os certificados carregados nos servidores CMS, você pode configurar e habilitar a clusterização do banco de dados entre três nós. O primeiro passo é escolher um servidor como o nó principal do cluster de banco de dados e configurá-lo completamente.
Banco de Dados Principal
O primeiro passo na configuração da replicação do banco de dados é especificar os certificados que serão usados para o banco de dados. Isso é feito com um comando no formato:
database cluster certsAgora vamos informar ao CMS qual interface usar para a clusterização dos bancos de dados com o comando:
database cluster localnode aEm seguida, inicializamos o banco de dados do cluster no servidor principal com o comando:
database cluster initialize
Nodos de Banco de Dados do Cliente
Realizamos o mesmo procedimento, mas em vez do comando database cluster initialize digitamos um comando no formato:
database cluster joinonde ip address existing master é o endereço IP do servidor CMS onde a inicialização do cluster foi realizada, ou seja, o Master.
Verificamos como está o funcionamento do nosso cluster de banco de dados em todos os servidores com o comando:
database cluster status
Fazemos o mesmo no terceiro servidor restante.
No final, teremos que o nosso primeiro servidor é o Master, enquanto os outros são Slaves.
Serviço de Administração Web
Habilitamos o serviço de administração web:
webadmin listen a 445A porta 445 foi escolhida porque a porta 443 é utilizada para o acesso dos usuários ao web-client.
Configuramos o serviço Web Admin com os arquivos dos certificados utilizando um comando no formato:
webadmin certsE habilitamos o Web Admin com o comando:
webadmin enable 
Se tudo estiver certo, receberemos as linhas de SUCESSO, que indicam que o Web Admin está corretamente configurado para a rede e o certificado. Verificamos o funcionamento do serviço através do navegador web, digitando o endereço do administrador web, por exemplo: :445
Cluster do Call Bridge
O Call Bridge é o único serviço presente em cada instalação do CMS. O Call Bridge é o mecanismo principal de conferência. Ele também fornece uma interface SIP, permitindo que chamadas sejam roteadas para ele ou dele, como, por exemplo, Cisco Unified CM.
Os comandos descritos abaixo devem ser executados em cada servidor com os certificados correspondentes.
Então:
Vinculamos os certificados ao serviço Call Bridge com o comando:
callbridge certs []Associamos os serviços CallBridge à interface necessária com o comando:
callbridge listen aE reiniciamos o serviço com o comando:
callbridge restart 
Agora que temos os Call Bridges configurados, podemos configurar a clusterização do Call Bridge. A clusterização do Call Bridge é diferente da clusterização de banco de dados ou XMPP. O Cluster de Call Bridge pode suportar de 2 a 8 nós sem quaisquer limitações. Ele fornece não apenas redundância, mas também distribuição de carga, permitindo que as conferências sejam ativamente distribuídas entre os servidores Call Bridge por meio de uma distribuição inteligente de chamadas. O CMS possui funcionalidades adicionais, grupos de Call Bridge e funções relacionadas que podem ser usadas para um gerenciamento mais aprofundado.
A clusterização do Call Bridge é configurada principalmente através da interface do administrador da web
O procedimento abaixo deve ser realizado em cada servidor do cluster.
Então,
1. Acesse através da web em Configuration > Cluster.
2. Em Identidade do Call Bridge como nome único, insira callbridge[01,02,03] correspondente ao nome do servidor. Esses nomes são arbitrários, mas devem ser únicos para este cluster. Eles têm um caráter descritivo, pois indicam que são identificadores de servidores [01,02,03].
3. Em Call Bridges Agrupados insira os endereços URL do administrador da web dos nossos servidores no cluster, [01,02,03].example.com:445, no campo Endereço. Certifique-se de especificar a porta. Você pode deixar o campo do domínio SIP do Peer link vazio.
4. Adicione à confiança do Call Bridge de cada servidor o certificado, cujo arquivo contém todos os certificados dos nossos servidores, que unimos neste arquivo no início, com um comando do tipo:
callbridge trust clusterE reiniciamos o serviço com o comando:
callbridge restart 
No final, em cada servidor, o resultado deve ser semelhante a este:
Cluster XMPP
O serviço XMPP no CMS é usado para processar todo o registro e autenticação para os 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 do XMPP é uma funcionalidade suportada em ambientes de produção, a partir da versão 2.1
Os comandos descritos abaixo devem ser executados em cada servidor com os certificados correspondentes.
Então:
Vincule os certificados ao serviço XMPP com um comando do tipo:
xmpp certs []Em seguida, defina a interface de escuta com o comando:
xmpp listen aPara o serviço XMPP, é necessário um domínio único. Este é o login para os usuários. Em outras palavras, quando um usuário tenta fazer login com o aplicativo CMA (ou através do cliente WebRTC), ele insere userID@logindomain. No nosso caso, será userid@conf.example.com. Por que não apenas example.com? Na nossa implementação específica, escolhemos nosso domínio Unified CM, que os usuários Jabber utilizarão no Unified CM, como example.com, portanto, precisamos de outro domínio para os usuários do CMS, a fim de direcionar chamadas para o CMS e a partir do CMS por meio de domínios SIP.
Configure o domínio XMPP com o comando do tipo:
xmpp domainE ativamos o serviço XMPP com o comando:
xmpp enableNo serviço XMPP, é necessário criar credenciais para cada Call Bridge, que serão usadas para registrar-se no serviço XMPP. Esses nomes são arbitrários (e não estão relacionados aos nomes únicos que você configurou para a clusterização do bridge de chamadas). Em um servidor XMPP, é necessário adicionar três bridges de chamadas, e depois inserir essas credenciais em outros servidores XMPP no cluster, uma vez que essa configuração não se encontra na base de dados do cluster. Posteriormente, configuraremos cada Call Bridge para usar esse nome e segredo para registro 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, elas serão inseridas em outros servidores Call Bridge para login neste servidor XMPP. Inserimos os seguintes comandos:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03Por fim, verificamos o que foi configurado com o comando:
xmpp callbridge list 
A mesma configuração deve estar presente nos demais servidores após as ações descritas abaixo.
Em seguida, adicionamos nos outros dois servidores exatamente as mesmas configurações, apenas com os comandos
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03A adição do Secret deve ser feita com muito cuidado, para não incluir acidentalmente espaços extras, por exemplo.
No final, em cada servidor deve haver a mesma configuração:
Em seguida, em todos os servidores do cluster, indicamos no trust um arquivo contendo todos os três certificados, criado anteriormente com um comando do tipo:
xmpp cluster trustAtivamos o modo de cluster xmpp em todos os servidores do cluster com o comando:
xmpp cluster enableNo primeiro servidor do cluster, iniciamos a criação do cluster xmpp com o comando:
xmpp cluster initializeNos demais servidores, adicionamos ao cluster xmpp com um comando do tipo:
xmpp cluster joinVerificamos em cada servidor o sucesso da criação do cluster XMPP com os comandos:
xmpp status
xmpp cluster statusPrimeiro servidor:
Segundo servidor:
Terceiro servidor:
Conectando o Call Bridge ao XMPP
Agora que o cluster XMPP está em funcionamento, é necessário configurar os serviços Call Bridge para se conectar ao cluster XMPP. Esta configuração é realizada através do administrador web.
Acessamos em cada servidor em Configuration > General e no campo Unique Call Bridge name escrevemos os nomes únicos do Call Bridge correspondentes ao servidor callbridge[01,02,03]. No campo Domínio conf.example.ru e as respectivas senhas, que podem ser consultadas
em qualquer servidor do cluster com o comando:
xmpp callbridge list 
O campo 'Servidor' deixamos vazio, Callbridge fará a busca pelo DNS SRV para _xmpp-component._tcp.conf.example.com, para encontrar um servidor XMPP disponível. Os endereços IP de conexão dos callbridges podem variar em cada servidor, dependendo dos valores retornados na consulta pelo registro _xmpp-component._tcp.conf.example.com do callbridge, o que por sua vez depende das configurações de prioridade para esse registro DNS.
Em seguida, vamos para Status > General, para verificar se o serviço Call Bride está conectado ao serviço XMPP.
Web Bridge
Em cada servidor do cluster, habilitamos o serviço Web Bridge com o comando:
webbridge listen a:443Configuramos o serviço Web Bridge com os arquivos de certificados utilizando um comando do tipo:
webbridge certsO Web Bridge suporta HTTPS. Ele vai redirecionar HTTP para HTTPS, se configurado para usar 'http-redirect'.
Para ativar o redirecionamento HTTP, utilize o seguinte comando:
webbridge http-redirect enablePara que o Call Bridge indique que o Web Bridge pode confiar nas conexões do Call Bridge, utilize o comando:
webbridge trustonde este é o arquivo que contém os três certificados de cada servidor no cluster.
Esta configuração deve ser a mesma em cada servidor do cluster.
Agora precisamos criar um usuário com a função 'appadmin', que é necessário para que possamos configurar nosso cluster(!), e não cada servidor do cluster individualmente, assim as configurações serão aplicadas igualmente a cada servidor, sendo configuradas apenas uma vez.
Para a configuração adicional, utilizaremos .
Para autenticação, selecionamos Basic na seção Autorization
Para o envio correto de comandos para os servidores do CMS, é necessário definir a codificação adequada.
Especificamos os Webbridges pelo comando. POST com o parâmetro url e valor
No próprio webbridge, especificamos os parâmetros necessários: acesso de convidado, acesso seguro e outros.
Grupos de Call Bridge.
Por padrão, o CMS nem sempre utiliza da forma mais eficiente os recursos disponíveis de conferência.
Por exemplo, para uma reunião com três participantes, cada um pode estar em três Call Bridges diferentes. Para que esses três participantes possam se comunicar entre si, os Call Bridges automaticamente estabelecerão conexões entre todos os servidores e clientes no mesmo Space, para que pareça que todos os clientes estão em um único servidor. Infelizmente, a desvantagem disso é que uma conferência de 3 pessoas agora consumirá 9 portas de mídia. Isso, evidentemente, não é uma utilização eficiente dos recursos. Além disso, quando o Call Bridge está realmente sobrecarregado, o mecanismo padrão é continuar aceitando chamadas e prestar serviços com qualidade reduzida a todos os assinantes desse Call Bridge.
Esses problemas são resolvidos com a função Grupo de Call Bridge. Essa função foi apresentada na versão 2.1 do software Cisco Meeting Server e foi expandida para suportar balanceamento de carga tanto para chamadas de entrada quanto de saída, incluindo o Cisco Meeting App (CMA), que abrange participantes do WebRTC.
Para resolver o problema de reconexão, foram introduzidos três limites de carga configuráveis para cada Call Bridge:
LoadLimit — é a carga numérica máxima para um Call Bridge específico. Cada plataforma tem um valor limite de carga recomendado, como 96000 para CMS1000 e 1,25 GHz por CPU virtual para a máquina virtual. Chamadas diferentes consomem uma quantidade específica de recursos dependendo da resolução e da taxa de quadros do participante.
NewConferenceLoadLimitBasisPoints (por padrão 50% do loadLimit) — define o limite de carga do servidor, após o qual novas conferências são rejeitadas.
ExistingConferenceLoadLimitBasisPoints (por padrão 80% do loadLimit) — valor de carga do servidor, após o qual os participantes que se juntam a uma conferência existente serão rejeitados.
Enquanto esta função foi desenvolvida para distribuição de chamadas e balanceamento de carga, outros grupos, como servidores TURN, servidores Web Bridge e dispositivos de gravação, também podem ser atribuídos a Grupos de Bridge de Chamadas, para que também possam ser agrupados corretamente para uso otimizado. Se algum desses objetos não for atribuído ao grupo de chamadas, presume-se que eles estejam disponíveis para todos os servidores sem qualquer prioridade específica.
Essas configurações são ajustadas aqui: :445/api/v1/system/configuration/cluster
Em seguida, indicamos a cada callbridge a qual grupo de callbridge ele pertence:
Primeiro callbridge
Segundo callbridge
Terceiro callbridge
Assim, configuramos um grupo de Call Bridge para um uso mais eficiente dos recursos do cluster do Cisco Meeting Server.
Importar 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 salvas no banco de dados do cluster, portanto, a configuração terá que ser feita, manualmente em cada servidor através da interface Web ou via API, e para não precisarmos nos levantar três vezes, vamos configurar os dados através da API.
Usando o URL para acessar :445/api/v1/ldapServers criamos o objeto do servidor LDAP, especificando parâmetros como:
- Endereço IP do servidor
- número da porta
- nome de usuário
- senha
- seguro
Seguro — true ou false, escolhemos dependendo da porta, 389 — não segura, 636 — segura.
Mapeando os parâmetros LDAP de origem para os atributos no Cisco Meeting Server.
O mapeamento LDAP alinha os atributos no diretório LDAP com os atributos no CMS. Os próprios atributos:
- jidMapping
- nameMapping
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Descrição dos atributosJID representa o identificador de login do usuário no CMS. Como este é um servidor LDAP do Microsoft Active Directory, o JID do CMS é mapeado para o sAMAccountName no LDAP, que é essencialmente o identificador de login do usuário no Active Directory. Observe também que você pega o sAMAccountName e adiciona o domínio conf.pod6.cms.lab ao seu final, porque esse é o login que seus usuários usarão para acessar o CMS.
nameMapping mapeia o que está contido no campo displayName do Active Directory com o campo nome do usuário no CMS.
coSpaceNameMapping cria o nome do espaço do CMS com base no campo displayName. Este atributo, junto com o atributo coSpaceUriMapping, é o que é necessário para criar um espaço para cada usuário.
coSpaceUriMapping define a parte do URI associada ao espaço pessoal do usuário. Alguns domínios podem ser configurados para séries no espaço. Se a parte do usuário corresponder a este campo para um desses domínios, a chamada será direcionada ao espaço desse usuário.
coSpaceSecondaryUriMapping define um segundo URI para acessar o espaço. Isso pode ser utilizado para adicionar um pseudônimo numérico para roteamento de chamadas para o espaço do usuário importado como alternativa ao URI alfanumérico definido na configuração coSpaceUriMapping.
O servidor LDAP e o mapeamento LDAP estão configurados. Agora é necessário vinculá-los, criando uma fonte LDAP.
Usando o URL para acessar :445/api/v1/ldapSource criamos o objeto LDAP Source, especificando parâmetros como:
- servidor
- mapeamento
- baseDn
- filtro
Agora que a configuração LDAP está concluída, podemos executar a operação de sincronização manual.
Fazemos isso pelo Web interface de cada servidor pressionando Sincronizar agora na seção Active Directory
ou através da API com o comando POST usando o URL para acessar :445/api/v1/ldapSyncs
Conferências Ad-Hoc
O que é isso?No conceito tradicional, uma conferência é quando dois participantes conversam entre si, e um dos participantes (usando um dispositivo registrado no Unified CM) pressiona o botão 'Conferência', chama outra pessoa e, após conversar com esse terceiro, pressionam novamente o botão 'Conferência' para se juntar a todos os participantes da conferência de três vias.
A conferência Ad-Hoc difere da conferência agendada no CMS na medida em que a conferência Ad-Hoc não é apenas uma chamada SIP para o CMS. Quando o iniciador da conferência pressiona o botão 'Conferência' pela segunda vez para convidar todos para a mesma reunião, o Unified CM deve fazer uma chamada API para o CMS para criar a conferência 'on-the-fly', para a qual todas as chamadas são então direcionadas. Tudo isso ocorre sem que os participantes percebam.
Isso significa que o Unified CM deve configurar as credenciais da API e o endereço/porta do WebAdmin do serviço, além do SIP-Trunk diretamente no 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 chamadas recebidas destinada aos espaços.
A integração com CUCM é configurada conforme descrito no artigo exceto que no Cisco UCM é necessário criar três troncos para CMS, três bridges de conferência, no perfil de segurança SIP indicar três nomes de assunto, grupo de roteamento, lista de roteamento, grupo de recursos de mídia e lista de grupo de recursos de mídia, e no Cisco Meeting Server adicionar algumas regras de roteamento.
Perfil de Segurança SIP:
Troncos:
Cada tronco parece igual:
Bridge de Conferência
Cada bridge de conferência parece igual:
Grupo de Roteamento
Lista de Roteamento
Grupo de Recursos de Mídia
Lista de Grupo de Recursos de Mídia
Regras de Chamadas
Diferentemente de sistemas de gerenciamento de chamadas mais sofisticados, como o Unified CM ou Expressway, para novas chamadas o CMS verifica o domínio apenas no campo SIP Request-URI. Portanto, se um SIP INVITE for destinado a sip:user@domain.com, o CMS se preocupa apenas com domain.com. O CMS segue essas regras para determinar para onde direcionar a chamada:
1. Primeiro, o CMS tenta corresponder o domínio SIP com os domínios configurados nas regras de tratamento de chamadas recebidas. Então, essas chamadas podem ser direcionadas para espaços "destinos" ou usuários específicos, IVR interno ou diretamente para destinatários integrados do Microsoft Lync/Skype para Empresas (S4B).
2. Se não houver correspondências nas regras de tratamento de chamadas recebidas, o CMS tentará corresponder o domínio configurado na tabela de redirecionamento de chamadas. Se a correspondência for estabelecida, a regra pode explicitamente recusar a chamada ou redirecionar a chamada. Neste momento, o CMS pode reescrever o domínio, o que às vezes é útil para chamadas para domínios Lync. Você também pode optar por pass throw, que significa que nenhum dos campos será alterado ainda mais, ou usar o grupo de assinantes interno do CMS. Se não houver correspondências nas regras de redirecionamento de chamadas, a recusa da chamada será usada como padrão. Lembre-se de que no CMS, embora a chamada seja "redirecionada", a multimídia ainda se vincula ao CMS, o que significa que estará no caminho do tráfego de sinalização e multimídia.
Então, somente chamadas redirecionadas estão sujeitas às regras de chamadas de saída. Estas opções definem os destinatários para onde enviar chamadas, o tipo de linha de conexão (seja uma nova chamada Lync ou SIP padrão) e quaisquer conversões que possam ser realizadas se a regra de redirecionamento de chamadas não selecionar a transmissão.
Aqui está o log do que acontece durante a conferência Ad-Hoc
Na captura de tela está visível de forma ruim (não sei como fazer melhor), então escreverei o log assim:
Informação 127.0.0.1:35870: Usuário da API "api" criou um novo espaço 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Informação chamada de criação falhou ao encontrar coSpace -- tentando recuperar do banco de dados
Informação API "001036270012" GUID do Espaço: 7986bb6c-af4e-488d-9190-a75f16844e44 <-- Chamada GUID: 93bfb890-646c-4364-8795-9587bfdc55ba <-- Correlator GUID da Chamada: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 <-- Interno G
Informação 127.0.0.1:35872: Usuário da API "api" criou uma nova chamada 93bfb890-646c-4364-8795-9587bfdc55ba
Informação chamada 7: chamada SIP recebida de "sip:672@172.x.x.x" para URI local "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Informação perna da chamada da API bc0be45e-ce8f-411c-be04-594e0220c38e na chamada 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (chamada da API 93bfb890-646c-4364-8795-9587bfdc55ba)
Informação conferência 434f88d0-8441-41e1-b6ee-6d1c63b5b098 com controle/mídia GUID: fb587c12-23d2-4351-af61-d6365cbd648d
Informação conferência 434f88d0-8441-41e1-b6ee-6d1c63b5b098 nomeada "001036270012"
Informação chamada 7: configurada - perna da chamada da API bc0be45e-ce8f-411c-be04-594e0220c38e com ID de chamada SIP "7e309680-cd217a6a-f237-e88214ac@172.x.x.x"
Informação chamada 7: configurando sessão RTP UDT para DTLS (mídia e controle combinados)
Informação conferência "001036270012": pernas de chamada não criptografadas agora presentes
Informação participante "672@172.x.x.x" juntou-se ao espaço 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Informação participante "672@172.x.x.x" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) uniu-se à conferência 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Informação chamada 8: chamada SIP recebida de "sip:690@172.x.x.x" para URI local "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Informação perna da chamada da API db61b242-1c6f-49bd-8339-091f62f5777a na chamada 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (chamada da API 93bfb890-646c-4364-8795-9587bfdc55ba)
Informação chamada 8: configurada - perna da chamada da API db61b242-1c6f-49bd-8339-091f62f5777a com ID de chamada SIP "7e309680-cd217a6a-f238-e88214ac@172.x.x.x"
Informação chamada 8: configurando sessão RTP UDT para DTLS (mídia e controle combinados)
Informação chamada 9: chamada SIP recebida de "sip:673@172.x.x.x" para URI local "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Informação perna da chamada da API 37a6e86d-d457-47cf-be24-1dbe20ccf98a na chamada 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (chamada da API 93bfb890-646c-4364-8795-9587bfdc55ba)
Informação chamada 9: configurada - perna da chamada da API 37a6e86d-d457-47cf-be24-1dbe20ccf98a com ID de chamada SIP "7e309680-cd217a6a-f239-e88214ac@172.x.x.x"
Informação chamada 9: configurando sessão RTP UDT para DTLS (mídia e controle combinados)
Informação chamada 8: compensando a falta de correspondência dos tipos de payload do lado remoto
Informação participante "690@172.x.x.x" juntou-se ao espaço 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Informação participante "690@172.x.x.x" (289e823d-6da8-486c-a7df-fe177f05e010) uniu-se à conferência 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Informação chamada 7: compensando a falta de correspondência dos tipos de payload do lado remoto
Informação chamada 8: modo de tipos de payload não correspondente 1/0
Informação chamada 8: respondendo à oferta no modo de tipos de payload não correspondente
Informação chamada 8: oferta de codec único recebida como follow-up
Informação chamada 8: modo de tipos de payload não correspondente 1/0
Informação chamada 8: respondendo à oferta no modo de tipos de payload não correspondente
Informação chamada 8: enviando resposta à oferta adicional de codec único
Informação chamada 9: compensando a falta de correspondência dos tipos de payload do lado remoto
Informação participante "673@172.x.x.x" juntou-se ao espaço 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Informação participante "673@172.x.x.x" (d27e9a53-2c8a-4e9c-9363-0415cd812767) uniu-se à conferência 434f88d0-8441-41e1-b6ee-6d1c63b5b098 via SIP
Informação chamada 9: BFCP (função do cliente) agora ativo
Informação chamada 9: enviando BFCP hello como cliente após o recebimento de hello quando BFCP não estava ativo
Informação chamada 9: BFCP (função do cliente) agora ativo
Informação chamada 7: encerrando; desligamento SIP remoto - conectado por 0:13
Informação chamada 7: destruindo perna da chamada da API bc0be45e-ce8f-411c-be04-594e0220c38e
Informação participante "672@x.x.x" deixou o espaço 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Informação chamada 9: em espera
Informação chamada 9: modo de tipos de payload não correspondente 1/0
Informação chamada 9: respondendo à oferta no modo de tipos de payload não correspondente
Informação chamada 8: em espera
Informação chamada 8: oferta de codec único recebida como follow-up
Informação chamada 8: modo de tipos de payload não correspondente 1/0
Informação chamada 8: respondendo à oferta no modo de tipos de payload não correspondente
Informação chamada 8: enviando resposta à oferta adicional de codec único
Informação chamada 9: encerrando; desligamento SIP remoto - conectado por 0:12A própria conferência Ad-Hoc:
Regras de chamadas de entrada
A configuração dos parâmetros de chamadas de entrada é necessária para receber chamadas 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ê vai querer que as chamadas para esse domínio sejam destinadas aos espaços. Você também precisará estabelecer regras para tudo que for destinado ao nome de domínio completo (e, possivelmente, até mesmo para o endereço IP) de cada um dos servidores CMS. Em nosso controle externo de chamadas, o Unified CM, serão configuradas as trilhas SIP, destinadas a cada um dos servidores CMS individualmente. Dependendo se o destino dessas trilhas SIP é um endereço IP ou o nome de domínio completo do servidor, será determinado se o CMS deve ser configurado para receber chamadas direcionadas ao seu endereço IP ou nome de domínio completo.
O domínio que possui a regra de tráfego de entrada com a maior prioridade é utilizado como domínio para quaisquer espaços de usuário. Quando os usuários se sincronizam via LDAP, o CMS cria automaticamente os espaços, mas apenas a parte personalizada da URI (coSpaceUriMapping), por exemplo, user.space. A parte da URI completa é criada com base nessa regra. De fato, se você entrasse no Web Bridge neste momento, veria que a URI do espaço não tem um domínio. Ao definir essa regra como a de maior prioridade, você está definindo o domínio para os espaços gerados como conf.example.com.
Regras de chamadas de saída
Para permitir que os usuários façam chamadas de saída para o cluster Unified CM, é necessário configurar as regras de conexões de saída. O domínio dos endpoints registrados no Unified CM, como Jabber, é example.com. As chamadas para esse domínio devem ser direcionadas como chamadas SIP padrão para os nós de processamento de chamadas do Unified CM. O servidor principal é cucm-01.example.com, e como secundário cucm-02.example.com.
A primeira regra descreve a mais simples roteamento de chamadas entre os servidores do cluster.
Campo Local do domínio responsável pelo que será exibido no SIP-URI do chamador para quem está recebendo a chamada após o símbolo «@». Se o deixarmos em branco, após o símbolo «@» aparecerá o endereço IP do CUCM pelo qual essa chamada passa. Se especificarmos um domínio, então após o símbolo «@» aparecerá o domínio. Isso é necessário para que seja possível retornar a chamada, caso contrário, será impossível retornar pelo SIP-URI nome@endereço-ip.
Chamada quando especificado Local do domínio
Chamada quando NÃO ser listado Local do domínio
É obrigatório especificar explicitamente Encrypted ou Unencrypted para chamadas de saída, pois com a opção Auto nada funcionará.
Gravação
A gravação de videoconferências é feita pelo servidor Record. O Recorder é exatamente o mesmo que o Cisco Meeting Server. O Recorder não requer a instalação de nenhuma licença. Licenças para gravação são necessárias nos servidores onde os serviços CallBridge estão em execução, ou seja, a licença de Gravação é necessária e deve ser aplicada ao componente CallBridge, não ao servidor onde o Recorder está em execução. O Recorder se comporta como um cliente de protocolo de troca de mensagens e presença (XMPP), portanto, o servidor XMPP deve estar ativado no servidor que hospeda o CallBridge.
Como temos um cluster, a licença precisa ser "esticada" para todos os três servidores do cluster. Portanto, basta associar (adicionar) os endereços MAC das interfaces a dos servidores CMS que fazem parte do cluster na área pessoal das licenças.
E esta é a imagem que deve aparecer em cada servidor do cluster
Na verdade, existem vários cenários para a implementação do Recorder, mas vamos seguir este:
Antes de configurar o Recorder, é necessário preparar um local para onde as videoconferências serão gravadas. Aqui está , como configurar toda a gravação. Vou me concentrar nos pontos e detalhes importantes:
1. É melhor fornecer o certificado do primeiro servidor no cluster.
2. O erro «Recorder unavailable» pode ocorrer porque um certificado errado foi especificado no Recorder Trust.
3. A gravação pode não acontecer se um diretório raiz incorreto for especificado no NFS.
Às vezes, há a necessidade de gravar automaticamente a conferência de um usuário ou espaço específico.
Para isso, dois CallProfiles são criados:
Com a função de gravação desativada
E com a função de gravação automática
Em seguida, vinculamos o CallProfile com a função de gravação automática ao espaço desejado.
No CMS, é comum que, se um CallProfile estiver explicitamente vinculado a algum espaço ou espaços, ele funcione apenas para esses espaços específicos. Se o CallProfile não estiver vinculado a nenhum espaço, por padrão, ele se aplica aos espaços aos quais nenhum CallProfile está explicitamente vinculado.
Na próxima vez, tentarei descrever como o acesso ao CMS é realizado fora da rede interna da organização.
Fontes:
Fonte: habr.com
