Comprensión de la lógica de enrutamiento de llamadas en Meeting Server

Introducción

Este documento describe la lógica de ruteo de llamadas de Cisco Meeting Server (CMS) (anteriormente producto Acano) que se divide en varias tablas de ruteo de llamadas. Este documento cubre las diferentes etapas y escenarios que las llamadas pueden tener a través de estas tablas de ruteo de llamadas.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• componente Call Bridge de Cisco Meeting Server.

Componentes Utilizados

La información de este documento se basa en Cisco Meeting Server en la versión 2.3.x.

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.

¿Cuál es la lógica de enrutamiento de llamadas de Cisco Meeting Server (CMS)?

El enrutamiento de llamadas en CMS incluye algunas tablas diferentes de enrutamiento de llamadas. Con el diagrama de flujo que se puede descargar , puede seguir la lógica de ruteo de llamadas para cada llamada que llega al CMS. Esto es válido para todos los tipos de llamadas: Cisco Meeting App (CMA - cliente pesado o WebRTC), llamadas de protocolo de inicio de sesión estándar (SIP) o llamadas SIP de Microsoft, a menos que se especifique lo contrario.

Nota: la única excepción sería para las llamadas iniciadas por CMS (CMS directamente para llamadas salientes programadas de TelePresence Management Suite (TMS) o llamadas de cliente de CMA salientes) en las que se omite la tabla de desvío de llamadas.

Este es el orden del proceso de ruteo de llamadas dentro de CMS: 

1. Tabla de coincidencia de llamadas entrantes
2. Tabla de desvío de llamadas entrantes
3. Tabla de llamadas salientes

Cada tabla se explica con más detalle más adelante en el documento, que incluye las imágenes que sólo muestran la parte relevante de .

Nota: CMS solo realiza el enrutamiento de llamadas basándose en el enrutamiento del dominio, por lo tanto, en el lado derecho (RHS) del identificador uniforme de recursos (URI). No hay ninguna funcionalidad de enrutamiento de llamadas basada en el lado izquierdo (LHS) del URI como la que tiene en Cisco Unified Communications Manager (CUCM) con enrutamiento de número de directorio (patrones de ruta).

Nota: Cada tabla es una lista ordenada establecida por el atributo priority. Una prioridad más alta significa que intenta ser igualado primero. Si no coincide, continúa con la siguiente regla de la lista. Como regla general, dé a las reglas más generales (como un * que coincida con cualquier dominio) una prioridad más baja que las reglas más específicas. De ese modo, las reglas específicas se controlan en primer lugar y se tiene la posibilidad de recurrir a las reglas más generales.

Paso 1. Tabla de coincidencia de llamadas entrantes

Este es el primer paso del proceso en el que CMS determina si la llamada entrante está destinada al propio Cisco Meeting Server y tendría que procesarse en él más adelante o si se trata de una llamada destinada a un sistema diferente en el que CMS es el agente que interactúa con la llamada y gestiona tanto los medios como la señalización (por ejemplo, las llamadas de gateway de Skype a terminales SIP estándar o viceversa).

Comprueba si la parte del dominio del URI entrante coincide o no con la tabla coincidente entrante. Si coincide, puede enrutar la llamada al espacio, al usuario, a IVR o realizar una búsqueda de conferencia de Lync (en las instalaciones o fuera de ellas) según la configuración de esta regla de plan de marcación. La tabla no permite dominios comodín, requiere una coincidencia completa.

Nota: si no tiene ningún dominio coincidente de llamadas entrantes configurado, CMS acepta todos los URI entrantes de las llamadas SIP o Lync que aterrizan en el callbridge. Para los clientes de CMA (WebRTC o cliente pesado), aunque acepta la llamada, no se enruta al espacio o usuario correcto automáticamente. Por lo tanto, es importante introducir el dominio correcto cuando utilice el cliente CMA para marcar a espacios o usuarios en este caso.

Por ejemplo, en la imagen se muestra una tabla de coincidencia de llamadas (sólo muestra la opción Espacios de destino y Usuarios de destino para mayor brevedad):

