ProHoster > Blog > Administración > Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Neste número mostrarei e explicarei algunhas das complexidades de configurar un servidor CMS no modo de clúster de conmutación por fallo.
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

TeoríaEn xeral, hai tres tipos de implementación do servidor CMS:

  • Único Combinado(Combinado único), é dicir. este é un servidor no que se están executando todos os servizos necesarios. Na maioría dos casos, este tipo de despregamento só é adecuado para o acceso de clientes internos e en contornos máis pequenos nos que as limitacións de escalabilidade e redundancia dun único servidor non son un problema crítico, ou en situacións nas que o CMS só realiza determinadas funcións, como ad hoc. conferencias sobre Cisco UCM.

    Esquema de traballo aproximado:
    Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

  • Split único(Single Split) amplía o tipo de implantación anterior engadindo un servidor separado para o acceso externo. Nas implantacións antigas, isto significaba implantar un servidor CMS nun segmento de rede desmilitarizado (DMZ) onde os clientes externos podían acceder a el e un servidor CMS no núcleo da rede onde os clientes internos podían acceder ao CMS. Este modelo de implantación en particular está sendo substituído polo chamado tipo Bordo único, que consta de servidores Autoestrada Cisco, que teñen ou terán moitas das capacidades de derivación do Firewall para que os clientes non teñan que engadir un servidor CMS de borde dedicado.

    Esquema de traballo aproximado:
    Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

  • Escalable e Resiliente(Escalable e tolerante a fallos) Este tipo inclúe redundancia para cada compoñente, o que permite que o sistema creza coas súas necesidades ata a súa máxima capacidade mentres proporciona redundancia en caso de fallo. Tamén usa o concepto Single Edge para proporcionar acceso externo seguro. Este é o tipo que veremos neste episodio. Se entendemos como despregar este tipo de clúster, non só entenderemos outro tipo de despregamentos, senón que tamén poderemos entender como crear clústeres de servidores CMS para dar cabida ao crecemento potencial da demanda.

Antes de pasar á implementación, cómpre comprender algunhas cousas básicas, a saber

Principais compoñentes do software CMS:

  • Base de datos: Permítelle combinar algunhas configuracións, como o plan de marcación, os espazos de usuario e os propios usuarios. Só admite a agrupación de clústeres para alta dispoñibilidade (master único).
  • Ponte de chamada: un servizo de audio e videoconferencia que proporciona un control total sobre a xestión e procesamento de chamadas e procesos multimedia. Soporta clustering para alta dispoñibilidade e escalabilidade.
  • Servidor XMPP: responsable do rexistro e autenticación dos clientes mediante a aplicación Cisco Meeting e/ou WebRTC(comunicación en tempo real, ou simplemente no navegador), así como a sinalización intercompoñente. Pódese agrupar só para alta dispoñibilidade.
  • Web Bridge: Proporciona acceso ao cliente a WebRTC.
  • Balanceador de carga: Proporciona un único punto de conexión para Cisco Meeting Apps no modo de división única. Escoita a interface externa e o porto para as conexións entrantes. Igualmente, o equilibrador de carga acepta conexións TLS entrantes do servidor XMPP, a través do cal pode cambiar as conexións TCP de clientes externos.
    No noso escenario non será necesario.
  • Servidor TURN: Ofrece tecnoloxía de derivación do firewall que permite
    coloque o noso CMS detrás dun firewall ou NAT para conectar clientes externos mediante a aplicación Cisco Meeting ou dispositivos SIP. No noso escenario non será necesario.
  • Administrador Web: Interface administrativa e acceso á API, incluso para conferencias especiais de Unified CM.

Modos de configuración

A diferenza da maioría dos outros produtos de Cisco, Cisco Meeting Server admite tres métodos de configuración para acomodar calquera tipo de implantación.

  • Liña de comandos (CLI): Interface de liña de comandos coñecida como MMP para tarefas de configuración inicial e certificado.
  • Administrador web: Principalmente para configuracións relacionadas con CallBridge, especialmente cando se configura un único servidor non agrupado.
  • API REST: Úsase para as tarefas de configuración máis complexas e as tarefas relacionadas con bases de datos agrupadas.

Ademais do anterior, utilízase o protocolo SFTP para transferir ficheiros (normalmente licenzas, certificados ou rexistros) a e dende o servidor CMS.

Nas guías de implementación de Cisco está escrito en branco e inglés que o clúster debe ser implantado polo menos tres servidores (nodos) no contexto das bases de datos. Porque Só cun número impar de nós funcionará o mecanismo para seleccionar un novo Mestre de base de datos e, en xeral, o mestre de base de datos ten unha conexión coa maior parte da base de datos do servidor CMS.

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

