Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Métodos para agregar participantes a una conferencia CMS existente

Configurar

Verificación

Troubleshoot

Información Relacionada

Introducción

Este documento describe cómo agregar participantes a una conferencia CMS existente en la implementación de CMS agrupados con Balanceo de Carga habilitado.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

- Equilibrio de carga de CMS (Cisco Meeting Server)

- Conferencias ad-hoc de CUCM (Cisco Unified Communications Manager)

Este documento asume que el balanceo de carga ya está configurado para los Callbridges agrupados (CB) y que trabaja para llamadas directas a estos servidores CMS (llamando directamente a un espacio CMS existente). Esto significa que estos requisitos ya están configurados:

- Todos los servidores CMS que se van a utilizar para las conferencias ad hoc se agregan a CUCM > Media Resources > Conference Bridge y están registrados

- Se crea una lista de grupos de recursos de medios (MRGL) que contiene un grupo de recursos de medios (MRG), y sólo tiene los servidores CMS, y es el primer grupo en el MRGL.

- Se crea una lista de rutas que contiene un grupo de rutas, y tiene los servidores CMS, y el algoritmo de distribución seleccionado es Circular

Componentes Utilizados

La información que contiene este documento se basa en las siguientes versiones de software y hardware.

- CMS 2.9.1

- CUCM 12.5.1

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Métodos para agregar participantes a una conferencia CMS existente

Nota: Existen tres métodos principales para agregar un participante a una conferencia CMS existente: agregue un participante a través de la API, agregue un participante a través de Active Control y agregue un participante sin Active Control.

1. Agregar un participante mediante API

Para utilizar este método, LoadbalanceOutgoingCalls en el Grupo Callbridge debe estar habilitado.

Para agregar al participante utilizando este método, se debe realizar una solicitud API POST a /calls/<active-call-id>/entries/. La solicitud POST debe incluir la ID de participante del participante que se agrega a la conferencia como valor del parámetro remoteParty, que forma parte de esta solicitud POST.

Esta solicitud POST indica a CMS que realice una llamada saliente al participante que se está agregando. Si LoadbalanceLlamadasSalientes en el Grupo Callbridge está habilitado, y si CMS ha alcanzado su límite de carga, encuentra un servidor CMS libre en el clúster para realizar una llamada saliente al participante que se agrega y se crea una llamada distribuida entre los dos servidores. Este es el mismo método que utiliza CMM para agregar participantes a una conferencia CMS.

2. Agregar un participante mediante el control activo

Para utilizar el agregado de participante de control activo, primero se debe negociar el control activo entre el servidor CMS y el usuario que agrega el participante.

Debe habilitar el control activo en el perfil de troncal SIP que se configura en el troncal SIP que conecta CUCM con CMS, para que habilite el parámetro Allow IX application media y tenga en cuenta que el perfil SIP estándar para conferencias de TelePresence lo tiene habilitado de forma predeterminada. Además, LoadbalanceLlamadasSalientes en el Grupo Callbridge debe estar habilitado.

Cuando se agrega un participante a través de Control activo a una conferencia CMS existente, el usuario (a través de un mensaje de control activo) le indica a CMS1 que realice una llamada saliente al nuevo participante. Si se alcanza el valor límite de carga configurado en CMS1 y el usuario intenta agregar un nuevo participante con control activo, CMS1 muestra este mensaje de error (hasta la versión 2.9.1 de CMS):

add participant "<participant-uri>" request failed: call bridge unavailable

Esto se aplica a ambos casos prácticos: cuando el participante se agrega a una conferencia ad hoc y cuando se agrega a un espacio CMS existente a través del control activo.

Se trata de un comportamiento defectuoso y se está realizando un seguimiento del defecto:  CSCvu72374

3. Agregar un participante sin control activo

Cuando se agrega un participante sin utilizar el control activo (por lo tanto, Permitir IX medios de aplicación no habilitado en el perfil SIP), CUCM realiza una llamada entre el usuario que inicia la acción y el nuevo participante. A continuación, cuando el usuario está listo para unirse al nuevo participante en la conferencia, CUCM realiza una llamada saliente a la conferencia ad hoc que se ejecuta en CMS1. Si se alcanza el límite de carga en CMS1, no se puede agregar al participante y CMS1 muestra este mensaje de error (55 es un número de llamada de ejemplo):

call 55: ending; local teardown, system participant limit reached - not connected after 0:00

Este mensaje de error es un mensaje de error normal que debe imprimir un servidor CMS cuando recibe una llamada entrante y después de haber alcanzado su límite máximo de carga. A continuación, depende del servidor de control de llamadas (CUCM o VCS) continuar enrutando la llamada a otros miembros del clúster. Sin embargo, en el caso de una conferencia ad hoc, esto no funciona y no es posible, ya que CUCM no tiene una lista de rutas para conferencias ad hoc.