Aquí el dominio se configura como acano.steven.lab que los clientes marcan normalmente. Sin embargo, también permite llamadas ad-hoc o patrones de ruta SIP específicos de CUCM (o reglas de búsqueda de Expressway) que solo tienen como destino un callbridge específico (en el caso de un clúster) mediante la primera y la segunda regla de reserva de la tabla que coinciden con la dirección IP del callbridge (10.48.54.160 en este caso) o el nombre de dominio completamente calificado (FQDN) del callbridge (acano1.acano.steven.lab en este caso).

Paso 2. Tabla de desvío de llamadas entrantes

Si la llamada no se ajustó a ninguna de las reglas de la tabla de correspondencias de llamadas entrantes o si no hubo ninguna coincidencia para que la llamada continúe (por ejemplo, el usuario marcó un URI de espacio incorrecto o no existente), pasará por la segunda tabla denominada tabla de reenvío de llamadas. También se basa únicamente en dominios y permite bloquear específicamente las llamadas a determinados dominios o permitir únicamente llamadas a determinados dominios. Si desea hacer esto, es importante tener reglas más específicas con una prioridad más alta, por lo que se comprueban primero.

Este ejemplo muestra que las llamadas a dummy.com se rechazan, mientras que las llamadas a tplab.local se reenvían:

Si deja en blanco la tabla de desvío de llamadas, se producirá un estado en el que CMS no actúa como gateway entre los participantes de Skype y SIP, por ejemplo, ya que no existe ninguna regla de desvío de llamadas. Suponiendo que el dominio de la llamada entrante no coincide en la tabla de coincidencia de llamadas entrantes o que el dominio coincide pero no hay coincidencia en los espacios, usuarios o IVR (o reuniones de Skype), la llamada no se reenvía con respecto a la tabla de llamadas salientes.

Nota: Esto sucede con los clientes CMA (clientes robustos y WebRTC), ya que pueden realizar llamadas salientes (*Web App en 3.0 no puede realizar llamadas salientes, sino llamadas realizadas por el espacio CMS fuera por Callbridge). Del mismo modo, las llamadas salientes en CMS también funcionan bien cuando se realizan a través de la API, por ejemplo (en el caso de las conferencias programadas de TMS). En general, las llamadas que se inician desde el propio CMS (ya sea directamente o a través de CMA) no deben seguir la lógica de desvío de llamadas.

En el registro de eventos, puede ver el mensaje de reenvío resaltado como por ejemplo cuando CMS actúa como una gateway para llamadas SIP y Skype. Justo antes de eso, puede ver la llamada entrante y la llamada saliente después.

2018-10-04  06:36:24.612  Info     call 788: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  06:36:24.624  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@any.com'
2018-10-04  06:36:24.625  Info     call 789: outgoing SIP call to "stejanss@any.com"

Si la tabla de reenvío no tiene ninguna regla o una regla de rechazo, el registro de eventos no lo muestra explícitamente. Simplemente le informa de que la llamada SIP no coincide (ningún espacio, usuario, IVR o reunión de Lync) y de que no cumple la regla de reenvío (o está configurada para rechazarse) para pasar a la sección de reglas salientes.

2018-10-04  06:47:12.482  Info     call 790: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  06:47:12.495  Info     call 790: ending; local teardown, destination URI not matched - not connected after 0:00

En el caso de las llamadas de clientes de CMA o las llamadas salientes de CMS que se inician a través de reuniones programadas de TMS, no se ve ninguna llamada entrante en el registro de eventos. La llamada se dirige inmediatamente a la tabla de plan de marcación saliente y la tabla de desvío de llamadas no la procesa.

En la tabla de desvío de llamadas, existen otras dos opciones de configuración: Reescritura de dominio e ID de la persona que llama.

Reescribir dominio

Esta opción le permite reescribir el dominio de la llamada entrante en uno diferente y cambia la parte de dominio del URI de solicitud SIP así como el encabezado To del mensaje SIP.