E como mostra a práctica, dous servidores (nodos) non son realmente suficientes. O mecanismo de selección funciona cando se reinicia o mestre, o servidor escravo convértese en mestre só despois de que se active o servidor reiniciado. Non obstante, se nun clúster de dous servidores o servidor Mestre se apaga de súpeto, entón o servidor escravo non se converterá no mestre e, se o escravo se apaga, o servidor mestre restante converterase no escravo.

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Pero no contexto de XMPP, realmente sería necesario montar un clúster de tres servidores, porque se, por exemplo, desactiva o servizo XMPP nun dos servidores nos que XMMP está en estado de líder, entón no servidor restante XMPP permanecerá en estado de seguidor e as conexións de CallBridge a XMPP caerán porque CallBridge conéctase exclusivamente a XMPP co estado de líder. E isto é fundamental, porque... non pasará nin unha soa chamada.

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Tamén nas mesmas guías de implantación móstrase un clúster cun servidor XMPP.

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

E tendo en conta o anterior, queda claro por que: funciona porque está en modo de failover.

No noso caso, o servidor XMPP estará presente nos tres nodos.

Suponse que os tres servidores están activados.

Rexistros DNS

Antes de comezar a configurar servidores, cómpre crear rexistros DNS А и SRV tipos:

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Teña en conta que nos nosos rexistros DNS hai dous dominios example.com e conf.exemplo.com. Example.com é un dominio que todos os subscritores de Cisco Unified Communication Manager poden usar para os seus URI, que é moi probable que estea presente na túa infraestrutura ou que poida estar presente. Ou example.com coincide co mesmo dominio que usan os usuarios para os seus enderezos de correo electrónico. Ou o cliente Jabber do teu portátil pode ter un URI [protexido por correo electrónico]. Dominio conf.example.com é o dominio que se configurará para os usuarios de Cisco Meeting Server. O dominio do Cisco Meeting Server será conf.example.com, polo que para o mesmo usuario de Jabber, debería utilizarse o URI user@ para iniciar sesión en Cisco Meeting Serverconf.exemplo.com.

Configuración básica

Todas as configuracións descritas a continuación móstranse nun servidor, pero deben realizarse en cada servidor do clúster.

QoS

Xa que o CMS xera en tempo real tráfico sensible aos atrasos e á perda de paquetes, na maioría dos casos recoméndase configurar a calidade de servizo (QoS). Para conseguilo, o CMS admite etiquetar paquetes cos Códigos de Servizos Diferenciados (DSCP) que xera. Aínda que a priorización do tráfico baseada en DSCP depende de como o procesen os compoñentes de rede da túa infraestrutura, no noso caso configuraremos o noso CMS coa priorización típica de DSCP baseada nas mellores prácticas de QoS.

En cada servidor introduciremos estes comandos

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

Así, todo o tráfico de vídeo foi marcado AF41 (DSCP 0x22), todo o tráfico de voz foi marcado EF (DSCP 0x2E), outros tipos de tráfico de baixa latencia como SIP e XMPP usan AF31 (DSCP 0x1A).

Comprobamos:
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

NTP

O protocolo de tempo de rede (NTP) é importante non só para proporcionar marcas de tempo precisas de chamadas e conferencias, senón tamén para verificar certificados.

Engade servidores NTP á túa infraestrutura cun comando como

ntp server add <server>

No noso caso, hai dous servidores deste tipo, polo que haberá dous equipos.
Comprobamos:
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia
E establece a zona horaria do noso servidor
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

DNS

Engadimos servidores DNS ao CMS cun comando como:

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

No noso caso, hai dous servidores deste tipo, polo que haberá dous equipos.
Comprobamos:
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Configuración da interface de rede

Configuramos a interface cun comando como:

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

Comprobamos:
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Nome do servidor (Hostname)

Establecemos o nome do servidor cun comando como:

hostname <name>

E reiniciamos.
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Isto completa a configuración básica.

Certificados

TeoríaCisco Meeting Server require unha comunicación cifrada entre varios compoñentes e, como resultado, os certificados X.509 son necesarios para todas as implantacións de CMS. Axudan a garantir que outros servidores/servizos confían nos servizos/servidores.

Cada servizo require un certificado, pero crear certificados separados para cada servizo pode provocar confusión e complexidade innecesaria. Afortunadamente, podemos xerar un par de claves pública-privada dun certificado e despois reutilizalos en varios servizos. No noso caso, empregarase o mesmo certificado para Call Bridge, XMPP Server, Web Bridge e Web Admin. Así, cómpre crear un par de claves de certificado públicas e privadas para cada servidor do clúster.

