El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
Este documento describe cómo agregar participantes a una conferencia CMS existente en la implementación de CMS agrupado con el Balanceo de Carga habilitado.
Cisco recomienda que tenga conocimiento sobre estos temas:
Este documento asume que el Balanceo de Carga ya está configurado para sus Callbridges (CB) agrupados y funciona para llamadas directas a estos servidores CMS (llamando directamente a un espacio CMS existente). Esto significa que estos requisitos ya están configurados:
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Nota: Existen tres métodos principales para agregar un participante a una conferencia CMS existente: agregar un participante mediante API, agregar un participante mediante Control activo y agregar un participante sin Control activo.
1. Añadir un participante mediante API
Para utilizar este método, se debe habilitar LoadbalanceOutgoingCalls en el grupo Callbridge.
Para agregar al participante mediante este método, se debe realizar una solicitud API POST a /calls/<active-call-id>/participate/. La solicitud POST debe incluir la ID de participante del participante que se va a agregar a la conferencia como valor del parámetro remoteParty, que forma parte de esta solicitud POST.
Esta solicitud POST indica al CMS que realice una llamada saliente al participante que se va a agregar. Si se habilita LoadbalanceOutgoingCalls en el grupo Callbridge, 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 está agregando, 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 Control activo
Para utilizar la opción de agregar participante de control activo, primero debe negociarse el control activo entre el servidor CMS y el usuario que está agregando el participante.
Debe habilitar el control activo en el perfil de troncal SIP configurado en el troncal SIP que conecta CUCM con CMS, para hacerlo, habilite el parámetro Allow IX application media, y observe que el perfil SIP estándar para conferencias de TelePresence lo habilita de forma predeterminada. Además, se debe habilitar LoadbalanceOutgoingCalls en el grupo Callbridge.
Cuando se agrega un participante mediante Control activo a una conferencia CMS existente, el usuario (mediante un mensaje de control activo) le indica a CMS1 que realice una llamada saliente al nuevo participante. Si se alcanza el valor de 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.
Este es un comportamiento defectuoso y se está rastreando bajo el defecto: CSCvu72374
3. Añadir un participante sin control activo
Cuando se agrega un participante sin utilizar el control activo (por lo tanto, Allow IX application media not enabled on the SIP Profile), 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, el participante no se puede agregar 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 alcanzar su límite de carga máximo. A continuación, corresponde al 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 las conferencias ad hoc.
Este documento proporciona los pasos de configuración necesarios para utilizar la tercera forma de agregar un participante a una conferencia existente (Agregar un participante sin control activo).
El comportamiento tratado con los pasos de configuración en este documento es:
1. El usuario crea una conferencia ad hoc, el servidor CMS1 la aloja
2. Una vez establecida 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, pero 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 corrija el defecto de control activo. El control activo se desactiva en esa conferencia ad-hoc.
Paso 1. Crear un nuevo perfil de seguridad de enlace troncal SIP para el enlace troncal 1
Paso 2. Crear un nuevo perfil de seguridad de línea troncal SIP para línea troncal 2
Paso 3. Crear un nuevo script de normalización SIP
M = {} function M.outbound_INVITE(msg) msg:removeHeaderValue("Call-Info", "<urn:x-cisco-remotecc:conference>") end return M
Paso 4. Crear un nuevo perfil SIP
Paso 5. Crear una nueva partición
Paso 6. Crear un nuevo espacio de búsqueda de llamadas (CSS):
Paso 7. Cree un nuevo troncal SIP, Trunk1:
Nombre del dispositivo | Introduzca un nombre para el enlace troncal SIP, Trunk1 |
Ejecutar en todos los nodos activos de Unified CM | Activado |
Dirección de destino | Introduzca la dirección IP del propio servidor de CUCM; por ejemplo, 10.48.36.50 |
Puerto de Destino | Ingrese el puerto en el que escucha Trunk2, 5041 |
Perfil de seguridad del enlace troncal SIP | Seleccione el perfil creado en el paso 1, recepción no segura troncal 1 en 5040 |
Perfil SIP | Seleccione el perfil creado en el paso 4, Sin control activo de conferencias de telepresencia |
Método de señalización DTMF | Seleccione RFC 2833 |
Guión de normalización SIP |
Seleccione el script creado en el paso 3, remove_conference_from_call_info_header. |
Paso 8. Crear un nuevo troncal SIP, Trunk2:
Nombre del dispositivo | Introduzca un nombre para el enlace troncal SIP, Trunk2 |
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 de CUCM; por ejemplo, 10.48.36.50 |
Puerto de Destino | Ingrese el puerto en el que escucha el Trunk1, 5040 |
Perfil de seguridad del enlace troncal SIP | Seleccione el perfil creado en el paso 2, recepción no segura troncal 2 en 5041 |
Perfil SIP | Seleccione el perfil creado en el paso 4, Sin control activo de conferencias de telepresencia |
Método de señalización DTMF | Seleccione RFC 2833 |
Guión de normalización SIP |
Seleccione el script de normalización existente cisco-meeting-server-interop |
Paso 9. Crear un nuevo patrón de ruta
Paso 10. Modifique la configuración del puente de conferencia ad hoc de CMS
Paso 11. Restablecer troncales SIP Trunk1 y Trunk2
Paso 12. Restablecer servidores CMS ad hoc
Utilize esta sección para confirmar que su configuración funcione correctamente.
Actualmente, no hay información específica de troubleshooting disponible para esta configuración.
Puede utilizar la herramienta Analizador de soluciones de colaboración para el análisis de registros.
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
17-Jun-2020 |
Versión inicial |