Por ejemplo, con la configuración de esta imagen, el registro de eventos (con el seguimiento de SIP habilitado) se muestra aquí para una llamada entrante con el dominio any.com pero sin coincidencia en la tabla de coincidencia de llamadas entrantes (ya sea en espacios, usuarios, IVR o conferencias de Skype):

2018-10-04  07:02:24.818  Info     SIP trace: connection 0: incoming SIP TCP data from 10.48.36.215:56457 to 10.48.80.71:5060, size 1000:
2018-10-04  07:02:24.818  Info     SIP trace: INVITE sip:stejanss@any.com SIP/2.0
2018-10-04  07:02:24.818  Info     SIP trace: Via: SIP/2.0/TCP 10.48.36.215:5060;branch=z9hG4bK53e4c4ce29394
2018-10-04  07:02:24.818  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=742103~ee545a46-516a-4de6-87d7-7b1f5a5b848a-26001856
2018-10-04  07:02:24.818  Info     SIP trace: To: <sip:stejanss@any.com>
..
2018-10-04  07:02:24.822  Info     call 797: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-04  07:02:24.834  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@newany.com'
2018-10-04  07:02:24.835  Info     call 798: outgoing SIP call to "stejanss@newany.com"
..
2018-10-04  07:02:24.838  Info     SIP trace: connection 19: outgoing SIP TCP data to 10.48.36.215:5060 from 10.48.80.71:57854, size 3286:
2018-10-04  07:02:24.838  Info     SIP trace: INVITE sip:stejanss@newany.com SIP/2.0
2018-10-04  07:02:24.838  Info     SIP trace: Via: SIP/2.0/TCP 10.48.80.71:5060;branch=z9hG4bKefc98b81a2961b37aee24f03c2142d8e
2018-10-04  07:02:24.839  Info     SIP trace: Call-ID: 18644f28-e998-4032-a7df-75325e9d11b0
2018-10-04  07:02:24.839  Info     SIP trace: CSeq: 659590315 INVITE
2018-10-04  07:02:24.839  Info     SIP trace: Max-Forwards: 70
2018-10-04  07:02:24.839  Info     SIP trace: Contact: <sip:1060@10.48.80.71;transport=tcp>
2018-10-04  07:02:24.839  Info     SIP trace: To: <sip:stejanss@newany.com>
2018-10-04  07:02:24.839  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=2aa2a49bba231a1b

En esta línea de desvío de llamadas, se muestra la modificación que se ha producido. En caso de que no tenga habilitada la traza SIP, todavía muestra la modificación de any.com a newany.com.

El uso más común de esta reescritura del dominio viene con una integración in situ de Lync con un clúster de CMS donde se recomienda establecer el encabezado de contacto y el encabezado De en las reglas salientes de Lync/Skype en los nombres de dominio completos (FQDN) específicos de callbridge. Esto se debe a estas reglas de ruteo:

• Skype envía nuevas transacciones dentro de un diálogo (como por ejemplo un ACK después de un INVITE - 200 OK) al encabezado Contact especificado en el 200 OK que recibió del CMS. Para las conexiones entrantes de Skype a CMS, Skype primero envía un mensaje NEGOTIATE SIP que contiene un encabezado ms-fe en el encabezado To que especifica cómo debe completarse el encabezado Contact en las respuestas 200 OK en el INVITE (ya que utiliza el mismo canal TCP)
• Skype envía nuevos diálogos (como compartir contenido, ya que se trata de una llamada independiente o una devolución de llamada en caso de llamada perdida) al encabezado From del mensaje INVITE original

A medida que vuelve a escribir el dominio, es relevante para la devolución de llamada de las llamadas de Lync. El encabezado From del mensaje INVITE perdido, apunta al callbridge específico de donde proviene la llamada. A continuación, Lync envía una nueva solicitud (INVITE) con un URI de solicitud SIP que coincide con el FQDN de callbridge. Luego se traduce al dominio SIP a través de estas reglas de reescritura. Una vez que se reenvía la llamada, utiliza las reglas de salida hacia CUCM o Expressway-C, donde se registra el terminal SIP.

ID de llamada