A agrupación de bases de datos, con todo, ten algúns requisitos especiais de certificado e, polo tanto, requiren os seus propios certificados que son diferentes aos dos outros servizos. CMS usa un certificado de servidor, que é semellante aos certificados utilizados por outros servidores, pero tamén hai un certificado de cliente usado para as conexións de bases de datos. Os certificados de bases de datos úsanse tanto para a autenticación como para o cifrado. En lugar de proporcionar un nome de usuario e un contrasinal para que o cliente se conecte á base de datos, presenta un certificado de cliente no que o servidor confía. Cada servidor do clúster de bases de datos utilizará o mesmo par de chaves públicas e privadas. Isto permite que todos os servidores do clúster encripten os datos de forma que só poidan ser descifrados por outros servidores que tamén compartan o mesmo par de claves.

Para que funcione a redundancia, os clústeres de bases de datos deben estar formados por un mínimo de 3 servidores, pero non máis de 5, cun tempo máximo de ida e volta de 200 ms entre calquera membro do clúster. Este límite é máis restritivo que para a agrupación de Call Bridge, polo que adoita ser o factor limitante nos despregamentos distribuídos xeograficamente.

O rol de base de datos para un CMS ten unha serie de requisitos únicos. A diferenza doutros roles, require un certificado de cliente e servidor, onde o certificado de cliente ten un campo CN específico que se presenta ao servidor.

O CMS usa unha base de datos Postgres cun mestre e varias réplicas completamente idénticas. Só hai unha base de datos principal á vez (o "servidor de bases de datos"). Os membros restantes do clúster son réplicas ou "clientes de base de datos".

Un clúster de bases de datos require un certificado de servidor dedicado e un certificado de cliente. Deben estar asinados mediante certificados, normalmente unha autoridade de certificación privada interna. Dado que calquera membro do clúster de bases de datos pode converterse no mestre, os pares de certificados do servidor de base de datos e do cliente (que conteñen as claves públicas e privadas) deben copiarse en todos os servidores para que poidan asumir a identidade do cliente ou do servidor de base de datos. Ademais, debe cargarse o certificado raíz da CA para garantir que se poidan verificar os certificados de cliente e servidor.

Entón, creamos unha solicitude para un certificado que será utilizado por todos os servizos do servidor, excepto a base de datos (haberá unha solicitude separada para isto) cun comando como:

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

En CN escribimos o nome xeral dos nosos servidores. Por exemplo, se os nomes de host dos nosos servidores servidor 01, servidor 02, servidor 03, entón CN será servidor.exemplo.com

Facemos o mesmo nos dous servidores restantes coa diferenza de que os comandos conterán os "nomes de host" correspondentes

Xeramos dúas solicitudes de certificados que serán utilizados polo servizo de base de datos con comandos como:

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

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

pki csr dbclusterclient CN:postgres

onde dbclusterserver и dbclusterclient nomes das nosas solicitudes e futuros certificados, nome de host 1(2)(3) nomes dos servidores correspondentes.

Realizamos este procedemento só nun servidor (!), e cargaremos os certificados e os correspondentes ficheiros .key a outros servidores.

Activa o modo de certificado de cliente en AD CSServidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Tamén cómpre combinar os certificados de cada servidor nun só ficheiro.En *NIX: 

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

En Windows/DOS: 

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

E carga a cada servidor:
1. Certificado de servidor “individual”.
2. Certificado raíz (xunto cos intermedios, se é o caso).
3. Certificados para a base de datos (“servidor” e “cliente”) e ficheiros coa extensión .key, que se xeraron ao crear unha solicitude de certificados de base de datos “servidor” e “cliente”. Estes ficheiros deben ser iguais en todos os servidores.
4. Expediente dos tres certificados “individuais”.

Como resultado, deberías obter algo como esta imaxe de ficheiro en cada servidor.

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Clúster de bases de datos

Agora que tes todos os certificados cargados nos servidores CMS, podes configurar e habilitar a agrupación de bases de datos entre os tres nodos. O primeiro paso é seleccionar un servidor como nodo mestre do clúster de bases de datos e configuralo completamente.

Base de datos mestra

O primeiro paso para configurar a replicación da base de datos é especificar os certificados que se utilizarán para a base de datos. Isto faise usando un comando como:

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

Agora imos dicir ao CMS que interface usar para agrupar bases de datos co comando:

database cluster localnode a

A continuación, inicializamos a base de datos do clúster no servidor principal co comando:

database cluster initialize

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Nodos da base de datos de clientes

Facemos o mesmo procedemento, só en lugar do comando inicialización do clúster de bases de datos introduza un comando como:

database cluster join <ip address existing master>

onde enderezo IP enderezo IP mestre existente do servidor CMS no que se inicializou o clúster, simplemente Master.

Comprobamos como funciona o noso clúster de bases de datos en todos os servidores co comando:

database cluster status

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Facemos o mesmo no terceiro servidor restante.

