En esta entrega, mostraré y explicaré algunos detalles sobre la configuración del servidor CMS en modo de clúster de alta disponibilidad.
TeoríaExisten tres tipos de despliegue del servidor CMS:
- Single Combined(Combinado Único), es decir, un solo servidor en el que se ejecutan todos los servicios necesarios. Este tipo de despliegue generalmente se aplica solo para el acceso de clientes internos y en entornos pequeños, donde las limitaciones de escalabilidad y redundancia de un solo servidor no son un problema crítico, o en situaciones donde el CMS solo realiza ciertas funciones, como conferencias especiales en Cisco UCM.
Diagrama de funcionamiento aproximado:
- Single Split(Dividido Único) amplía el tipo de despliegue anterior, agregando un servidor separado para acceso externo. En antigüedades, esto significaba desplegar el servidor CMS en la zona desmilitarizada (DMZ), donde los clientes externos podían acceder, y un servidor CMS en el núcleo de la red, donde los clientes internos acceden al CMS. Este modelo específico de despliegue ahora está siendo reemplazado por el tipo llamado Single Edge, que consiste en servidores Cisco Expressway, que tienen o tendrán muchas de las capacidades de eludir el Firewall, por lo que los clientes no necesitan agregar un servidor de frontera dedicado para el CMS.
Diagrama de funcionamiento aproximado:
- Escalable y Resiliente(Este tipo incluye redundancia para cada componente, lo que permite que el sistema crezca con sus necesidades hasta alcanzar la máxima capacidad, asegurando al mismo tiempo redundancia en caso de fallos. También utiliza el concepto de Single Edge para asegurar un acceso externo seguro. Este es el tipo que abordaremos en esta entrega. Al entender cómo desplegar un clúster de este tipo, no solo comprenderemos otros tipos de despliegue, sino que también podremos entender cómo crear clústeres de servidores CMS teniendo en cuenta el crecimiento potencial de las necesidades.
Antes de proceder con el despliegue, es importante entender algunas cuestiones básicas, a saber,
Componentes de software principales del CMS:
- Base de datos: permite combinar algunas configuraciones, como grupos de abonados, espacios de usuarios y los mismos usuarios. Soporta clustering solo para alta disponibilidad (un maestro).
- Puente de Llamadas: servicio para conferencias de audio y video, que proporciona control total sobre la gestión y procesamiento de llamadas y procesos multimedia. Soporta clustering para alta disponibilidad y escalabilidad.
- Servidor XMPP: se encarga del registro y autenticación de los clientes que utilizan la aplicación Cisco Meeting Application y/o WebRTC (comunicación en tiempo real, o simplemente en el navegador), así como la señalización entre componentes. Puede ser clusterizado solo para alta disponibilidad.
- Puente Web: proporciona acceso a los clientes en WebRTC.
- Balanceador de Carga: asegura un único punto de conexión para las aplicaciones Cisco Meeting App en modo Single Split. Escucha la interfaz y puerto externos para conexiones entrantes. Igualmente, el balanceador de carga acepta conexiones TLS entrantes desde el servidor XMPP, a través del cual puede redirigir conexiones TCP de clientes externos.
En nuestro escenario no será necesario. - Servidor TURN: proporciona tecnología para sortear firewall, permitiendo
exponer nuestro CMS fuera del firewall o NAT para conectar clientes externos que utilizan la aplicación Cisco Meeting App o dispositivos SIP. En nuestro escenario no será necesario. - Administrador Web: interfaz administrativa y acceso a la API, incluyendo para conferencias especiales de Unified CM.
Modos de Configuración
A diferencia de la mayoría de otros productos de Cisco, Cisco Meeting Server soporta tres métodos de configuración, permitiendo desplegar cualquier tipo de despliegue.
- Línea de Comandos (CLI): interfaz de línea de comandos, conocida como MMP, para tareas de configuración inicial y certificados.
- Administrador Web: principalmente para configuraciones relacionadas con CallBridge, especialmente al configurar un solo servidor no clusterizado.
- REST API: se utiliza para las tareas de configuración más complejas y tareas relacionadas con la base de datos cluster.
Además de lo anterior, se utiliza un protocolo SFTP para la transferencia de archivos — generalmente licencias, certificados o registros — hacia y desde el servidor CMS.
En las guías de implementación de Cisco se indica claramente que el clúster debe ser desplegado como mínimo de tres servidores (nodos) en el contexto de bases de datos. Dado que solo funciona con un número impar de nodos, el mecanismo para seleccionar un nuevo Maestro de la base de datos solamente se activará, y todo el Maestro de la base de datos tiene relación con la mayor parte de la base de datos del servidor CMS.
Y como muestra la práctica, dos servidores (nodos) realmente no son suficientes. El mecanismo de selección se activa al reiniciar el Maestro, el servidor Esclavo se convierte en Maestro únicamente después de reiniciar el servidor. Sin embargo, si en un clúster de dos servidores el servidor Maestro se 'apaga', el servidor Esclavo no se convertirá en Maestro, y si el Esclavo se 'apaga', el servidor Maestro restante se convierte también en Esclavo.
En el contexto de XMPP, realmente es necesario formar un clúster de tres servidores, ya que si, por ejemplo, se desactiva el servicio XMPP en uno de los servidores que tiene el estado de Líder, el servidor restante permanecerá en el estado de Seguidor y las conexiones de CallBridge a XMPP se perderán, ya que CallBridge solo se conecta a XMPP en estado de Líder. Esto es crítico, ya que no se podrá realizar ninguna llamada.
También en estas guías de implementación se muestra un clúster con un solo servidor XMPP.
Y considerando lo anterior, se entiende por qué: funciona porque en modo de failover.
En nuestro caso, el servidor XMPP estará presente en los tres nodos.
Se asume que nuestros tres servidores están activos.
Registros DNS
Antes de comenzar a configurar los servidores, es necesario crear los registros DNS. A y SRV tipos:
Tenga en cuenta que en nuestros registros DNS hay dos dominios example.com y conf.example.com. Example.com es el dominio que todos los abonados de Cisco Unified Communication Manager pueden usar para sus URI, el cual probablemente ya esté presente en su infraestructura o tenga una alta probabilidad de estarlo. O el dominio example.com se corresponde con el mismo dominio que los usuarios utilizan para sus direcciones de correo electrónico. O el cliente Jabber en su ordenador portátil puede tener la URI user@example.com. El dominio conf.example.com es el que se configurará para los usuarios del Cisco Meeting Server. El dominio del Cisco Meeting Server será conf.example.com, por lo que para que el mismo usuario Jabber inicie sesión en el Cisco Meeting Server, deberá usar la URI user@conf.example.com.
Configuración básica
Todas las configuraciones descritas a continuación se muestran en un solo servidor, pero deben realizarse en cada servidor del clúster.
QoS
Dado que CMS genera tiempo real El tráfico sensible a la latencia y la pérdida de paquetes generalmente se recomienda para la configuración de la calidad del servicio (QoS). Para esto, el CMS admite el etiquetado de paquetes con códigos de servicios diferenciados (DSCP) que genera. Aunque la priorización del tráfico basada en DSCP depende de cómo los componentes de red de su infraestructura procesan el tráfico, en nuestro caso configuraremos nuestro CMS con una distribución típica de prioridades DSCP basada en las mejores prácticas de QoS.
Introduciremos estos comandos en cada servidor
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1ADe esta manera, todo el tráfico de video se etiquetó como AF41 (DSCP 0x22), todo el tráfico de voz se etiquetó como EF (DSCP 0x2E), otros tipos de tráfico con baja latencia, como SIP y XMPP, utilizan AF31 (DSCP 0x1A).
Verificando:
NTP
El Protocolo de Tiempo de Red (NTP) es importante no solo para proporcionar marcas de tiempo precisas de llamadas y conferencias, sino también para la verificación de certificados.
Agregamos servidores NTP a su infraestructura con el comando de tipo
ntp server add En nuestro caso, hay dos de estos servidores, por lo que habrá dos comandos.
Verificando:
Y establecemos la zona horaria para nuestro servidor
DNS
Los servidores DNS en CMS se agregan con el comando de tipo:
dns add forwardzone En nuestro caso, hay dos de estos servidores, por lo que habrá dos comandos.
Verificando:
Configuración de la interfaz de red
Configuramos la interfaz con el comando de tipo:
ipv4 add / Verificando:
Nombre del servidor (Hostname)
Establecemos el nombre del servidor con el comando de tipo:
hostname Y reiniciamos.
Con esto, ha finalizado la configuración básica.
Los certificados
TeoríaCisco Meeting Server requiere comunicación encriptada entre los distintos componentes, y como resultado, los certificados X.509 son necesarios para todas las implementaciones de CMS. Ayudan a garantizar la confianza en los servicios/servidores por parte de otros servidores/servicios.
Se requiere un certificado para cada servicio; sin embargo, la creación de certificados separados para cada servicio puede causar confusión y complicaciones innecesarias. Afortunadamente, podemos generar un par de claves de certificado públicas y privadas y luego reutilizarlas para varios servicios. En nuestro caso, el mismo certificado se utilizará para el Call Bridge, el servidor XMPP, el Web Bridge y el Web Admin. Por lo tanto, es necesario crear un par de claves de certificado públicas y privadas para cada servidor en el clúster.
La clusterización de bases de datos tiene algunos requisitos especiales para los certificados y, por lo tanto, requiere sus propios certificados, distintos de los certificados de otros servicios. El CMS utiliza un certificado de servidor, que es similar a los certificados utilizados por otros servidores, pero también hay un certificado de cliente, utilizado para las conexiones a la base de datos. Los certificados de bases de datos se utilizan tanto para la autenticación como para el cifrado. En lugar de proporcionar un nombre de usuario y una contraseña para conectar el cliente a la base de datos, se presenta un certificado de cliente en el que confía el servidor. Cada servidor en el clúster de bases de datos utilizará el mismo par de claves pública y privada. Esto permite que todos los servidores en el clúster cifren los datos de manera que solo puedan ser descifrados por otros servidores que también utilicen el mismo par de claves.
Para que la redundancia funcione, los clústeres de bases de datos deben constar de al menos 3 servidores, pero no más de 5, con un tiempo máximo de propagación de 200 ms en ambas direcciones entre cualquier miembro del clúster. Este límite es más restrictivo que la clusterización de Call Bridge, por lo que a menudo es un factor limitante en implementaciones geográficamente distribuidas.
El rol de la base de datos para el CMS tiene una serie de requisitos únicos. A diferencia de otros roles, requiere un certificado de cliente y un certificado de servidor, donde el certificado de cliente tiene un campo CN específico que se presenta al servidor.
El CMS utiliza una base de datos postgres con un maestro y varios réplicas completamente idénticas. En cada momento hay solo una base de datos principal ("servidor de base de datos"). Los otros miembros del clúster son réplicas o "clientes de base de datos".
Para un clúster de base de datos se requieren el certificado de servidor dedicado y el certificado del cliente. Estos deben estar firmados por los certificados, generalmente de un centro de certificación privado interno. Dado que cualquiera de los miembros del clúster de base de datos puede convertirse en principal, los pares de certificados del servidor de base de datos y del cliente (que contienen claves públicas y privadas) deben ser copiados en todos los servidores para que puedan aceptar la identidad del cliente o del servidor de base de datos. Además, el certificado raíz del CA debe ser cargado para garantizar que los certificados del cliente y del servidor puedan ser verificados.
Así que, generamos una solicitud para el certificado que será utilizado por todos los servicios del servidor, excepto database (para esto habrá una solicitud separada) con el comando del tipo:
pki csr hostname CN:cms.example.com subjectAltName:hostname.example.com,example.com,conf.example.com,join.example.com
En CN escribimos el nombre general de nuestros servidores. Por ejemplo, si los hostname de nuestros servidores server01, server02, server03, entonces CN será server.example.com
Hacemos lo mismo en los otros dos servidores con la diferencia de que en los comandos estarán los correspondientes «hostname»
Generamos dos solicitudes para los certificados que serán usados por el servicio database con comandos del tipo:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgresdonde dbclusterserver y dbclusterclient nombres de nuestras solicitudes y futuros certificados, hostname1(2)(3) nombres de los servidores correspondientes.
Este procedimiento lo realizamos solo en un servidor(!), y cargaremos los certificados y los archivos .key correspondientes en los otros servidores.
Activar el modo de certificado de cliente en AD CS
También necesitamos combinar en un solo archivo los certificados para cada servidorEn *NIX:
cat server01.cer server02.cer server03.cer > server.cerEn Windows/DOS:
copy server01.cer + server02.cer + server03.cer server.cer Y cargar en cada servidor:
1. El certificado «individual» del servidor.
2. Certificado raíz (junto con los intermedios si los hay).
3. Certificados para la base de datos («servidor» y «cliente») y los archivos con extensión .key, que se formaron al crear la solicitud para el certificado «servidor» y «cliente» de la base de datos. Estos archivos deben ser los mismos en todos los servidores.
4. Archivo de todos los tres certificados «individuales».
Al final, debería resultar un panorama de archivos similar en cada servidor.
Clúster de Base de Datos
Ahora que tiene todos los certificados cargados en los servidores CMS, puede configurar e iniciar la agrupación de bases de datos entre tres nodos. El primer paso es elegir un servidor como nodo principal de la agrupación de bases de datos y configurarlo completamente.
Base de Datos Principal
El primer paso para configurar la replicación de la base de datos es especificar los certificados que se usarán para la base de datos. Esto se hace con un comando del tipo:
database cluster certsAhora indicamos a la CMS qué interfaz utilizar para la agrupación de bases de datos con el comando:
database cluster localnode aLuego inicializamos la base de datos de la agrupación en el servidor principal con el comando:
database cluster initialize
Nodos de Base de Datos del Cliente
Realizamos el mismo procedimiento, solo que en lugar de usar un comando database cluster initialize introducimos un comando del tipo:
database cluster joindonde ip address existing master es la dirección IP del servidor CMS en el que se inicializó la agrupación, es decir, el Master.
Verificamos cómo funciona nuestra agrupación de bases de datos en todos los servidores con el comando:
database cluster status
Hacemos lo mismo en el tercer servidor restante.
Así que nuestro primer servidor es el Master, mientras que los demás son Slaves.
Servicio de Administrador Web
Activamos el servicio de administrador web:
webadmin listen a 445Se eligió el puerto 445 porque el puerto 443 se utiliza para el acceso de usuarios al cliente web.
Configuramos el servicio de Administrador Web con los archivos de certificados usando un comando del tipo:
webadmin certsY activamos el Administrador Web con el comando:
webadmin enable 
Si todo está bien, obtendremos líneas de ÉXITO que indican que el Administrador Web está correctamente configurado para la red y el certificado. Probamos el funcionamiento del servicio a través de un navegador web e ingresamos la dirección del administrador web, por ejemplo: :445
Agrupación del Puente de Llamadas
El Puente de Llamadas es el único servicio presente en cada implementación de CMS. El Puente de Llamadas es el principal mecanismo de comunicación en conferencias. También proporciona una interfaz SIP, de modo que las llamadas pueden ser enrutadas hacia él o desde él, por ejemplo, con Cisco Unified CM.
Los comandos descritos a continuación deben ejecutarse en cada servidor con los certificados correspondientes.
Así que:
Vinculamos los certificados al servicio de Puente de Llamadas con el comando del tipo:
callbridge certs []Asignamos los servicios CallBridge a la interfaz que necesitamos con el comando:
callbridge listen aY reiniciamos el servicio con el comando:
callbridge restart 
Ahora que hemos configurado los Call Bridges, podemos configurar la agrupación de Call Bridge. La agrupación de Call Bridge es diferente de la agrupación de bases de datos o XMPP. Un Clúster de Call Bridge puede soportar de 2 a 8 nodos sin restricciones. Proporciona no solo redundancia, sino también distribución de carga, lo que permite que las conferencias se distribuyan activamente entre los servidores Call Bridge mediante una distribución de llamadas inteligente. CMS tiene características adicionales, grupos de Call Bridge y funciones relacionadas que se pueden utilizar para una gestión adicional.
La agrupación de Call Bridge se configura principalmente a través de la interfaz de administración web.
El procedimiento descrito a continuación debe llevarse a cabo en cada servidor del clúster.
Así que,
1. Ingrese a través de la web en Configuration > Cluster.
2. En Call Bridge identity ingrese un nombre único como callbridge[01,02,03] correspondiente al nombre del servidor. Estos nombres son arbitrarios, pero deben ser únicos para este clúster. Son descriptivos, ya que indican que son las identificaciones de los servidores [01,02,03].
3. En Clustered Call Bridges ingrese las direcciones URL del administrador web de nuestros servidores en el clúster, [01,02,03].example.com:445, en el campo Address. Asegúrese de incluir el puerto. Puede dejar el campo Peer link SIP domain vacío.
4. Agregue el certificado de confianza de CallBridge de cada servidor, cuyo archivo contiene todos los certificados de nuestros servidores que fusionamos en este archivo al principio, con un comando del tipo:
callbridge trust clusterY reiniciamos el servicio con el comando:
callbridge restart 
Como resultado, cada servidor debería tener un aspecto como este:
XMPP Cluster
El servicio XMPP en CMS se utiliza para manejar todo el registro y la autenticación para Cisco Meeting Apps (CMA), incluyendo el cliente web CMA WebRTC. El Call Bridge también actúa como un cliente XMPP para fines de autenticación y, por lo tanto, debe ser configurado como otros clientes. La resistencia a fallos de XMPP es una función que se admite en entornos de producción a partir de la versión 2.1.
Los comandos descritos a continuación deben ejecutarse en cada servidor con los certificados correspondientes.
Así que:
Asocie los certificados con el servicio XMPP con un comando del tipo:
xmpp certs []Luego, defina la interfaz de escucha con el comando:
xmpp listen aPara el servicio XMPP se requiere un dominio único. Este es el identificador para los usuarios. En otras palabras, cuando un usuario intenta iniciar sesión a través de la aplicación CMA (o mediante un cliente WebRTC), introduce userID@logindomain. En nuestro caso será userid@conf.example.com. ¿Por qué no simplemente example.com? En nuestra implementación específica elegimos nuestro dominio Unified CM, que los usuarios de Jabber usarán en Unified CM, como example.com, por lo tanto necesitamos otro dominio para los usuarios de CMS, para enrutar llamadas hacia y desde CMS a través de los dominios SIP.
Configura el dominio XMPP utilizando un comando del tipo:
xmpp domainY habilitamos el servicio XMPP con el comando:
xmpp enableEn el servicio XMPP es necesario crear credenciales para cada Call Bridge que se utilizarán al registrarse en el servicio XMPP. Estos nombres son arbitrarios (y no están relacionados con los nombres únicos que configuraste para la agrupación de puentes de llamadas). En un servidor XMPP es necesario agregar tres puentes de llamadas, y luego ingresar estas credenciales en otros servidores XMPP en el clúster, ya que esta configuración no se almacena en la base de datos del clúster. Más tarde configuraremos cada Call Bridge para usar este nombre y secreto para registrarse en el servicio XMPP.
Ahora necesitamos configurar el servicio XMPP en el primer servidor con tres Call Bridges callbridge01, callbridge02 y callbridge03. A cada cuenta se le asignarán contraseñas aleatorias. Más tarde se ingresarán en otros servidores Call Bridge para iniciar sesión en este servidor XMPP. Ingresamos los siguientes comandos:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03Al final verificamos lo que obtuvimos con el comando:
xmpp callbridge list 
Debería verse exactamente igual en los demás servidores después de las acciones descritas a continuación.
A continuación, agregamos en los otros dos servidores exactamente las mismas configuraciones, solo con los comandos
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Agregamos el secreto con mucho cuidado, para no incluir accidentalmente espacios adicionales, por ejemplo.
Al final, en cada servidor debe haber la misma imagen:
Luego, en todos los servidores del clúster, especificamos en la confianza el archivo que contiene los tres certificados, creado anteriormente con un comando del tipo:
xmpp cluster trustActivamos el modo de clúster xmpp en todos los servidores del clúster con el comando:
xmpp cluster enableEn el primer servidor del clúster, iniciamos la creación del clúster XMPP con el comando:
xmpp cluster initializeEn los demás servidores, añadimos al clúster XMPP con un comando del tipo:
xmpp cluster joinVerificamos la creación exitosa del clúster XMPP en cada servidor con los comandos:
xmpp status
xmpp cluster statusPrimer servidor:
Segundo servidor:
Tercer servidor:
Conectando Call Bridge a XMPP
Ahora que el clúster XMPP está en funcionamiento, es necesario configurar los servicios de Call Bridge para conectarse al clúster XMPP. Esta configuración se realiza a través del administrador web.
Entramos en cada servidor en Configuration > General y en el campo Unique Call Bridge name escribimos nombres únicos de Call Bridge correspondientes a cada servidor callbridge[01,02,03]. En el campo Dominio conf.example.ru y las contraseñas correspondientes, se pueden ver
en cualquier servidor del clúster con el comando:
xmpp callbridge list 
El campo 'Servidor' lo dejamos vacío, Callbridge realizará una búsqueda DNS SRV para _xmpp-component._tcp.conf.example.com, para encontrar un servidor XMPP disponible. Las direcciones IP con las que se conectan los Callbridges a XMPP pueden variar en cada servidor, dependiendo de los valores que se devuelven en la consulta de la entrada _xmpp-component._tcp.conf.example.com al Callbridge, lo que a su vez depende de la configuración de prioridades para esa entrada DNS.
A continuación, pasamos a Status > General, para asegurarnos de que el servicio Call Bride está correctamente conectado al servicio XMPP.
Puente Web
En cada servidor del clúster, activamos el servicio Web Bridge con el comando:
webbridge listen a:443Configuramos el servicio Web Bridge con los archivos de certificado utilizando un comando del tipo:
webbridge certsWeb Bridge soporta HTTPS. Redirigirá HTTP a HTTPS si está configurado para usar 'http-redirect'.
Para habilitar la redirección HTTP, utilice el siguiente comando:
webbridge http-redirect enablePara indicar al Call Bridge que el Web Bridge puede confiar en las conexiones del Call Bridge, utilice el comando:
webbridge trustdonde este es el archivo que contiene los tres certificados de cada servidor en el clúster.
Esta imagen debe ser igual en cada servidor del clúster.
Ahora necesitamos crear un usuario con el rol de 'appadmin', que necesitamos para poder configurar nuestro clúster(!), y no cada servidor del clúster por separado, de este modo, la configuración se aplicará de manera uniforme en cada servidor, haciéndola una sola vez.
Para la configuración adicional, utilizaremos .
Para la autorización, seleccionamos Basic en la sección Autorization
Para enviar correctamente comandos a los servidores CMS, es necesario establecer la codificación adecuada.
Especificamos los Webbridges con el comando. POST con el parámetro url y el valor
En el propio webbridge, debemos especificar los parámetros necesarios: acceso de invitado, acceso protegido, entre otros.
Call Bridge Groups
Por defecto, el CMS no siempre aprovecha al máximo los recursos de conferencia disponibles.
Por ejemplo, para una reunión con tres participantes, cada uno puede estar en tres Call Bridges diferentes. Para que estos tres participantes puedan comunicarse entre sí, los Call Bridges establecerán automáticamente conexiones entre todos los servidores y clientes en el mismo Space, de modo que parezca que todos los clientes están en un mismo servidor. Lamentablemente, el inconveniente de esto es que una conferencia de 3 personas ahora consumirá 9 puertos de medios. Esto, evidentemente, es un uso ineficiente de los recursos. Además, cuando un Call Bridge está realmente sobrecargado, el mecanismo por defecto es seguir aceptando llamadas y proporcionar servicios con calidad reducida a todos los abonados de ese Call Bridge.
Estos problemas se resuelven con la función Call Bridge Group. Esta función fue introducida en la versión 2.1 del software Cisco Meeting Server y se amplió para soportar el balanceo de carga para llamadas entrantes y salientes, así como la Cisco Meeting App (CMA), incluyendo participantes de WebRTC.
Para abordar el problema de la reconexión, se introdujeron tres límites de carga configurables para cada Call Bridge:
LoadLimit — este es el límite de carga numérica máxima para un Call Bridge específico. Cada plataforma tiene un límite de carga recomendado, por ejemplo, 96000 para CMS1000 y 1.25 GHz en un procesador virtual para una máquina virtual. Diferentes llamadas consumen cierta cantidad de recursos dependiendo de la resolución y la tasa de cuadros del participante.
NewConferenceLoadLimitBasisPoints (por defecto 50% loadLimit) — establece el límite de carga del servidor, después del cual se rechazan nuevas conferencias.
ExistingConferenceLoadLimitBasisPoints (por defecto 80% de loadLimit) — el valor de carga del servidor, después del cual los participantes que se unen a una conferencia existente serán rechazados.
Mientras esta función fue diseñada para distribuir las llamadas y balancear la carga, otros grupos, como los servidores TURN, servidores Web Bridge y dispositivos de grabación, también pueden ser asignados a los grupos de Call Bridge, de modo que también puedan agruparse correctamente para un uso óptimo. Si alguno de estos objetos no está asignado a un grupo de llamadas, se supone que están disponibles para todos los servidores sin ningún tipo de prioridad definida.
Estos parámetros se configuran aquí: :445/api/v1/system/configuration/cluster
A continuación, indicamos a cada callbridge a qué grupo de callbridge pertenece:
Primer callbridge
Segundo callbridge
Tercer callbridge
De este modo, hemos configurado un grupo de Call Bridge para un uso más eficiente de los recursos del clúster del Cisco Meeting Server.
Importar usuarios desde Active Directory
El servicio Web Admin tiene una sección de configuración LDAP, pero no proporciona opciones de configuración complejas, y la información no se guarda en la base de datos del clúster, por lo que la configuración deberá realizarse manualmente en cada servidor a través de la interfaz web o mediante API, y para que no tengamos que 'levantarnos tres veces', configuraremos los datos a través de la API.
Usando la URL para acceder :445/api/v1/ldapServers creamos un objeto LDAP Server, especificando parámetros como:
- IP del servidor
- número de puerto
- nombre de usuario
- contraseña
- seguro
Seguro — seleccionamos true o false dependiendo del puerto, 389 — no seguro, 636 — seguro.
Mapeamos los parámetros LDAP fuente a atributos en el Cisco Meeting Server.
El mapeo LDAP asocia los atributos en el directorio LDAP con los atributos en CMS. Los atributos son:
- jidMapping
- nameMapping
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Descripción de los atributosJID representa el identificador de inicio de sesión del usuario en CMS. Dado que este es un servidor LDAP de Microsoft Active Directory, el JID de CMS se mapea con sAMAccountName en LDAP, que es esencialmente el identificador de inicio de sesión del usuario en Active Directory. Además, tenga en cuenta que toma sAMAccountName y agrega el dominio conf.pod6.cms.lab al final, porque este es el inicio de sesión que sus usuarios utilizarán para ingresar a CMS.
nameMapping mapea lo que se contiene en el campo displayName de Active Directory con el campo del nombre del usuario en CMS.
coSpaceNameMapping crea el nombre del espacio de CMS basado en el campo displayName. Este atributo junto con el atributo coSpaceUriMapping son lo que se necesita para crear un espacio para cada usuario.
coSpaceUriMapping define la parte del URI asociada con el espacio personal del usuario. Algunos dominios pueden estar configurados para establecer en el espacio. Si la parte personalizada coincide con este campo para uno de esos dominios, la llamada se dirigirá al espacio de ese usuario.
coSpaceSecondaryUriMapping define un segundo URI para alcanzar el espacio. Esto puede usarse para agregar un seudónimo numérico para enrutar llamadas al espacio de un usuario importado como alternativa al URI alfanumérico definido en el parámetro coSpaceUriMapping.
El servidor LDAP y el mapeo LDAP están configurados. Ahora se requiere vincularlos creando una fuente LDAP.
Usando la URL para acceder :445/api/v1/ldapSource creamos el objeto LDAP Source, especificando parámetros como:
- servidor
- mapeo
- baseDn
- filtro
Ahora que la configuración de LDAP está completa, se puede realizar la operación de sincronización manual.
Hacemos esto ya sea en la interfaz web de cada servidor presionando Sincronizar ahora en la sección Active Directory
o a través de la API usando el comando POST utilizando la dirección URL para acceder :445/api/v1/ldapSyncs
Conferencias Ad-Hoc
¿Qué es esto?En el sentido tradicional, una conferencia es cuando dos participantes hablan entre sí, y uno de los participantes (usando un dispositivo registrado en Unified CM) presiona el botón 'Conferencia', llama a otra persona y después de hablar con ese tercer lado presiona nuevamente el botón 'Conferencia' para unirse a todos los participantes de la conferencia tripartita.
La conferencia Ad-Hoc se distingue de la conferencia programada en CMS porque la conferencia Ad-Hoc no es simplemente una llamada SIP a CMS. Cuando el iniciador de la conferencia presiona el botón 'Conferencia' por segunda vez para invitar a todos a la misma reunión, Unified CM debe realizar una llamada API a CMS para crear la conferencia 'al vuelo', a la que luego se envían todas las llamadas. Todo esto ocurre sin que los participantes lo noten.
Esto significa que Unified CM debe configurar las credenciales API y la dirección/puerto del servicio WebAdmin, así como el SIP-Trunk directamente en el servidor CMS para continuar la llamada.
Si es necesario, CUCM puede crear dinámicamente un espacio en CMS, para que cada llamada pueda llegar a CMS y cumplir con la regla de llamadas entrantes destinada a los espacios.
Integración con CUCM se configura de la misma manera que se describe en el artículo excepto que en Cisco UCM se deben crear tres troncales para CMS, tres Conference Bridge, especificar tres Subject Name en el SIP Security Profile, Route Group, Route List, Media Resource Group y Media Resource Group List; además, en Cisco Meeting Server se deben añadir algunas reglas de enrutamiento.
SIP Security Profile:
Troncales:
Cada troncal se ve igual:
Conference Bridge
Cada Conference Bridge se ve igual:
Route Group
Route List
Media Resource Group
Media Resource Group List
Reglas de llamadas
A diferencia de sistemas de gestión de llamadas más avanzados como Unified CM o Expressway, para nuevas llamadas CMS solo analiza el dominio en el campo SIP Request-URI. Así que, si SIP INVITE está destinado a sip: user@domain.com, CMS solo se preocupa por domain.com. CMS sigue estas reglas para determinar a dónde dirigir la llamada:
1. Primero, CMS intenta hacer coincidir el dominio SIP con los dominios configurados en las reglas de manejo de llamadas entrantes. Luego, estas llamadas se pueden dirigir a los espacios (‘destinados’) o a usuarios específicos, IVRs internos, o destinatarios integrados directamente de Microsoft Lync/Skype for Business (S4B).
2. Si no hay coincidencias en las reglas de manejo de llamadas entrantes, CMS intentará hacer coincidir el dominio configurado en la tabla de reenvío de llamadas. Si se establece una coincidencia, la regla puede rechazar explícitamente la llamada o reenviarla. En este momento, CMS puede reescribir el dominio, lo cual a veces es útil para llamadas a dominios de Lync. También puede optar por pass through, lo que significa que ninguno de los campos se modificará adicionalmente, o usar el grupo de abonados interno de CMS. Si no hay coincidencias en las reglas de reenvío de llamadas, por defecto se utilizará el rechazo de la llamada. Tenga en cuenta que en CMS, aunque la llamada esté 'reenviada', los medios siguen unidos a CMS, lo que significa que estará en la ruta de señalización y tráfico multimedia.
Sólo las llamadas redirigidas se someten a las reglas de llamadas salientes. Estos parámetros definen los destinatarios a los que se enviarán las llamadas, el tipo de línea de conexión (ya sea una nueva llamada de Lync o SIP estándar) y cualquier transformación que pueda realizarse si la regla de redirección de llamadas no selecciona la transferencia.
Este es el registro de lo que ocurre durante la conferencia Ad-Hoc
En la captura de pantalla se ve mal (no sé cómo hacerlo mejor), así que escribiré el registro así:
Info 127.0.0.1:35870: El usuario API "api" creó un nuevo espacio 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info fallo de llamada de creación para encontrar coSpace -- intentando recuperar de la base de datos
Info API "001036270012" GUID del espacio: 7986bb6c-af4e-488d-9190-a75f16844e44 GUID de llamada: 93bfb890-646c-4364-8795-9587bfdc55ba GUID del correlador de llamada: 844a3c9c-8a1e-4568-bbc3-8a0cab5aed66 G interno
Info 127.0.0.1:35872: El usuario API "api" creó una nueva llamada 93bfb890-646c-4364-8795-9587bfdc55ba
Info llamada 7: llamada SIP entrante de "sip:672@172.x.x.x" a URI local "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Info pierna de llamada API bc0be45e-ce8f-411c-be04-594e0220c38e en la llamada 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (llamada API 93bfb890-646c-4364-8795-9587bfdc55ba)
Info la conferencia 434f88d0-8441-41e1-b6ee-6d1c63b5b098 tiene control/media GUID: fb587c12-23d2-4351-af61-d6365cbd648d
Info la conferencia 434f88d0-8441-41e1-b6ee-6d1c63b5b098 nombrada "001036270012"
Info llamada 7: configurada - pierna de llamada API bc0be45e-ce8f-411c-be04-594e0220c38e con ID de llamada SIP "7e309680-cd217a6a-f237-e88214ac@172.x.x.x"
Info llamada 7: configurando sesión UDT RTP para DTLS (media y control combinados)
Info conferencia "001036270012": ahora presentes piernas de llamada no encriptadas
Info participante "672@172.x.x.x" se unió al espacio 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info participante "672@172.x.x.x" (e8371f75-fb9e-4019-91ab-77665f6d8cc3) se unió a la conferencia 434f88d0-8441-41e1-b6ee-6d1c63b5b098 a través de SIP
Info llamada 8: llamada SIP entrante de "sip:690@172.x.x.x" a URI local "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Info pierna de llamada API db61b242-1c6f-49bd-8339-091f62f5777a en la llamada 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (llamada API 93bfb890-646c-4364-8795-9587bfdc55ba)
Info llamada 8: configurada - pierna de llamada API db61b242-1c6f-49bd-8339-091f62f5777a con ID de llamada SIP "7e309680-cd217a6a-f238-e88214ac@172.x.x.x"
Info llamada 8: configurando sesión UDT RTP para DTLS (media y control combinados)
Info llamada 9: llamada SIP entrante de "sip:673@172.x.x.x" a URI local "sip:001036270012@cms01.example.com:5060" / "sip:001036270012@cms01.example.com"
Info pierna de llamada API 37a6e86d-d457-47cf-be24-1dbe20ccf98a en la llamada 434f88d0-8441-41e1-b6ee-6d1c63b5b098 (llamada API 93bfb890-646c-4364-8795-9587bfdc55ba)
Info llamada 9: configurada - pierna de llamada API 37a6e86d-d457-47cf-be24-1dbe20ccf98a con ID de llamada SIP "7e309680-cd217a6a-f239-e88214ac@172.x.x.x"
Info llamada 9: configurando sesión UDT RTP para DTLS (media y control combinados)
Info llamada 8: compensando por tipos de carga no coincidentes del extremo lejano
Info participante "690@172.x.x.x" se unió al espacio 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info participante "690@172.x.x.x" (289e823d-6da8-486c-a7df-fe177f05e010) se unió a la conferencia 434f88d0-8441-41e1-b6ee-6d1c63b5b098 a través de SIP
Info llamada 7: compensando por tipos de carga no coincidentes del extremo lejano
Info llamada 8: modo de tipos de carga no coincidentes 1/0
Info llamada 8: respondiendo a la oferta en modo de tipos de carga no coincidentes
Info llamada 8: oferta de un solo códec de seguimiento recibida
Info llamada 8: modo de tipos de carga no coincidentes 1/0
Info llamada 8: respondiendo a la oferta en modo de tipos de carga no coincidentes
Info llamada 8: enviando respuesta a la oferta adicional de un solo códec
Info llamada 9: compensando por tipos de carga no coincidentes del extremo lejano
Info participante "673@172.x.x.x" se unió al espacio 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info participante "673@172.x.x.x" (d27e9a53-2c8a-4e9c-9363-0415cd812767) se unió a la conferencia 434f88d0-8441-41e1-b6ee-6d1c63b5b098 a través de SIP
Info llamada 9: BFCP (rol del cliente) ahora activo
Info llamada 9: enviando saludo BFCP como cliente tras recibir saludo cuando BFCP no estaba activo
Info llamada 9: BFCP (rol del cliente) ahora activo
Info llamada 7: finalizando; desconexión SIP remota - conectada durante 0:13
Info llamada 7: destruyendo pierna de llamada API bc0be45e-ce8f-411c-be04-594e0220c38e
Info participante "672@x.x.x" salió del espacio 7986bb6c-af4e-488d-9190-a75f16844e44 (001036270012)
Info llamada 9: en espera
Info llamada 9: modo de tipos de carga no coincidentes 1/0
Info llamada 9: respondiendo a la oferta en modo de tipos de carga no coincidentes
Info llamada 8: en espera
Info llamada 8: oferta de un solo códec de seguimiento recibida
Info llamada 8: modo de tipos de carga no coincidentes 1/0
Info llamada 8: respondiendo a la oferta en modo de tipos de carga no coincidentes
Info llamada 8: enviando respuesta a la oferta adicional de un solo códec
Info llamada 9: finalizando; desconexión SIP remota - conectada durante 0:12La conferencia Ad-Hoc:
Reglas de llamadas entrantes
La configuración de los parámetros de llamadas entrantes es necesaria para poder recibir la llamada en CMS. Como habías visto en la configuración de LDAP, todos los usuarios fueron importados con el dominio conf.pod6.cms.lab. Por lo tanto, al menos, querrás que las llamadas a este dominio estén destinadas a los espacios. También necesitarás establecer reglas para todo lo que esté destinado al nombre de dominio completo (y, quizás, incluso para la dirección IP) de cada uno de los servidores CMS. En nuestro control de llamadas externo, Unified CM, se configurarán troncales SIP, destinadas a cada uno de los servidores CMS de forma individual. Dependiendo de si la asignación de estas troncales SIP es una dirección IP o el nombre de dominio completo del servidor, se definirá si se debe configurar CMS para recibir llamadas dirigidas a su dirección IP o al nombre de dominio completo.
El dominio que tenga la regla de tráfico entrante más alta se utiliza como dominio para cualquier space de usuario. Cuando los usuarios se sincronizan a través de LDAP, CMS crea automáticamente spaces, pero solo la parte de usuario del URI (coSpaceUriMapping), por ejemplo, user.space. La parte del URI completo se crea en base a esta regla. De hecho, si hubieras ingresado a Web Bridge en esta etapa, habrías visto que el Space URI no tiene dominio. Al establecer esta regla como la de mayor prioridad, estás definiendo el dominio para los spaces generados como conf.example.com.
Reglas de llamadas salientes
Para permitir que los usuarios realicen llamadas salientes en el clúster de Unified CM, es necesario configurar las reglas de conexiones salientes. El dominio de los puntos finales registrados en Unified CM, como Jabber, es example.com. Las llamadas a este dominio deben ser dirigidas como llamadas SIP estándar a los nodos de procesamiento de llamadas de Unified CM. El principal es el servidor cucm-01.example.com, y como adicional cucm-02.example.com.
La primera regla describe la más simple ruta de llamadas entre los servidores del clúster.
Campo Local desde el dominio se encarga de lo que se mostrará en el SIP-URI del llamante para quien recibe la llamada después del símbolo «@». Si lo dejamos vacío, después del símbolo «@» aparecerá la dirección IP del CUCM a través del cual pasa esta llamada. Si especificamos un dominio, entonces después del símbolo «@» aparecerá el dominio. Esto es necesario para poder devolver la llamada, de lo contrario, no será posible devolver la llamada al SIP-URI nombre@dirección-IP.
Llamada cuando se especifica Local desde el dominio
Llamada cuando NO especificado Local desde el dominio
Es obligatorio especificar explícitamente Encriptado o No Encriptado, será para las llamadas salientes, por lo que con el parámetro Auto nada funcionará.
Grabación
La grabación de videoconferencias se realiza mediante el servidor de grabación. El Recorder es exactamente el mismo Cisco Meeting Server. No requiere la instalación de ninguna licencia. Las licencias para la grabación son necesarias para los servidores que ejecutan los servicios de CallBridge, es decir, la licencia de grabación es necesaria y debe aplicarse al componente CallBridge, no al servidor donde se ejecuta el Recorder. El Recorder se comporta como un cliente del protocolo ampliado de intercambio de mensajes y presencia (XMPP), por lo que el servidor XMPP debe estar habilitado en el servidor donde se aloja CallBridge.
Dado que tenemos un clúster y la licencia necesita ser «extendida» a los tres servidores del clúster, simplemente asociamos (agregamos) las direcciones MAC de las interfaces a de todos los servidores CMS que forman parte del clúster en el panel personal.
Y esta es la imagen que debe aparecer en cada servidor del clúster
En general, hay varios escenarios para la colocación del Recorder, pero nos adheriremos a este:
Antes de configurar el Recorder, se debe preparar el espacio donde se grabarán las videoconferencias. Este es , cómo configurar toda la grabación. Me centraré en los aspectos y detalles importantes:
1. Es mejor proporcionar el certificado del primer servidor en el clúster.
2. El error «Recorder unavailable» puede ocurrir porque el certificado especificado en el Recorder Trust no es el correcto.
3. La grabación puede no realizarse si no se especifica el directorio raíz para la grabación en NFS.
A veces es necesario grabar automáticamente la conferencia de un usuario o espacio específico.
Para ello, se crean dos CallProfiles:
Con la función de grabación desactivada
Y con la función de grabación automática activada
Luego, «adjuntamos» el CallProfile con la función de grabación automática al espacio necesario.
En CMS, se establece que si un CallProfile está claramente vinculado a ciertos espacios, entonces ese CallProfile solo funciona para esos espacios específicos. Si el CallProfile no está vinculado a ningún espacio, por defecto se aplica a los espacios a los que no está vinculado explícitamente ningún CallProfile.
La próxima vez intentaré describir las formas en que se accede a la CMS desde fuera de la red interna de la organización.
Fuentes:
Fuente: habr.com