Aquí hay dos opciones que se pueden establecer en las reglas de reenvío. Se configura para pasar y, a continuación, no se realiza ninguna modificación en el encabezado De de las INVITACIONES salientes o se configura para utilizar el plan de marcación, que permite al sistema modificar el encabezado De según las reglas salientes. Esta configuración es independiente del hecho de si tiene una reescritura del dominio, ya que solo se refiere a la URI de la solicitud SIP así como al encabezado To del mensaje INVITE saliente.

Por ejemplo, se realizó la misma llamada que antes, pero ahora hay una regla de plan de marcación saliente para newany.com (como después de la reescritura en la tabla de reenvío de llamadas entrantes) configurada como llamada de tipo Lync (Ms-Conversation-ID como encabezado SIP adicional, por ejemplo). Apropiadamente, el dominio de origen local (y el dominio de contacto local) se completan para señalar al FQDN de callbridge como se indicó anteriormente para las llamadas de Lync. Esto refleja el cambio en el encabezado From y Contact del SIP INVITE saliente. Como se muestra en la imagen, se rellenan con el mismo valor y se pueden seleccionar individualmente según sus necesidades.

2018-10-12  09:09:24.488  Info     SIP trace: connection 28: incoming SIP TCP data from 10.48.36.215:44460 to 10.48.80.71:5060, size 1000:
2018-10-12  09:09:24.489  Info     SIP trace: INVITE sip:stejanss@any.com SIP/2.0
2018-10-12  09:09:24.489  Info     SIP trace: Via: SIP/2.0/TCP 10.48.36.215:5060;branch=z9hG4bKf4a230ec178e
2018-10-12  09:09:24.489  Info     SIP trace: From: "EX60 Steven" <sip:1060@steven.lab>;tag=118288~ee545a46-516a-4de6-87d7-7b1f5a5b848a-32900729
2018-10-12  09:09:24.489  Info     SIP trace: To: <sip:stejanss@any.com>
2018-10-12  09:09:24.489  Info     SIP trace: Call-ID: 81e67f80-bc0164c4-f2c6-d724300a@10.48.36.215

2018-10-12  09:09:24.494  Info     call 803: incoming SIP call from "sip:1060@10.48.36.215" to local URI "sip:stejanss@any.com"
2018-10-12  09:09:24.506  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@newany.com'
2018-10-12  09:09:24.507  Info     call 804: outgoing SIP call to "stejanss@newany.com" (Lync)

2018-10-12  09:09:24.507  Info     SIP trace: connection 33: allocated for outgoing connection to 10.48.36.46:5060
2018-10-12  09:09:24.508  Info     SIP trace: connection 33: outgoing connection successful, 10.48.80.71:39782 to 10.48.36.46:5060
2018-10-12  09:09:24.510  Info     SIP trace: connection 33: outgoing SIP TCP data to 10.48.36.46:5060 from 10.48.80.71:39782, size 2971:
2018-10-12  09:09:24.510  Info     SIP trace: INVITE sip:stejanss@newany.com SIP/2.0
2018-10-12  09:09:24.510  Info     SIP trace: Via: SIP/2.0/TCP 10.48.80.71:5060;branch=z9hG4bK15bdde97ab641b586f162187cfdd98b5
2018-10-12  09:09:24.510  Info     SIP trace: Call-ID: c366ddaf-e602-4fa5-b1d6-2e16ec08534a
2018-10-12  09:09:24.510  Info     SIP trace: CSeq: 1498747095 INVITE
2018-10-12  09:09:24.510  Info     SIP trace: Max-Forwards: 70
2018-10-12  09:09:24.510  Info     SIP trace: Contact: <sip:1060@callbridgefqdn.any.com;transport=tcp>
2018-10-12  09:09:24.510  Info     SIP trace: Ms-Conversation-ID: 3P5Hu8grR1GGDF1BSMZAmw==
2018-10-12  09:09:24.510  Info     SIP trace: To: <sip:stejanss@newany.com>
2018-10-12  09:09:24.510  Info     SIP trace: From: "EX60 Steven" <sip:1060@callbridgefqdn.any.com>;tag=fb4ae780677e9d9b