Como resultado, resulta que o noso primeiro servidor é o Mestre, o resto son escravos.

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Servizo de administración web

Activa o servizo de administrador web:

webadmin listen a 445

Escolleuse o porto 445 porque o porto 443 úsase para o acceso do usuario ao cliente web

Configuramos o servizo Web Admin con ficheiros de certificado cun comando como:

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

E activa o administrador web co comando:

webadmin enable

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Se todo está ben, recibiremos liñas de ÉXITO que indican que Web Admin está configurado correctamente para a rede e o certificado. Comprobamos a funcionalidade do servizo mediante un navegador web e introducimos o enderezo do administrador web, por exemplo: cms.example.com: 445

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Clúster Bridge de chamadas

Call Bridge é o único servizo presente en cada implantación de CMS. Call Bridge é o principal mecanismo de conferencia. Tamén ofrece unha interface SIP para que as chamadas poidan ser encamiñadas a ela ou dende, por exemplo, un Cisco Unified CM.

Os comandos descritos a continuación deben executarse en cada servidor cos certificados axeitados.
Así:

Asociamos certificados ao servizo Call Bridge cun comando como:

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

Vinculamos os servizos de CallBridge á interface que necesitamos co comando:

callbridge listen a

E reinicie o servizo co comando:

callbridge restart

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Agora que temos os nosos Call Bridges configurados, podemos configurar o clustering de Call Bridge. A agrupación de Call Bridge é diferente da agrupación de bases de datos ou XMPP. Call Bridge Cluster pode admitir de 2 a 8 nós sen ningunha restrición. Proporciona non só redundancia, senón tamén equilibrio de carga para que as conferencias se poidan distribuír activamente entre os servidores de Call Bridge mediante a distribución intelixente de chamadas. O CMS ten funcións adicionais, grupos de Call Bridge e funcións relacionadas que se poden usar para unha xestión posterior.

A agrupación da ponte de chamadas configúrase principalmente a través da interface de administración web
O procedemento que se describe a continuación debe realizarse en cada servidor do clúster.
Así,

1. Vaia pola web ata Configuración > Clúster.
2. En Identidade da ponte de chamada Como nome único, introduza callbridge[01,02,03] correspondente ao nome do servidor. Estes nomes son arbitrarios, pero deben ser únicos para este clúster. Son de natureza descritiva porque indican que son identificadores de servidor [01,02,03].
3.B Pontes de chamadas agrupadas introduza os URL do administrador web dos nosos servidores no clúster, cms[01,02,03].example.com:445, no campo Enderezo. Asegúrese de especificar o porto. Podes deixar o dominio SIP de Peer link baleiro.
4. Engade un certificado á confianza de CallBridge de cada servidor, cuxo ficheiro contén todos os certificados dos nosos servidores, que fusionamos neste ficheiro ao principio, cun comando como: 

callbridge trust cluster <trusted cluster certificate bundle>

E reinicie o servizo co comando:

callbridge restart

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Como resultado, en cada servidor deberías obter esta imaxe:
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Clúster XMPP

O servizo XMPP do CMS utilízase para xestionar todo o rexistro e a autenticación de Cisco Meeting Apps (CMA), incluído o cliente web CMA WebRTC. A propia Call Bridge tamén actúa como cliente XMPP para fins de autenticación e, polo tanto, debe configurarse como outros clientes. A tolerancia a fallos de XMPP é unha característica que se admite en ambientes de produción desde a versión 2.1

Os comandos descritos a continuación deben executarse en cada servidor cos certificados axeitados.
Así:

Asociamos certificados co servizo XMPP cun comando como:

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

A continuación, define a interface de escoita co comando:

xmpp listen a

O servizo XMPP require un dominio único. Este é o inicio de sesión dos usuarios. Noutras palabras, cando un usuario tenta iniciar sesión usando a aplicación CMA (ou a través do cliente WebRTC), introduce userID@logindomain. No noso caso será userid@conf.exemplo.com. Por que non é só example.com? Na nosa implementación particular, seleccionamos o noso dominio de Unified CM que os usuarios de Jabber usarán en Unified CM como example.com, polo que necesitabamos un dominio diferente para que os usuarios de CMS encamiñasen as chamadas cara e dende o CMS a través de dominios SIP.

Configura un dominio XMPP usando un comando como:

xmpp domain <domain>

E activa o servizo XMPP co comando:

xmpp enable

No servizo XMPP, debes crear credenciais para cada Call Bridge que se utilizarán ao rexistrarte no servizo XMPP. Estes nomes son arbitrarios (e non están relacionados cos nomes únicos que configuraches para a agrupación de pontes de chamadas). Debe engadir tres pontes de chamada nun servidor XMPP e, a continuación, introducir esas credenciais noutros servidores XMPP do clúster porque esta configuración non encaixa na base de datos do clúster. Máis adiante configuraremos cada Call Bridge para que use este nome e segredo para rexistrarse no servizo XMPP.