Configurar

Este documento proporciona los pasos de configuración necesarios para utilizar la tercera forma de agregar participantes a una conferencia existente (Agregar un participante sin control activo).

El comportamiento que se aborda con los pasos de configuración en este documento es:

1. El usuario crea una conferencia ad hoc, el servidor CMS1 la aloja

2. Después de establecer la conferencia ad hoc, CMS1 alcanza gradualmente su límite de carga configurado (configurado sobre API en /system/configuration/cluster)

3. El usuario intenta agregar un nuevo participante a la conferencia ad hoc en curso; sin embargo, el nuevo usuario no se conecta a la conferencia

Nota: Este procedimiento de configuración permite que un usuario agregue participantes a una conferencia ad hoc de CMS existente incluso si el servidor CMS que aloja la conferencia ad hoc ha alcanzado su límite de carga y se puede utilizar hasta que se haya corregido el defecto de control activo. El control activo se inhabilita en esa conferencia ad-hoc.

Paso 1.  Cree un nuevo perfil de seguridad de troncal SIP para el enlace troncal 1

- Vaya a Sistema > Seguridad > Perfil de seguridad del enlace troncal SIP

- Seleccione Add New (Agregar nuevo).

- Configure el nombre para que Trunk1 no secure receive en 5040

- Configure el Modo de Seguridad del Dispositivo para que no sea seguro

- Establezca el puerto entrante en 5040

- Seleccione Save (Guardar).

Perfil de seguridad SIP de enlace troncal1

Paso 2.  Cree un nuevo perfil de seguridad de troncal SIP para el enlace troncal 2

- Vaya a Sistema > Seguridad > Perfil de seguridad del enlace troncal SIP

- Seleccione Add New (Agregar nuevo).

- Configure el Nombre para que sea Trunk2 no secure receive en 5041

- Configure el Modo de Seguridad del Dispositivo para que no sea seguro

- Establezca el puerto entrante en 5041

- Seleccione Save (Guardar).

Perfil de seguridad SIP de enlace troncal 2

Paso 3.  Crear un nuevo script de normalización SIP

- Vaya a Device > Device settings > Guiones de normalización SIP

- Seleccione Add New (Agregar nuevo).

- Configure el nombre para que sea remove_conference_from_call_info_header

- En el Contenido, utilice este script

M = {}

function M.outbound_INVITE(msg)

msg:removeHeaderValue("Call-Info", "<urn:x-cisco-remotecc:conference>")

end

return M

- Seleccione Save (Guardar).

Paso 4.  Crear un nuevo perfil SIP

- Vaya a Device > Device settings > Perfil SIP

- Seleccione el perfil SIP estándar para la conferencia de TelePresence y cópielo

- Establezca el nombre como No hay conferencia de telepresencia de control activa

- Desmarque la casilla Allow iX Application Media en la parte inferior de la página

- Seleccione Save (Guardar).

Paso 5.  Crear una nueva partición

- Vaya a Call Routing > Class of Control > Partición

- Seleccione Add New (Agregar nuevo).

- Establezca el nombre como cms_adhoc_numbers

- Seleccione Save (Guardar).

Paso 6.  Cree un nuevo espacio de búsqueda de llamadas (CSS):

- Vaya a Call Routing > Class Control > Calling Search Space

- Seleccione Add New (Agregar nuevo).

- Establezca el nombre como CMS_adhoc_numbers

- Agregue la partición creada en el paso 5 cms_adhoc_numbers

- Seleccione Save (Guardar).

Configuración del espacio de búsqueda de llamadas

Paso 7.  Cree un nuevo troncal SIP, Trunk1:

- Vaya a Device >Trunk (Dispositivo > Enlace troncal)

- Seleccione Add New (Agregar nuevo).

- Seleccione SIP Trunk (Enlace troncal SIP) en Trunk Type (Tipo de enlace troncal).

- Seleccione Next (Siguiente).

- Introduzca estos valores y Guardar

Nombre del dispositivo

Introduzca un nombre para el enlace troncal SIP, enlace troncal1

Ejecutar En Todos Los Nodos Activos De Unified CM

Activado

Dirección de destino

Ingrese la IP del propio servidor CUCM, por ejemplo 10.48.36.50

Puerto de Destino

Ingrese el puerto en el que Trunk2 escucha, 5041

Perfil de seguridad del enlace troncal SIP

Seleccione el perfil creado en el paso 1, Trunk1 non secure receive en 5040

Perfil SIP

Seleccione el perfil creado en el paso 4, Sin conferencia de telepresencia de control activa

Método de señalización DTMF

Seleccione RFC 2833