En caso de que la regla de reenvío se establezca en pass through, no habrá ninguna modificación en el encabezado From, como se ha visto también en el ejemplo anterior (en cuyo caso pass through se estableció en la regla de reenvío). El encabezado de contacto siempre se adapta cuando CMS inicia un nuevo callLeg y, por lo tanto, debe agregarse un encabezado de contacto a sí mismo.

Se pueden utilizar diferentes combinaciones de ID de llamante y Dominio de contacto local y Dominio de origen local. El encabezado From del SIP INVITE saliente se construye tal como se muestra en la tabla donde la llamada entrante ingresa al CMS con un encabezado From de usera@from.com.

Paso 3. Tabla de llamadas salientes

Esta es la última tabla en la lógica de ruteo de llamadas que hace la llamada a un servidor diferente como:

• La llamada entrante no se controla localmente (en el dominio coincidente de la llamada entrante).
• Recibe una llamada saliente desde un espacio CMS (a través de CMA o de la API en caso de reuniones programadas de TMS, por ejemplo, o una llamada saliente indicada por Cisco Meeting Manager (CMM)) o desde un cliente CMA.

En la imagen, se puede ver que la lógica es relativamente fácil. Si no hay ninguna entrada en la tabla, todavía permite llamadas salientes pero asume que el servidor CMS puede resolver en los registros SRV SIP (_sips._tcp / _sip._tcp / _sip._udp) para ese dominio en particular como se menciona en el URI de la solicitud SIP. Si la tabla no está vacía, pero el dominio marcado no coincide, se realiza la misma lógica de búsqueda de DNS. Si hay una coincidencia en el dominio, entonces sigue la lógica de esa regla en particular. En este sentido, si desea bloquear las llamadas salientes desde CMA o realizadas a través de TMS o CMM, puede hacerlo de dos maneras. No tiene registros DNS SRV (o no se puede resolver mediante CMS) o enrute esas llamadas al control de llamadas (CUCM o Expressway, por ejemplo) y bloquee las llamadas allí.

La imagen muestra un ejemplo de tabla de llamadas salientes:

Con una <match all domains> regla general al final y la primera regla al dominio de steven.lab sin SIP Proxy a utilizar completado (por lo que depende de los registros DNS SRV para ello).

Tenga en cuenta que se trata de una lista ordenada con un valor de prioridad superior que se trata en primer lugar. En caso de que coincida con una regla con el Comportamiento establecido en Detener, la llamada no pasa por el resto de la tabla después de esa coincidencia y la llamada ha fallado si ese Proxy SIP no pudo rutear la llamada, por ejemplo. Si la configuración se establece en Continuar, puede permitir una reserva a una ruta o nodo diferente del clúster. Por ejemplo, puede especificar un proxy SIP diferente para cada regla en el mismo dominio. 

La configuración de Dominio de contacto local y Dominio de origen local se trata en la sección anterior de la tabla de reenvío de llamadas entrantes. El tipo de enlace troncal permite especificar qué tipo de llamada se debe realizar, que puede ser SIP estándar, Lync o Avaya, que depende del sistema receptor.

El campo Encryption determina si la señalización de la llamada debe ser descifrada o cifrada. Sin embargo, tenga en cuenta que esto no implica ningún cifrado de medios, ya que se establece en la configuración de cifrado de medios SIP, como se encuentra en el menú Configuración > Configuración de llamada. En esta configuración, también tiene la opción de seleccionar Auto (Automático), que intenta realizar la llamada primero con una señalización cifrada con un posible repliegue a una señalización no cifrada. Si sabe de antemano que el otro lado está encriptado o no, se recomienda definirlo en consecuencia para evitar cualquier retraso en la configuración de llamadas debido al proceso de repliegue.

Una salida de ejemplo del archivo de registro para una llamada a steven.lab (después de la reescritura del dominio en la tabla de reenvío de llamadas entrantes), con traza DNS y traza SIP establecidos en detailed, muestra los registros SRV que se consultan y el mecanismo de reserva en caso de que el cifrado se establezca en Auto.