Agora necesitamos configurar o servizo XMPP no primeiro servidor con tres Call Bridges callbridge01, callbridge02 e callbridge03. A cada conta asignaranse contrasinais aleatorios. Posteriormente introduciranse noutros servidores de Call Bridge para iniciar sesión neste servidor XMPP. Introduza os seguintes comandos:

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

Como resultado, comprobamos o que pasou co comando:

xmpp callbridge list

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia
A mesma imaxe debería aparecer nos servidores restantes despois dos pasos descritos a continuación.

A continuación, engadimos exactamente a mesma configuración nos dous servidores restantes, só cos comandos

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

Engadimos Secret con moito coidado para que, por exemplo, non haxa espazos adicionais nel.
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Como resultado, cada servidor debería ter a mesma imaxe:

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

A continuación, en todos os servidores do clúster, especificamos en confianza o ficheiro que contén os tres certificados, creado anteriormente cun comando como este:

xmpp cluster trust <trust bundle>

Activamos o modo de clúster xmpp en todos os servidores de clúster co comando:

xmpp cluster enable

No primeiro servidor do clúster, iniciamos a creación dun clúster xmpp co comando:

xmpp cluster initialize

Noutros servidores, engade un clúster a xmpp cun comando como:

xmpp cluster join <ip address head xmpp server>

Comprobamos en cada servidor o éxito de crear un clúster XMPP en cada servidor cos comandos:

xmpp status
xmpp cluster status

Primeiro servidor:
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia
Segundo servidor:
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia
Terceiro servidor:
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Conectando Call Bridge a XMPP

Agora que se está a executar o clúster XMPP, cómpre configurar os servizos Call Bridge para conectarse ao clúster XMPP. Esta configuración realízase a través do administrador web.

En cada servidor, vai a Configuración > Xeral e no campo Nome único Call Bridge escribir nomes únicos correspondentes ao servidor Call Bridge ponte de chamada[01,02,03]... En campo Dominio conf.example.ru e contrasinais correspondentes, podes espiarlos
en calquera servidor do clúster co comando:

xmpp callbridge list

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Deixe o campo "Servidor" baleiro Ponte ponte realizará unha busca de DNS SRV _xmpp-component._tcp.conf.example.compara atopar un servidor XMPP dispoñible. Os enderezos IP para conectar callbridges a XMPP poden diferir en cada servidor, depende dos valores que se devolvan á solicitude de rexistro _xmpp-component._tcp.conf.example.com callbridge, que á súa vez depende da configuración de prioridade para un determinado rexistro DNS.

A continuación, vai a Estado > Xeral para verificar se o servizo Call Bride está conectado correctamente ao servizo XMPP.

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Web Bridge

En cada servidor do clúster, active o servizo Web Bridge co comando:

webbridge listen a:443

Configuramos o servizo Web Bridge con ficheiros de certificado cun comando como:

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

Web Bridge admite HTTPS. Redirixirá HTTP a HTTPS se está configurado para usar "http-redirect".
Para activar a redirección HTTP, use o seguinte comando:

webbridge http-redirect enable

Para que Call Bridge saiba que Web Bridge pode confiar nas conexións de Call Bridge, use o comando:

webbridge trust <certfile>

onde este é un ficheiro que contén os tres certificados de cada servidor do clúster.

Esta imaxe debería estar en todos os servidores do clúster.
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Agora necesitamos crear un usuario co rol de “appadmin”, necesitámolo para poder configurar o noso clúster(!), e non cada servidor do clúster por separado, deste xeito a configuración aplicarase por igual a cada servidor a pesar do feito de que se farán unha vez.
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Para máis configuración imos usar Carteiro.

Para a autorización, seleccione Básica na sección Autorización

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Para enviar comandos correctamente ao servidor CMS, cómpre establecer a codificación necesaria

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Especificamos Webbridge co comando POST con parámetro url e significado cms.example.com

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Na propia webbridge indicamos os parámetros necesarios: acceso de convidado, acceso protexido, etc.

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Chamar a grupos Bridge

Por defecto, o CMS non sempre fai o uso máis eficiente dos recursos de conferencia dispoñibles.

Por exemplo, para unha reunión con tres participantes, cada participante pode acabar en tres Call Bridges diferentes. Para que estes tres participantes se comuniquen entre si, Call Bridges establecerá automaticamente conexións entre todos os servidores e clientes no mesmo espazo, de xeito que pareza que todos os clientes estivesen no mesmo servidor. Desafortunadamente, a desvantaxe é que unha única conferencia de 3 persoas consumirá agora 9 portos multimedia. Este é, obviamente, un uso ineficiente dos recursos. Ademais, cando un Call Bridge está realmente sobrecargado, o mecanismo predeterminado é seguir aceptando chamadas e proporcionar un servizo de calidade reducida a todos os subscritores desa Call Bridge.