script de normalización SIP

Seleccione el script creado en el paso 3, remove_conference_from_call_info_header

Configuración de troncal1 SIP

Paso 8.  Cree un nuevo troncal SIP, Trunk2:

- Vaya a Device >Trunk (Dispositivo > Enlace troncal)

- Seleccione Add New (Agregar nuevo).

- Seleccione SIP Trunk (Enlace troncal SIP) en Trunk Type (Tipo de enlace troncal).

- Seleccione Next (Siguiente).

- Introduzca estos valores y Guardar

Nombre del dispositivo

Introduzca un nombre para el enlace troncal SIP, enlace troncal2

Ejecutar En Todos Los Nodos Activos De Unified CM

Activado

Calling Search Space

Seleccione el CSS creado en el paso 6, CMS_adhoc_numbers

Dirección de destino

Introduzca la dirección IP o FQDN del propio servidor CUCM; por ejemplo, 10.48.36.50

Puerto de Destino

Ingrese el puerto en el que Trunk1 escucha, 5040

Perfil de seguridad del enlace troncal SIP

Seleccione el perfil creado en el paso 2, Trunk2 non secure receive en 5041

Perfil SIP

Seleccione el perfil creado en el paso 4, Sin conferencia de telepresencia de control activa

Método de señalización DTMF

Seleccione RFC 2833

script de normalización SIP

Seleccione el script de normalización existente cisco-meeting-server-interop

Configuración de Trunk2 SIP

Paso 9.  Crear un nuevo patrón de ruta

- Vaya a Call Routing > Route/Hunt > Patrón de ruta

- Seleccione Add New (Agregar nuevo).

- Establecer el Patrón de ruta a!

- Establezca la partición de ruta en la partición creada en el Paso 5, cms_adhoc_numbers

- Active la casilla de verificación Prioridad urgente

- Cambiar clasificación de llamada a OnNet

- Configure la lista de rutas/gateway para que sea la lista de rutas de CMS que ya está configurada (como se mencionó anteriormente en la sección Requisitos)

- Seleccione Save (Guardar).

Patrón de ruta

lista de rutas de balanceo de carga de CMS

grupo de ruta de balanceo de carga CMS

Paso 10.  Modificar la configuración del puente de conferencia ad hoc de CMS

- Navegar a los recursos de medios > Puente de conferencia

- Seleccione el primer servidor CMS

- Cambie el Enlace troncal SIP para Trunk1, el troncal SIP creado en el paso 7

- Active la casilla de verificación Anular el destino del troncal SIP como dirección HTTPS

- En el campo Nombre de host/Dirección IP, establezca el FQDN de CMS Webadmin para ese servidor CMS específico que también debe existir en el certificado de Webadmin de ese servidor

- Seleccione Save (Guardar).

- Haga lo mismo con todos los demás servidores CMS, configure Trunk1 para que se use en todos ellos; sin embargo, cambie el campo Nombre de host/Dirección IP al FQDN de CMS específico

CMS1

CMS2

CMS3

Paso 11.  Restablecer troncales SIP Trunk1 y Trunk2

- Vaya a Device >Trunk (Dispositivo > Enlace troncal)

- Seleccione Trunk1 y Trunk2

- Seleccione Restablecer seleccionado

- Espere hasta que ambos muestren servicio completo

Paso 12.  Restablecer servidores ad hoc CMS

- Vaya a Media Resources > Conference Bridge (Recursos de medios > Dispositivo de conferencia).

- Seleccionar todos los servidores CMS

- Seleccione Restablecer seleccionado

- Espere hasta que todos los servidores muestren Registrados

Verificación

Utilize esta sección para confirmar que su configuración funcione correctamente.

- Cree una conferencia ad hoc y verifique qué servidor CMS aloja la conferencia

CMS1 que aloja la conferencia ad hoc

- Verifique la carga actual de procesamiento de medios en ese servidor CMS, use una API GET/system/load

Carga de medios actual

- Establezca el límite de carga en el servidor en un valor inferior a la carga de procesamiento de medios enviando un POST a/system/configuration/cluster con el límite de carga del parámetro, por ejemplo, 1000

Cambio del límite de carga

- Agregue un nuevo participante a la reunión. El participante se agrega y se crea una distribución entre CMS1 y otro servidor CMS desde que CMS1 ha alcanzado su límite

Llamada distribuida

Troubleshoot

Actualmente, no hay información específica de troubleshooting disponible para esta configuración.

Puede utilizar la herramienta Collaboration Solutions Analyser para el análisis de registros.

Información Relacionada

- Lógica de equilibrio de carga en Cisco Meeting Server

- documentación de configuración de CMS

- Guías de programación de MMP y API de CMS

- documentación de configuración de CUCM