2018-10-12  11:25:16.168  Info     call 821: incoming SIP call from "sip:1060@steven.lab" to local URI "sip:stejanss@any.com"
2018-10-12  11:25:16.179  Info     forwarding call to 'sip:stejanss@any.com' to 'stejanss@steven.lab'
2018-10-12  11:25:16.180  Info     call 822: outgoing SIP call to "stejanss@steven.lab"

2018-10-12  11:25:16.180  Info     DNS trace: resolving "steven.lab" (SRV "_sips._tcp", dnsType:1) for call 822
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 returned result, addresses: 1
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 succeeded; results: 1
2018-10-12  11:25:16.181  Info     DNS trace: resolution of "steven.lab" (SRV "_sips._tcp") for call 822 using 10.48.36.215:5061
2018-10-12  11:25:16.181  Info     SIP trace: connection 45: allocated for outgoing encrypted connection to 10.48.36.215:5061
2018-10-12  11:25:16.201  Info     handshake error 336151576 on outgoing connection 45 to 10.48.36.215:5061 from 10.48.80.71:54864
2018-10-12  11:25:16.201  Info     SIP trace: connection 45: shutting down...

2018-10-12  11:25:16.201  Info     call 822: falling back to unencrypted control connection...

2018-10-12  11:25:16.201  Info     DNS trace: resolving "steven.lab" (SRV "_sip._tcp", dnsType:1) for call 822
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 returned result, addresses: 1
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 succeeded; results: 1
2018-10-12  11:25:16.202  Info     DNS trace: resolution of "steven.lab" (SRV "_sip._tcp") for call 822 using 10.48.36.215:5060
2018-10-12  11:25:16.202  Info     SIP trace: connection 46: allocated for outgoing connection to 10.48.36.215:5060
2018-10-12  11:25:16.203  Info     SIP trace: connection 46: outgoing connection successful, 10.48.80.71:59776 to 10.48.36.215:5060
2018-10-12  11:25:16.205  Info     SIP trace: connection 46: outgoing SIP TCP data to 10.48.36.215:5060 from 10.48.80.71:59776, size 3290:
2018-10-12  11:25:16.205  Info     SIP trace: INVITE sip:stejanss@steven.lab SIP/2.0

Nota: En el caso de un entorno agrupado con varios callbridges, puede configurar reglas de plan de marcado saliente por callbridge cuando lo configura a través de la API y especifica en el objeto API un ID de callbridge (o ID de grupo de callbridge). Suponga, por ejemplo, que desea que todas las llamadas salgan de un callbridge determinado para un dominio determinado (por ejemplo, cuando marca a us.example.com, le gustaría que salieran de sus servidores basados en US). A continuación, asegúrese de que tiene una configuración de API para las reglas del plan de marcación saliente para que cada callbridge distinto del basado en US pueda rutear la llamada al callbridge de US (en este ejemplo).

OutboundDialPlanRule (para callbridge de US)

• domain = us.example.com
• sipProxy = <vacío al utilizar DNS SRV / IP o FQDN si se establece manualmente>
• scope = callbridge
• callbridge = <UScallbridge-ID>

OutboundDialPlanRules (para todos los callbridges que no sean de EE.UU. y que deben permitir realizar esa llamada) (se necesita uno por callbridge)

• domain = us.example.com
• sipProxy = <IP-or-FQDN-of-US-Callbridge>
• scope = callbridge
• callbridge = <non-US-callbridge-ID>

Verificación 

Actualmente, no hay un procedimiento de verificación disponible para esta configuración.

Troubleshoot 

Actualmente no hay información específica de solución de problemas disponible para esta configuración.

Información Relacionada

• Soporte Técnico y Documentación - Cisco Systems
• Herramienta Analizador de soluciones de colaboración 
• documentación de CMS

---

NOTA: Para obtener ejemplos de configuración, consulte estas guías:

• Configuración e integración de la guía única combinada de CMS
• Guía de configuración de Cisco Meeting Server y CUCM