Estes problemas resólvense mediante a función Call Bridge Group. Esta función introduciuse na versión 2.1 do software Cisco Meeting Server e ampliouse para admitir o equilibrio de carga para chamadas entrantes e saíntes de Cisco Meeting App (CMA), incluídos os participantes de WebRTC.

Para resolver o problema de reconexión, introducíronse tres límites de carga configurables para cada Call Bridge:

Límite de carga — esta é a carga numérica máxima para un Call Bridge particular. Cada plataforma ten un límite de carga recomendado, como 96000 para o CMS1000 e 1.25 GHz por vCPU para a máquina virtual. As diferentes chamadas consomen unha certa cantidade de recursos dependendo da resolución e frecuencia de fotogramas do participante.
NovosConferenceLoadLimitBasisPoints (Límite de carga 50 % predeterminado): establece o límite de carga do servidor, despois do cal as novas conferencias son rexeitadas.
ExistingConferenceLoadLimitBasisPoints (80 % predeterminado de loadLimit) - o valor de carga do servidor despois do cal os participantes que se unan a unha conferencia existente serán rexeitados.

Aínda que esta función foi deseñada para a distribución de chamadas e o equilibrio de carga, outros grupos, como os servidores TURN, os servidores Web Bridge e os gravadores, tamén se poden asignar aos grupos Call Bridge para que tamén se poidan agrupar correctamente para un uso óptimo. Se algún destes obxectos non está asignado a un grupo de chamadas, suponse que está dispoñible para todos os servidores sen ningunha prioridade particular.

Estes parámetros están configurados aquí: cms.example.com:445/api/v1/system/configuration/cluster

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

A continuación, indicamos a cada callbridge a que grupo de callbridge pertence:

Primeiro callbridge
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia
Segundo callbridge
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia
Terceiro callbridge
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Así, configuramos o grupo Call Brdige para utilizar de forma máis eficiente os recursos do clúster de Cisco Meeting Server.

Importación de usuarios desde Active Directory

O servizo Web Admin ten unha sección de configuración LDAP, pero non ofrece opcións de configuración complexas, e a información non se almacena na base de datos do clúster, polo que a configuración terá que facerse, ben manualmente en cada servidor a través da interface web, ou ben mediante a API, e para que "tres veces" "Non te levantes" seguiremos configurando os datos a través da API.

Usando o URL para acceder cms01.example.com:445/api/v1/ldapServers crea un obxecto Servidor LDAP, especificando parámetros como:

  • IP do servidor
  • número de porto
  • Nome de usuario
  • contrasinal
  • protexer

Seguro: seleccione verdadeiro ou falso dependendo do porto, 389 - non seguro, 636 - protexido.
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Asignación de parámetros de orixe LDAP a atributos en Cisco Meeting Server.
A asignación LDAP asigna os atributos do directorio LDAP aos atributos do CMS. Atributos reais:

  • jidMapping
  • NameMapping
  • CoSpaceNameMapping
  • coSpaceUriMapping
  • coSpaceSecondaryUriMapping

Descrición de atributosBID representa o ID de inicio de sesión do usuario no CMS. Dado que este é un servidor LDAP de Microsoft Active Directory, o CMS JID mapea ao sAMAccountName en LDAP, que é esencialmente o ID de inicio de sesión do Active Directory do usuario. Ten en conta tamén que tomas sAMAccountName e engades o dominio conf.pod6.cms.lab ao final porque este é o inicio de sesión que usarán os teus usuarios para iniciar sesión no CMS.

NameMapping fai coincidir o contido no campo displayName de Active Directory co campo de nome CMS do usuario.

CoSpaceNameMapping crea un nome de espazo CMS baseado no campo displayName. Este atributo, xunto co atributo coSpaceUriMapping, é o necesario para crear un espazo para cada usuario.

coSpaceUriMapping define a parte do usuario do URI asociado ao espazo persoal do usuario. Algúns dominios pódense configurar para que se marquen no espazo. Se a parte do usuario coincide con este campo para un destes dominios, a chamada dirixirase ao espazo dese usuario.

coSpaceSecondaryUriMapping define un segundo URI para chegar ao espazo. Isto pódese usar para engadir un alias numérico para enrutar chamadas ao espazo do usuario importado como alternativa ao URI alfanumérico definido no parámetro coSpaceUriMapping.

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

O servidor LDAP e a asignación LDAP están configurados. Agora cómpre vinculalos creando unha fonte LDAP.

