En este número mostraré y explicaré algunas de las complejidades de configurar un servidor CMS en modo de clúster de conmutación por error.
ТеорияEn general, existen tres tipos de implementación de servidores CMS:
- Individual Combinado(Único combinado), es decir este es un servidor en el que se ejecutan todos los servicios necesarios. En la mayoría de los casos, este tipo de implementación solo es adecuado para el acceso de clientes internos y en entornos más 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 ad hoc. conferencias sobre Cisco UCM.
Esquema de trabajo aproximado:
- División única(División única) amplía el tipo de implementación anterior agregando un servidor independiente para acceso externo. En implementaciones heredadas, esto significaba implementar un servidor CMS en un segmento de red desmilitarizada (DMZ) donde los clientes externos podían acceder a él, y un servidor CMS en el núcleo de la red donde los clientes internos podían acceder al CMS. Este modelo de implementación particular está siendo reemplazado ahora por el llamado tipo Borde único, que consta de servidores Autopista Cisco, que tienen o tendrán muchas de las mismas capacidades de omisión de firewall para que los clientes no necesiten agregar un servidor CMS perimetral dedicado.
Esquema de trabajo aproximado:
- Escalable y resistente(Escalable y tolerante a fallas) Este tipo incluye redundancia para cada componente, lo que permite que el sistema crezca con sus necesidades hasta su capacidad máxima y, al mismo tiempo, proporciona redundancia en caso de falla. También utiliza el concepto Single Edge para proporcionar acceso externo seguro. Este es el tipo que veremos en este episodio. Si entendemos cómo implementar este tipo de clúster, no solo entenderemos otros tipos de implementaciones, sino que también podremos entender cómo crear clústeres de servidores CMS para adaptarse al crecimiento potencial de la demanda.
Antes de pasar a la implementación, es necesario comprender algunas cosas básicas, a saber
Principales componentes del software CMS:
- Base de datos: Le permite combinar algunas configuraciones, como el plan de marcado, los espacios de usuario y los propios usuarios. Admite agrupación en clústeres para alta disponibilidad (maestro único).
- Puente de llamada: un servicio de audio y videoconferencia que proporciona control total sobre la gestión y procesamiento de llamadas y procesos multimedia. Admite agrupación en clústeres para alta disponibilidad y escalabilidad.
- Servidor XMPP: responsable del registro y autenticación de clientes que utilizan la aplicación Cisco Meeting y/o WebRTC (comunicación en tiempo real, o simplemente en el navegador), así como señalización entre componentes. Se puede agrupar únicamente para alta disponibilidad.
- Puente web: Proporciona acceso de cliente a WebRTC.
- equilibrador de carga: Proporciona un único punto de conexión para Cisco Meeting Apps en modo de división única. Escucha la interfaz externa y el puerto para conexiones entrantes. Del mismo modo, el equilibrador de carga acepta conexiones TLS entrantes desde el servidor XMPP, a través del cual puede cambiar conexiones TCP desde clientes externos.
En nuestro escenario no será necesario. - servidor de turnos: Proporciona tecnología de derivación de firewall que permite
Coloque nuestro CMS detrás de un Firewall o NAT para conectar clientes externos mediante la aplicación Cisco Meeting o dispositivos SIP. En nuestro escenario no será necesario. - Administrador web: Interfaz administrativa y acceso API, incluso para conferencias especiales de Unified CM.
Modos de configuración
A diferencia de la mayoría de los demás productos de Cisco, Cisco Meeting Server admite tres métodos de configuración para adaptarse a cualquier tipo de implementación.
- Línea de comando (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 cuando se configura un único servidor no agrupado.
- REST API: Se utiliza para las tareas de configuración más complejas y tareas relacionadas con bases de datos agrupadas.
Además de lo anterior, se utiliza el protocolo. SFTP para transferir archivos (normalmente licencias, certificados o registros) hacia y desde el servidor CMS.
En las guías de implementación de Cisco está escrito en blanco e inglés que es necesario implementar el clúster. Al menos tres servidores (nodos) en el contexto de bases de datos. Porque Sólo con un número impar de nodos funcionará el mecanismo para seleccionar un nuevo Maestro de Base de Datos y, en general, el Maestro de Base de Datos tiene conexió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 funciona cuando se reinicia el servidor Maestro, el servidor Esclavo se convierte en Maestro sólo después de que se activa el servidor reiniciado. Sin embargo, si en un grupo de dos servidores el servidor Maestro se apaga repentinamente, entonces el servidor Esclavo no se convertirá en Maestro, y si el Servidor Esclavo se apaga, entonces el servidor Maestro restante se convertirá en Esclavo.
Pero en el contexto de XMPP, realmente sería necesario montar un grupo de tres servidores, porque Si, por ejemplo, desactiva el servicio XMPP en uno de los servidores en los que XMMP está en estado Líder, entonces en el servidor restante XMPP permanecerá en estado Seguidor y las conexiones CallBridge a XMPP se interrumpirán, porque CallBridge se conecta exclusivamente a XMPP con estado Líder. Y esto es fundamental, porque... No se realizará ni una sola llamada.
También en las mismas guías de implementación se demuestra un clúster con un servidor XMPP.
Y teniendo en cuenta lo anterior, queda claro por qué: funciona porque está en modo de conmutación por error.
En nuestro caso, el servidor XMPP estará presente en los tres nodos.
Se supone que nuestros tres servidores están funcionando.
registros DNS
Antes de comenzar a configurar servidores, debe crear registros DNS А и SRV tipos:
Tenga en cuenta que en nuestros registros DNS hay dos dominios: ejemplo.com y conf.ejemplo.com. Ejemplo.com es un dominio que todos los suscriptores de Cisco Unified Communication Manager pueden usar para sus URI, que probablemente esté presente en su infraestructura o que probablemente esté presente. O ejemplo.com coincide con el mismo dominio que los usuarios utilizan para sus direcciones de correo electrónico. O el cliente Jabber de su computadora portátil puede tener un URI [email protected]. Dominio conf.example.com es el dominio que se configurará para los usuarios de Cisco Meeting Server. El dominio de Cisco Meeting Server será conf.example.com, por lo que para el mismo usuario de Jabber, se deberá utilizar el URI usuario@ para iniciar sesión en Cisco Meeting Server.conf.ejemplo.com.
Configuracion basica
Todas las configuraciones que se describen a continuación se muestran en un servidor, pero deben realizarse en cada servidor del clúster.
QoS
Dado que el CMS genera en tiempo real tráfico sensible a retrasos y pérdida de paquetes, en la mayoría de los casos se recomienda configurar la calidad de servicio (QoS). Para lograr esto, el CMS admite el etiquetado de paquetes con los códigos de servicios diferenciados (DSCP) que genera. Aunque la priorización del tráfico basada en DSCP depende de cómo lo procesan los componentes de red de su infraestructura, en nuestro caso configuraremos nuestro CMS con una priorización DSCP típica basada en las mejores prácticas de QoS.
En cada servidor ingresaremos estos comandos.
dscp 4 multimedia 0x22
dscp 4 multimedia-streaming 0x22
dscp 4 voice 0x2E
dscp 4 signaling 0x1A
dscp 4 low-latency 0x1APor lo tanto, todo el tráfico de video se marcó AF41 (DSCP 0x22), todo el tráfico de voz se marcó EF (DSCP 0x2E), otros tipos de tráfico de baja latencia como SIP y XMPP usan AF31 (DSCP 0x1A).
Comprobamos:
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 verificar certificados.
Agregue servidores NTP a su infraestructura con un comando como
ntp server add <server>
En nuestro caso, hay dos servidores de este tipo, por lo que habrá dos equipos.
Comprobamos:
Y establecer la zona horaria para nuestro servidor.
DNS
Agregamos servidores DNS al CMS con un comando como:
dns add forwardzone <domain-name> <server ip>
En nuestro caso, hay dos servidores de este tipo, por lo que habrá dos equipos.
Comprobamos:
Configuración de la interfaz de red
Configuramos la interfaz con un comando como:
ipv4 <interface> add <address>/<prefix length> <gateway>
Comprobamos:
Nombre del servidor (nombre de host)
Configuramos el nombre del servidor con un comando como:
hostname <name>
Y reiniciamos.
Esto completa la configuración básica.
Certificados
ТеорияCisco Meeting Server requiere comunicación cifrada entre varios componentes y, como resultado, se requieren certificados X.509 para todas las implementaciones de CMS. Ayudan a garantizar que otros servidores/servicios confíen en los servicios/servidor.
Cada servicio requiere un certificado, pero la creación de certificados separados para cada servicio puede generar confusión y complejidad innecesaria. Afortunadamente, podemos generar un par de claves pública-privada de un certificado y luego reutilizarlas en múltiples servicios. En nuestro caso, se utilizará el mismo certificado para Call Bridge, XMPP Server, Web Bridge y Web Admin. Por lo tanto, debe crear un par de claves de certificado públicas y privadas para cada servidor del clúster.
Sin embargo, la agrupación de bases de datos tiene algunos requisitos de certificado especiales y, por lo tanto, requiere sus propios certificados que son diferentes de los de otros servicios. CMS utiliza un certificado de servidor, que es similar a los certificados utilizados por otros servidores, pero también hay un certificado de cliente que se utiliza para las conexiones de bases de datos. Los certificados de base de datos se utilizan tanto para la autenticación como para el cifrado. En lugar de proporcionar un nombre de usuario y contraseña para que el cliente se conecte a la base de datos, presenta un certificado de cliente en el que el servidor confía. Cada servidor del clúster de base de datos utilizará el mismo par de claves públicas y privadas. Esto permite que todos los servidores del clúster cifren datos de tal manera que solo puedan ser descifrados por otros servidores que también compartan el mismo par de claves.
Para que funcione la redundancia, los clústeres de bases de datos deben constar de un mínimo de 3 servidores, pero no más de 5, con un tiempo máximo de ida y vuelta de 200 ms entre los miembros del clúster. Este límite es más restrictivo que el de la agrupación en clústeres de Call Bridge, por lo que suele ser el factor limitante en implementaciones distribuidas geográficamente.
La función de la base de datos para un CMS tiene una serie de requisitos únicos. A diferencia de otras funciones, requiere un certificado de cliente y servidor, donde el certificado del cliente tiene un campo CN específico que se presenta al servidor.
El CMS utiliza una base de datos Postgres con un maestro y varias réplicas completamente idénticas. Sólo hay una base de datos primaria a la vez (el “servidor de base de datos”). Los miembros restantes del clúster son réplicas o "clientes de base de datos".
Un clúster de base de datos requiere un certificado de servidor dedicado y un certificado de cliente. Deben estar firmados por certificados, normalmente una autoridad certificadora privada interna. Dado que cualquier miembro del clúster de la base de datos puede convertirse en maestro, los pares de certificados del servidor de la base de datos y del cliente (que contienen las claves pública y privada) deben copiarse en todos los servidores para que puedan asumir la identidad del cliente o del servidor de la base de datos. Además, se debe cargar el certificado raíz de CA para garantizar que se puedan verificar los certificados del cliente y del servidor.
Entonces, creamos una solicitud para un certificado que será utilizado por todos los servicios del servidor excepto la base de datos (habrá una solicitud separada para esto) con un comando como:
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 nombres de host de nuestros servidores server01, server02, server03, entonces CN será servidor.ejemplo.com
Hacemos lo mismo en los dos servidores restantes con la diferencia de que los comandos contendrán los “hostnames” correspondientes.
Generamos dos solicitudes de certificados que serán utilizadas por el servicio de base de datos con comandos como:
pki csr dbclusterserver CN:hostname1.example.com subjectAltName:hostname2.example.com,hostname3.example.com
pki csr dbclusterclient CN:postgresdonde servidor de clúster de base de datos и clientedbcluster nombres de nuestras solicitudes y futuros certificados, nombre de host1(2)(3) nombres de los servidores correspondientes.
Realizamos este procedimiento solo en un servidor (!), y cargaremos los certificados y los archivos .key correspondientes a otros servidores.
Habilite el modo de certificado de cliente en AD CS
También debe fusionar los certificados de cada servidor en un solo archivo.En *NIX:
cat server01.cer server02.cer server03.cer > server.cerEn Windows/DOS:
copy server01.cer + server02.cer + server03.cer server.cer
Y subir a cada servidor:
1. Certificado de servidor “individual”.
2. Certificado raíz (junto con los intermedios, en su caso).
3. Certificados de la base de datos (“servidor” y “cliente”) y archivos con extensión .key, que se generaron al crear una solicitud de certificados de la base de datos “servidor” y “cliente”. Estos archivos deben ser los mismos en todos los servidores.
4. Archivo de los tres certificados “individuales”.
Como resultado, debería obtener algo como esta imagen de archivo en cada servidor.
Clúster de base de datos
Ahora que tiene todos los certificados cargados en los servidores CMS, puede configurar y habilitar la agrupación de bases de datos entre los tres nodos. El primer paso es seleccionar un servidor como nodo maestro del clúster de base de datos y configurarlo completamente.
Base de datos maestra
El primer paso para configurar la replicación de la base de datos es especificar los certificados que se utilizarán para la base de datos. Esto se hace usando un comando como:
database cluster certs <server_key> <server_crt> <client_key> <client_crt> <ca_crt>Ahora digamos al CMS qué interfaz usar para la agrupación de bases de datos con el comando:
database cluster localnode aLuego inicializamos la base de datos del clúster en el servidor principal con el comando:
database cluster initialize
Nodos de base de datos de clientes
Hacemos el mismo procedimiento, solo que en lugar del comando. inicialización del clúster de base de datos ingrese un comando como:
database cluster join <ip address existing master>donde dirección IP existente dirección IP maestra del servidor CMS en el que se inicializó el clúster, simplemente Maestro.
Comprobamos cómo funciona nuestro clúster de base de datos en todos los servidores con el comando:
database cluster status
Hacemos lo mismo en el tercer servidor restante.
Como resultado, resulta que nuestro primer servidor es el Maestro, el resto son Esclavos.
Servicio de administración web
Habilite el servicio de administrador web:
webadmin listen a 445Se eligió el puerto 445 porque el puerto 443 se utiliza para el acceso de los usuarios al cliente web.
Configuramos el servicio Web Admin con archivos de certificados con un comando como:
webadmin certs <keyfile> <certificatefile> <ca bundle>Y habilite Web Admin con el comando:
webadmin enable
Si todo está bien, recibiremos líneas de ÉXITO indicando que Web Admin está configurado correctamente para la red y el certificado. Comprobamos la funcionalidad del servicio mediante un navegador web e ingresamos la dirección del administrador web, por ejemplo: : 445
Clúster de puente de llamadas
Call Bridge es el único servicio presente en todas las implementaciones de CMS. Call Bridge es el principal mecanismo de conferencia. También proporciona una interfaz SIP para que las llamadas se puedan enrutar hacia o desde ella mediante, por ejemplo, un Cisco Unified CM.
Los comandos que se describen a continuación deben ejecutarse en cada servidor con los certificados adecuados.
Por lo tanto:
Asociamos certificados al servicio Call Bridge con un comando como:
callbridge certs <keyfile> <certificatefile>[<cert-bundle>]Vinculamos los servicios CallBridge a la interfaz que necesitamos con el comando:
callbridge listen aY reinicie el servicio con el comando:
callbridge restart
Ahora que tenemos nuestros Call Bridges configurados, podemos configurar la agrupación de Call Bridge. La agrupación en clústeres de Call Bridge es diferente de la agrupación en clústeres de bases de datos o XMPP. Call Bridge Cluster puede admitir de 2 a 8 nodos sin ninguna restricción. Proporciona no sólo redundancia, sino también equilibrio de carga para que las conferencias se puedan distribuir activamente entre servidores Call Bridge mediante la distribución inteligente de llamadas. El CMS tiene funciones adicionales, grupos de Call Bridge y funciones relacionadas que se pueden utilizar para una mayor gestión.
La agrupación de puentes de llamadas se configura principalmente a través de la interfaz de administración web
El procedimiento que se describe a continuación debe realizarse en cada servidor del cluster.
Por lo tanto,
1. Vaya a través de la web a Configuración > Clúster.
2. En Identidad del puente de llamada Como nombre único, ingrese callbridge[01,02,03] correspondiente al nombre del servidor. Estos nombres son arbitrarios, pero deben ser únicos para este clúster. Son de naturaleza descriptiva porque indican que son identificadores de servidor [01,02,03].
3.B Puentes de llamadas agrupados ingrese las URL del administrador web de nuestros servidores en el clúster, [01,02,03].example.com:445, en el campo Dirección. Asegúrese de especificar el puerto. Puede dejar el dominio SIP de enlace de igual vacío.
4. Agregue un certificado a la confianza CallBridge de cada servidor, cuyo archivo contiene todos los certificados de nuestros servidores, que fusionamos en este archivo al principio, con un comando como:
callbridge trust cluster <trusted cluster certificate bundle>Y reinicie el servicio con el comando:
callbridge restart
Como resultado, en cada servidor deberías obtener esta imagen:
Clúster XMPP
El servicio XMPP en el CMS se utiliza para manejar todo el registro y la autenticación de Cisco Meeting Apps (CMA), incluido el cliente web CMA WebRTC. El propio Call Bridge también actúa como un cliente XMPP para fines de autenticación y, por lo tanto, debe configurarse como otros clientes. La tolerancia a fallas de XMPP es una característica que se admite en entornos de producción desde la versión 2.1.
Los comandos que se describen a continuación deben ejecutarse en cada servidor con los certificados adecuados.
Por lo tanto:
Asociamos certificados al servicio XMPP con un comando como:
xmpp certs <keyfile> <certificatefile>[<cert-bundle>]Luego defina la interfaz de escucha con el comando:
xmpp listen aEl servicio XMPP requiere un dominio único. Este es el inicio de sesión para los usuarios. En otras palabras, cuando un usuario intenta iniciar sesión utilizando la aplicación CMA (o mediante el cliente WebRTC), ingresa ID de usuario@dominio de inicio de sesión. En nuestro caso será userid@conf.ejemplo.com. ¿Por qué no es sólo ejemplo.com? En nuestra implementación particular, seleccionamos nuestro dominio Unified CM que los usuarios de Jabber usarán en Unified CM como example.com, por lo que necesitábamos un dominio diferente para que los usuarios de CMS enruten llamadas hacia y desde el CMS a través de dominios SIP.
Configure un dominio XMPP usando un comando como:
xmpp domain <domain>Y habilite el servicio XMPP con el comando:
xmpp enableEn el servicio XMPP, debe crear credenciales para cada Call Bridge que se utilizará al registrarse en el servicio XMPP. Estos nombres son arbitrarios (y no están relacionados con los nombres únicos que configuró para la agrupación de puentes de llamadas). Debe agregar tres puentes de llamadas en un servidor XMPP y luego ingresar esas credenciales en otros servidores XMPP en el clúster porque esta configuración no cabe en la base de datos del clúster. Posteriormente configuraremos cada Call Bridge para que use 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. Posteriormente se ingresarán en otros servidores de Call Bridge para iniciar sesión en este servidor XMPP. Ingrese los siguientes comandos:
xmpp callbridge add callbridge01
xmpp callbridge add callbridge02
xmpp callbridge add callbridge03Como resultado, comprobamos qué pasó con el comando:
xmpp callbridge list
Exactamente la misma imagen debería aparecer en los servidores restantes después de los pasos que se describen a continuación.
A continuación, agregamos exactamente la misma configuración en los dos servidores restantes, solo que con los comandos
xmpp callbridge add-secret callbridge01
xmpp callbridge add-secret callbridge02
xmpp callbridge add-secret callbridge03Agregamos Secret con mucho cuidado para que, por ejemplo, no queden espacios adicionales.
Como resultado, cada servidor debería tener la misma imagen:
A continuación, en todos los servidores del clúster, especificamos en confianza el archivo que contiene los tres certificados, creado anteriormente con un comando como este:
xmpp cluster trust <trust bundle>Habilitamos 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 de un clúster xmpp con el comando:
xmpp cluster initializeEn otros servidores, agregue un clúster a xmpp con un comando como:
xmpp cluster join <ip address head xmpp server>Comprobamos en cada servidor el éxito de la creación de un clúster XMPP en cada servidor con los comandos:
xmpp status
xmpp cluster statusPrimer servidor:
Segundo servidor:
Tercer servidor:
Conexión de Call Bridge a XMPP
Ahora que el clúster XMPP se está ejecutando, debe configurar los servicios Call Bridge para conectarse al clúster XMPP. Esta configuración se realiza a través del administrador web.
En cada servidor, vaya a Configuración > General y en el campo Nombre único del puente de llamadas escribir nombres únicos correspondientes al servidor Call Bridge puente de llamadas[01,02,03]... En campo Dominio conf.ejemplo.ru y contraseñas correspondientes, puedes espiarlas
en cualquier servidor del clúster con el comando:
xmpp callbridge list
Deje el campo "Servidor" vacío Puente de llamadas realizará una búsqueda DNS SRV para _xmpp-component._tcp.conf.example.compara encontrar un servidor XMPP disponible. Las direcciones IP para conectar callbridges a XMPP pueden diferir en cada servidor, depende de qué valores se devuelven a la solicitud de registro. _xmpp-component._tcp.conf.example.com callbridge, que a su vez depende de la configuración de prioridad para un registro DNS determinado.
A continuación, vaya a Estado > General para verificar si el servicio Call Bride está conectado correctamente al servicio XMPP.
Puente web
En cada servidor del clúster, habilite el servicio Web Bridge con el comando:
webbridge listen a:443Configuramos el servicio Web Bridge con archivos de certificados con un comando como:
webbridge certs <keyfile> <certificatefile> <ca bundle>Puente web admite HTTPS. Redireccionará HTTP a HTTPS si está configurado para usar "http-redirect".
Para habilitar la redirección HTTP, utilice el siguiente comando:
webbridge http-redirect enablePara que Call Bridge sepa que Web Bridge puede confiar en las conexiones de Call Bridge, use el comando:
webbridge trust <certfile>donde se trata de un archivo que contiene los tres certificados de cada servidor del clúster.
Esta imagen debe estar en todos los servidores del clúster.
Ahora necesitamos crear un usuario con el rol "appadmin", lo necesitamos para poder configurar nuestro clúster (!), y no cada servidor en el clúster por separado, de esta manera la configuración se aplicará por igual a cada servidor a pesar de hecho de que se harán una vez.
Para una mayor configuración usaremos .
Para autorización, seleccione Básico en la sección Autorización
Para enviar comandos correctamente al servidor CMS, debe configurar la codificación requerida
Especificamos Webbridge con el comando PUBLICAR con parámetro url y significado
En el propio webbridge indicamos los parámetros requeridos: acceso de invitados, acceso protegido, etc.
Grupos de puente de llamadas
De forma predeterminada, el CMS no siempre hace el uso más eficiente de los recursos de conferencia disponibles.
Por ejemplo, para una reunión con tres participantes, cada participante puede terminar en tres puentes de llamada diferentes. Para que estos tres participantes se comuniquen entre sí, Call Bridges establecerá automáticamente conexiones entre todos los servidores y clientes en el mismo Espacio, de modo que todo parezca como si todos los clientes estuvieran en el mismo servidor. Desafortunadamente, la desventaja de esto es que una sola conferencia de 3 personas ahora consumirá 9 puertos multimedia. Evidentemente se trata de un uso ineficiente de los recursos. Además, cuando un Call Bridge está realmente sobrecargado, el mecanismo predeterminado es continuar aceptando llamadas y brindar un servicio de calidad reducida a todos los suscriptores de ese Call Bridge.
Estos problemas se resuelven utilizando la función Call Bridge Group. Esta característica se introdujo en la versión 2.1 del software Cisco Meeting Server y se ha ampliado para admitir el equilibrio de carga para llamadas entrantes y salientes de la aplicación Cisco Meeting (CMA), incluidos los participantes de WebRTC.
Para solucionar el problema de reconexión, se han introducido tres límites de carga configurables para cada Call Bridge:
Límite de carga — esta es la carga numérica máxima para un Call Bridge en particular. Cada plataforma tiene un límite de carga recomendado, como 96000 para el CMS1000 y 1.25 GHz por vCPU para la máquina virtual. Las diferentes llamadas consumen una determinada cantidad de recursos según la resolución y la velocidad de fotogramas del participante.
NuevaConferenciaLoadLimitBasisPoints (predeterminado 50% loadLimit): establece el límite de carga del servidor, después del cual se rechazan las nuevas conferencias.
existenteConferenceLoadLimitBasisPoints (predeterminado 80% de loadLimit): el valor de carga del servidor después del cual se rechazarán los participantes que se unan a una conferencia existente.
Si bien esta función fue diseñada para la distribución de llamadas y el equilibrio de carga, otros grupos, como servidores TURN, servidores de puente web y grabadores, también se pueden asignar a grupos de puente de llamadas para que también se puedan agrupar adecuadamente para un uso óptimo. Si alguno de estos objetos no está asignado a un grupo de llamadas, se supone que está disponible para todos los servidores sin ninguna prioridad particular.
Estos parámetros se configuran aquí: :445/api/v1/sistema/configuración/clúster
A continuación, indicamos a cada callbridge a qué grupo de callbridge pertenece:
Primer puente de llamada
Segundo puente de llamada
Tercer puente de llamada
Por lo tanto, configuramos el grupo Call Brdige para utilizar de manera más eficiente los recursos del clúster de 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 almacena 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 la API, y para que "tres veces" No nos levantemos ", seguiremos configurando los datos a través de la API.
Usando URL para acceder :445/api/v1/ldapServers crea un objeto de servidor LDAP, especificando parámetros como:
- Servidor IP
- número de puerto
- имя пользователя
- пароль
- seguro
Seguro: seleccione verdadero o falso según el puerto, 389: no seguro, 636: protegido.
Asignación de parámetros de origen LDAP a atributos en Cisco Meeting Server.
La asignación LDAP asigna los atributos del directorio LDAP a los atributos del CMS. Los atributos reales:
- jidMapeo
- nombreMapeo
- coSpaceNameMapping
- coSpaceUriMapping
- coSpaceSecondaryUriMapping
Descripción de atributosBID representa el ID de inicio de sesión del usuario en el CMS. Dado que se trata de un servidor LDAP de Microsoft Active Directory, el JID de CMS se asigna al sAMAccountName en LDAP, que es esencialmente el ID de inicio de sesión de Active Directory del usuario. También 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 usarán sus usuarios para iniciar sesión en el CMS.
nombreMapeo coincide con lo que está contenido en el campo displayName de Active Directory con el campo de nombre del CMS del usuario.
coSpaceNameMapping crea un nombre de espacio CMS basado en el campo displayName. Este atributo, junto con el atributo coSpaceUriMapping, es lo que se requiere para crear un espacio para cada usuario.
coSpaceUriMapping define la parte del usuario del URI asociado con el espacio personal del usuario. Algunos dominios se pueden configurar para conectarse al espacio. Si la parte del usuario coincide con este campo para uno de estos dominios, la llamada se dirigirá al espacio de ese usuario.
coSpaceSecondaryUriMapping define un segundo URI para llegar al espacio. Esto se puede utilizar para agregar un alias numérico para enrutar llamadas al espacio del usuario importado como alternativa al URI alfanumérico definido en el parámetro coSpaceUriMapping.
El servidor LDAP y la asignación LDAP están configurados. Ahora necesita vincularlos creando una fuente LDAP.
Usando URL para acceder :445/api/v1/ldapSource crea un objeto de origen LDAP, especificando parámetros como:
- servidor
- cartografía
- baseDn
- filtrar
Ahora que la configuración LDAP está completa, puede realizar la operación de sincronización manual.
Esto lo hacemos ya sea en la interfaz Web de cada servidor haciendo clic Sincronizar ahora sección Directorio Activo
o mediante la API con el comando PUBLICAR usando URL para acceder :445/api/v1/ldapSyncs
Conferencias ad hoc
¿Qué es esto?En el concepto tradicional, una conferencia es cuando dos participantes están hablando entre sí y uno de los participantes (usando un dispositivo registrado con Unified CM) presiona el botón "Conferencia", llama a la otra persona y luego de hablar con ese tercero. , presiona nuevamente el botón "Conferencia" para unir a todos los participantes en la conferencia tripartita.
Lo que distingue una conferencia Ad-Hoc de una conferencia programada en un CMS es que una conferencia Ad-Hoc no es sólo una llamada SIP al CMS. Cuando el iniciador de la conferencia hace clic en el botón Conferencia por segunda vez para invitar a todos a la misma reunión, Unified CM debe realizar una llamada API al CMS para crear una conferencia sobre la marcha a la que luego se transfieren todas las llamadas. Todo esto pasa desapercibido para los participantes.
Esto significa que Unified CM debe configurar las credenciales de API y la dirección/puerto de WebAdmin del servicio, así como el troncal SIP directamente en el servidor CMS para continuar la llamada.
Si es necesario, CUCM puede crear dinámicamente un espacio en el CMS para que cada llamada pueda llegar al CMS y coincidir con la regla de llamadas entrantes destinada a los espacios.
Integración con CUCM configurado de la misma manera que se describe en el artículo excepto que en Cisco UCM necesita crear tres troncales para el CMS, tres puentes de conferencia, en el perfil de seguridad SIP especifique tres nombres de sujeto, grupos de rutas, listas de rutas, grupos de recursos de medios y listas de grupos de recursos de medios, y agregue algunas reglas de enrutamiento. al servidor de reuniones de Cisco.
Perfil de seguridad SIP:
Bañador:
Cada baúl tiene el mismo aspecto:
Puente de conferencia
Cada puente de conferencia tiene el mismo aspecto:
Grupo de ruta
Lista de rutas
Grupo de recursos de medios
Lista de grupos de recursos de medios
Reglas de llamada
A diferencia de los sistemas de administración de llamadas más avanzados, como Unified CM o Expressway, CMS solo busca el dominio en el campo SIP Request-URI para nuevas llamadas. Entonces, si SIP INVITE es para sorber: [email protected]El CMS sólo se preocupa por el dominio.com. CMS sigue estas reglas para determinar dónde enrutar una llamada:
1. El CMS primero intenta hacer coincidir el dominio SIP con los dominios configurados en las reglas de llamadas entrantes. Luego, estas llamadas se pueden enrutar a espacios (“dirigidos”) o usuarios específicos, IVR internos o destinos Microsoft Lync/Skype for Business (S4B) directamente integrados.
2. Si no hay coincidencia en las reglas de llamadas entrantes, CMS intentará hacer coincidir el dominio configurado en la tabla de desvío de llamadas. Si se realiza una coincidencia, la regla puede rechazar explícitamente la llamada o reenviarla. En este momento, el CMS puede reescribir el dominio, lo que a veces resulta útil para llamar a dominios de Lync. También puede optar por pasar, lo que significa que ninguno de los campos se modificará más, o utilizar un plan de marcado interno de CMS. Si no hay coincidencia en las reglas de desvío de llamadas, el valor predeterminado es rechazar la llamada. Tenga en cuenta que en el CMS, aunque la llamada se "reenvía", los medios todavía están vinculados al CMS, lo que significa que estarán en la ruta de señalización y tráfico de medios.
En ese caso, sólo las llamadas desviadas estarán sujetas a las reglas de llamadas salientes. Estas configuraciones determinan los destinos a donde se envían las llamadas, el tipo de troncal (ya sea una nueva llamada Lync o una llamada SIP estándar) y cualquier conversión que se pueda realizar si no se selecciona la transferencia en la regla de desvío de llamadas.
Aquí está el registro real de lo que sucede durante una conferencia Ad-Hoc.
La captura de pantalla lo muestra mal (no sé cómo mejorarlo), así que escribiré el registro 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:12La conferencia Ad-Hoc en sí:
Reglas de llamadas entrantes
Es necesario configurar los parámetros de las llamadas entrantes para poder recibir una llamada en el CMS. Como vio en la configuración de LDAP, todos los usuarios fueron importados con el dominio conf.pod6.cms.lab. Entonces, como mínimo, desea que las llamadas a este dominio se dirijan a espacios. También deberá configurar reglas para todo lo que esté destinado al nombre de dominio completo (y tal vez incluso a la dirección IP) de cada uno de los servidores CMS. Nuestro control de llamadas externo, Unified CM, configurará troncales SIP dedicadas a cada uno de los servidores CMS de forma individual. Dependiendo de si el destino de estas troncales SIP es una dirección IP o el FQDN del servidor, se determinará si el CMS debe configurarse para aceptar llamadas dirigidas a su dirección IP o FQDN.
El dominio que tiene la regla de entrada de mayor prioridad se utiliza como dominio para cualquier espacio de usuario. Cuando los usuarios se sincronizan a través de LDAP, el CMS crea espacios automáticamente, pero solo la parte del usuario del URI (coSpaceUriMapping), por ejemplo, user.space. Parte El URI completo se genera según esta regla. De hecho, si iniciara sesión en Web Bridge en este punto, vería que el URI del espacio no tiene un dominio. Al establecer esta regla como la prioridad más alta, está configurando el dominio para que los espacios generados sean conferenciaejemplo.com.
Reglas de llamadas salientes
Para permitir que los usuarios realicen llamadas salientes al clúster de Unified CM, debe configurar reglas de salida. El dominio de los puntos finales registrados con Unified CM, como Jabber, es ejemplo.com. Las llamadas a este dominio deben enrutarse como llamadas SIP estándar a nodos de procesamiento de llamadas de Unified CM. El servidor principal es cucm-01.example.com y el servidor adicional es cucm-02.example.com.
La primera regla describe el enrutamiento más simple de llamadas entre servidores del clúster.
Campo Local del dominio es responsable de lo que se mostrará en el SIP-URI de la persona que llama después del símbolo "@". Si lo dejamos vacío, luego del símbolo “@” estará la dirección IP del CUCM por donde pasa esta llamada. Si especificamos un dominio, después del símbolo "@" realmente habrá un dominio. Esto es necesario para poder devolver la llamada; de lo contrario, no será posible devolver la llamada a través de SIP-URI nombre@dirección-ip.
Llamar cuando se indique Local del dominio
llamar cuando NO indicado Local del dominio
Asegúrese de especificar explícitamente Cifrado o Sin cifrar para las llamadas salientes, porque nada funciona con el parámetro Automático.
Grabación
Las videoconferencias son grabadas por el servidor de grabación. La grabadora es exactamente igual que Cisco Meeting Server. Recorder no requiere la instalación de ninguna licencia. Se requieren licencias de grabación para los servidores que ejecutan servicios CallBridge, es decir. Se requiere una licencia de grabación que debe aplicarse al componente CallBridge y no al servidor que ejecuta Recorder. La grabadora se comporta como un cliente de protocolo de presencia y mensajería extensible (XMPP), por lo que el servidor XMPP debe estar habilitado en el servidor que aloja CallBridge.
Porque Tenemos un clúster y la licencia debe extenderse a los tres servidores del clúster. Luego, simplemente en su cuenta personal en las licencias asociamos (agregamos) las direcciones MAC de las interfaces A de todos los servidores CMS incluidos en el clúster.
Y esta es la imagen que debería estar en cada servidor del clúster.
En general, existen varios escenarios para colocar Recorder, pero nos ceñiremos a este:
Antes de configurar la Grabadora, debe preparar un lugar donde se grabarán las videoconferencias. En realidad aquí , cómo configurar todas las grabaciones. Me concentro en puntos y detalles importantes:
1. Es mejor transferir el certificado del primer servidor del clúster.
2. El error "Grabadora no disponible" puede ocurrir porque se especifica un certificado incorrecto en Recorder Trust.
3. Es posible que la escritura no funcione si el directorio NFS especificado para la grabación no es el directorio raíz.
A veces es necesario grabar automáticamente una conferencia de un usuario o espacio específico.
Para ello se crean dos CallProfiles:
Con la grabación desactivada
Y con función de grabación automática.
A continuación, "adjuntamos" un CallProfile con función de grabación automática al espacio requerido.
En CMS está establecido que si un CallProfile está explícitamente vinculado a cualquier espacio o espacio, entonces este CallProfile funciona solo en relación con estos espacios específicos. Y si CallProfile no está vinculado a ningún espacio, entonces, de forma predeterminada, se aplica a aquellos espacios a los que no está vinculado explícitamente ningún CallProfile.
La próxima vez intentaré describir cómo se accede al CMS fuera de la red interna de la organización.
Fuentes:
Fuente: habr.com