Usando o URL para acceder cms01.example.com:445/api/v1/ldapSource crea un obxecto de orixe LDAP, especificando parámetros como:

  • servidor
  • mapeamento
  • baseDn
  • filtrar

Agora que se completa a configuración de LDAP, pode realizar a operación de sincronización manual.

Facemos isto ou ben na interface web de cada servidor facendo clic Sincroniza agora No capítulo Active Directory
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

ou a través da API co comando POST usando URL para acceder cms01.example.com:445/api/v1/ldapSyncs

Conferencias ad-hoc

¿Que é iso?No concepto tradicional, unha conferencia é cando dous participantes están falando entre si, e un dos participantes (usando un dispositivo rexistrado en Unified CM) preme o botón "Conferencia", chama á outra persoa e despois de falar con ese terceiro. , preme de novo o botón "Conferencia" para unirse a todos os participantes na conferencia tripartita.

O que distingue unha conferencia Ad-Hoc dunha conferencia programada nun CMS é que unha conferencia Ad-Hoc non é só unha chamada SIP ao CMS. Cando o iniciador da conferencia fai clic no botón Conferencia unha segunda vez para invitar a todos á mesma reunión, Unified CM debe facer unha chamada API ao CMS para crear unha conferencia en tempo real á que despois se transfiran todas as chamadas. Todo isto pasa desapercibido para os participantes.

Isto significa que Unified CM debe configurar as credenciais da API e o enderezo/porto de WebAdmin do servizo, así como o tronco SIP directamente ao servidor CMS para continuar a chamada.

Se é necesario, CUCM pode crear dinámicamente un espazo no CMS para que cada chamada poida chegar ao CMS e coincidir coa regra de chamada entrante que se destina aos espazos.

Integración con CUCM configurado do mesmo xeito que se describe no artigo antes excepto que en Cisco UCM cómpre crear tres troncos para o CMS, tres pontes de conferencia, no perfil de seguranza SIP especifique tres nomes de asuntos, grupos de rutas, listas de rutas, grupos de recursos multimedia e listas de grupos de recursos multimedia e engade algunhas regras de enrutamento. a Cisco Meeting Server.

Perfil de seguridade SIP:
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Troncos:
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Cada tronco ten o mesmo aspecto:
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Ponte de conferencias
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Cada ponte de conferencias ten o mesmo aspecto:
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Grupo de Rutas
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Lista de rutas
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Grupo de recursos multimedia
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Lista de grupos de recursos multimedia
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Regras de convocatoria

A diferenza dos sistemas de xestión de chamadas máis avanzados, como Unified CM ou Expressway, CMS só busca o dominio no campo SIP Request-URI para novas chamadas. Entón, se SIP INVITE é para sip: [protexido por correo electrónico]O CMS só se preocupa por domain.com. CMS segue estas regras para determinar onde dirixir unha chamada:

1. O CMS tenta primeiro facer coincidir o dominio SIP cos dominios configurados nas regras de chamadas entrantes. Estas chamadas poden ser encamiñadas a espazos ("orientados") ou usuarios específicos, IVR internos ou destinos integrados directamente de Microsoft Lync/Skype for Business (S4B).
2. Se non hai ningunha coincidencia nas regras de chamadas entrantes, CMS tentará coincidir co dominio configurado na táboa de reenvío de chamadas. Se se fai unha coincidencia, a regra pode rexeitar explícitamente a chamada ou reenviar a chamada. Neste momento, o CMS pode reescribir o dominio, o que ás veces é útil para chamar a dominios de Lync. Tamén podes optar por pasar o lanzamento, o que significa que ningún dos campos se modificará aínda máis, ou usar un plan de marcación CMS interno. Se non hai ningunha coincidencia nas regras de desvío de chamadas, o predeterminado é rexeitar a chamada. Teña en conta que no CMS, aínda que a chamada está "reenviada", o medio segue ligado ao CMS, o que significa que estará na ruta de sinalización e tráfico de medios.
Entón, só as chamadas reenviadas están suxeitas ás regras de chamadas saíntes. Esta configuración determina os destinos onde se envían as chamadas, o tipo de troncal (se é unha nova chamada de Lync ou unha chamada SIP estándar) e as conversións que se poidan realizar se a transferencia non está seleccionada na regra de reenvío de chamadas.

Aquí tes o rexistro real do que acontece durante unha conferencia Ad-Hoc

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

A captura de pantalla móstrao mal (non sei como facelo mellor), así que escribirei o rexistro así:

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 propia conferencia Ad-Hoc:
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Regras de chamadas entrantes
É necesario configurar os parámetros das chamadas entrantes para poder recibir unha chamada no CMS. Como viches na configuración de LDAP, todos os usuarios foron importados co dominio conf.pod6.cms.lab. Entón, como mínimo, queres que as chamadas a este dominio teñan como destino espazos. Tamén terás que configurar regras para todo o que estea destinado ao nome de dominio totalmente cualificado (e quizais mesmo ao enderezo IP) de cada un dos servidores CMS. O noso control de chamadas externos, Unified CM, configurará troncais SIP dedicados a cada un dos servidores CMS individualmente. Dependendo de se o destino destes troncos SIP é un enderezo IP ou o FQDN do servidor determinará se o CMS debe configurarse para aceptar chamadas dirixidas ao seu enderezo IP ou FQDN.

O dominio que ten a regra de entrada de maior prioridade úsase como dominio para calquera espazo de usuario. Cando os usuarios se sincronizan mediante LDAP, o CMS crea espazos automaticamente, pero só a parte do usuario do URI (coSpaceUriMapping), por exemplo, user.space. Parte dominio O URI completo xérase en función desta regra. De feito, se tiveses que iniciar sesión en Web Bridge neste momento, verías que o URI de espazo non ten un dominio. Ao establecer esta regra como a prioridade máis alta, está a especificar o dominio para os espazos xerados como conf.exemplo.com.
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Regras de chamadas saíntes

Para permitir que os usuarios fagan chamadas de saída ao clúster de Unified CM, debes configurar regras de saída. O dominio dos extremos rexistrados con Unified CM, como Jabber, é example.com. As chamadas a este dominio deben dirixirse como chamadas SIP estándar aos nodos de procesamento de chamadas de Unified CM. O servidor principal é cucm-01.example.com e o servidor adicional é cucm-02.example.com.

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia
A primeira regra describe o enrutamento máis sinxelo de chamadas entre servidores de clúster.

Campo Local do dominio é responsable do que se mostrará no SIP-URI da persoa que chama despois do símbolo "@". Se o deixamos baleiro, despois do símbolo "@" aparecerá o enderezo IP do CUCM polo que pasa esta chamada. Se especificamos un dominio, despois do símbolo "@" haberá un dominio. Isto é necesario para poder devolver a chamada, se non, non será posible devolver a chamada mediante SIP-URI nome@ip-address.

Chamar cando se indique Local do dominio
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Chama cando NON indicado Local do dominio
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Asegúrate de especificar de forma explícita Cifrado ou Non cifrado para as chamadas saíntes, porque nada funciona co parámetro Auto.

Gravación

As videoconferencias son gravadas polo servidor de gravación. O gravador é exactamente o mesmo que o servidor de reunións de Cisco. O gravador non require a instalación de ningunha licenza. As licenzas de gravación son necesarias para os servidores que executan servizos CallBridge, é dicir. requírese unha licenza de gravación que debe aplicarse ao compoñente CallBridge e non ao servidor que executa o gravador. A gravadora compórtase como un cliente XMPP (Extensible Messaging and Presence Protocol), polo que o servidor XMPP debe estar activado no servidor que aloxa CallBridge.

Porque Temos un clúster e hai que "estirar" a licenza nos tres servidores do clúster. Despois simplemente na súa conta persoal nas licenzas asociamos (engadimos) os enderezos MAC das interfaces a de todos os servidores CMS incluídos no clúster.

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

E esta é a imaxe que debería estar en todos os servidores do clúster

Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

En xeral, hai varios escenarios para colocar o gravador, pero seguirémonos neste:
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

Antes de configurar a gravadora, cómpre preparar un lugar onde se gravarán as videoconferencias. En realidade aquí Ligazón, como configurar todas as gravacións. Concéntrome en puntos e detalles importantes:

1. É mellor deslizar o certificado do primeiro servidor do clúster.
2. O erro "Grabadora non dispoñible" pode ocorrer porque o certificado incorrecto está especificado na confianza do gravador.
3. É posible que a escritura non funcione se o directorio NFS especificado para gravar non é o directorio raíz.

Ás veces é necesario gravar automaticamente unha conferencia dun usuario ou espazo específico.

Para iso, créanse dous CallProfiles:
Coa gravación desactivada
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

E con función de gravación automática
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

A continuación, "anexamos" un CallProfile cunha función de gravación automática ao espazo desexado.
Servidor de reunións de Cisco 2.5.2. Clúster en modo escalable e resistente con función de gravación de videoconferencia

En CMS é tan habitual que se un perfil de chamada está ligado explícitamente a calquera espazo ou espazo, entón este perfil de chamada só funciona en relación con estes espazos específicos. E se o CallProfile non está ligado a ningún espazo, entón por defecto aplícase a aqueles espazos aos que ningún CallProfile está ligado explícitamente.

A próxima vez tentarei describir como se accede ao CMS fóra da rede interna da organización.

Fontes:

Fonte: www.habr.com

Engadir un comentario