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

Introducción

Este documento describe la lógica de enrutamiento de llamadas de Cisco Meeting Server (CMS) (antes producto Acano), que se divide en varias tablas de enrutamiento de llamadas. Este documento cubre las diferentes etapas y escenarios que las llamadas pueden realizar 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.

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.

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

El ruteo de llamadas en CMS implica unas pocas tablas diferentes de ruteo de llamadas. Con el diagrama de flujo que se puede descargar , puede seguir la lógica de enrutamiento de llamadas para cada llamada que llega a CMS. Esto es válido para todos los tipos de llamadas: Cisco Meeting App (CMA - cliente grueso 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 (bien para las llamadas salientes programadas de TelePresence Management Suite (TMS) o bien para las llamadas salientes del cliente CMA) en las que se omite la tabla de reenvío de llamadas.

Este es el orden del proceso de ruta de llamada dentro de CMS: 

1. Tabla de coincidencia de llamadas entrantes
2. Tabla de reenvío de llamada entrante
3. Tabla de llamadas salientes

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

Nota: CMS solo realiza el enrutamiento de llamadas basándose en el enrutamiento de dominio, por lo que se basa en el lado derecho (RHS) del identificador uniforme de recursos (URI). No hay funcionalidad de enrutamiento de llamadas basada en el lado izquierdo (LHS) del URI, como en Cisco Unified Communications Manager (CUCM) con routing DirectoryNumber (patrones de ruta).

Nota: Cada tabla es una lista ordenada establecida por el atributo de prioridad. Una prioridad más alta significa que se intenta hacer coincidir 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 esta manera, las reglas específicas se manejan primero y usted tiene el repliegue potencialmente a las reglas más generales.

Paso 1. Tabla de coincidencia de llamadas entrantes

Este es el primer paso en el proceso en el que CMS determina si la llamada entrante está destinada al propio Cisco Meeting Server y tendría que procesarla más o si se trata de una llamada destinada a un sistema diferente en el que CMS es el agente que intertrabaja la llamada y maneja tanto los medios como la señalización (p.ej. El gateway de Skype llama a los terminales SIP estándar o viceversa).

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

Nota: Si no tiene ninguna llamada entrante que coincida con los dominios configurados, CMS acepta todos los URI entrantes de las llamadas SIP o Lync que llegan a la callbridge. Para los clientes CMA (WebRTC o cliente grueso), aunque acepta la llamada, no se enruta automáticamente al espacio o usuario correcto. Por lo tanto, es importante ingresar en 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 la brevedad):

Aquí el dominio se configura como acano.steven.lab que los clientes normalmente marcan. 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 sólo tienen como destino un callbridge específico (en caso de un clúster) por la primera y 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 completo (FQDN) del callbridge acano1.acano.steven.lab en este caso).

Paso 2. Tabla de reenvío de llamada entrante

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

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

Cuando deja en blanco la tabla de desvío de llamadas, esto produce un estado en el que CMS no actúa como gateway entre participantes de Skype y SIP, por ejemplo, ya que no hay ninguna regla de reenvío de llamadas. En el supuesto de 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 Skype), la llamada no se reenvía con respecto a la tabla de llamadas salientes.

Nota: Esto sucede sin embargo con los clientes CMA (clientes gruesos y WebRTC), ya que pueden realizar llamadas salientes (*Aplicación web en 3.0 no puede realizar llamadas salientes, sino más bien llamadas realizadas por el espacio CMS fuera de Callbridge). De manera similar, las llamadas salientes en CMS funcionan bien también cuando se realizan a través de API, por ejemplo (en el caso de las conferencias programadas de TMS). En general, las llamadas que se inician desde el propio CMS (directamente o a través de CMA) no deben seguir la lógica de reenvío de llamadas.

En el registro de eventos, puede ver el mensaje de reenvío resaltado como, por ejemplo, cuando CMS actúa como gateway para las 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 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 que se ha perdido la regla de reenvío (o está configurada para rechazarla) 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

Para las llamadas de clientes 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 no se procesa en la tabla de reenvío de llamadas.

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

Reescritura del dominio

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

Por ejemplo, con la configuración en esta imagen, el registro de eventos (con el seguimiento SIP habilitado) se muestra aquí para una llamada entrante con el dominio any.com pero sin una coincidencia en la tabla de coincidencia de llamadas entrantes (en espacios, usuarios, conferencias IVR o 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 llamada de reenvío, muestra la modificación que ha ocurrido. En caso de que no tenga el seguimiento de SIP habilitado, 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 de Lync in situ con un clúster de CMS donde se recomienda establecer el encabezado de contacto y el encabezado De en las reglas salientes a 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 (por ejemplo, un ACK después de una INVITE - 200 OK) al encabezado Contact especificado en el 200 OK que recibió del CMS.  Para las conexiones entrantes de Skype a CMS, Skype envía primero un mensaje NEGOTIATE SIP que contiene un encabezado ms-fe en el encabezado To, que especifica cómo se debe rellenar el encabezado Contact en las respuestas 200 OK en INVITE (ya que utiliza el mismo canal TCP)
• Skype envía nuevos diálogos (como el uso compartido de contenido, ya que se trata de una llamada independiente, o una devolución de llamada en caso de una 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 desde las llamadas de Lync. El encabezado From de la INVITE perdida, señala al callbridge específico de donde proviene la llamada. Lync envía una nueva solicitud (INVITE) con el 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 reenviada la llamada, utiliza las reglas de salida hacia CUCM o Expressway-C donde se registra el extremo SIP.

ID de la persona que llama

Aquí hay dos opciones que se pueden establecer en las reglas de reenvío. Se configura para pasar y luego no se realiza ninguna modificación en el encabezado From de los INVITE salientes o se configura para utilizar el plan de marcación que permite al sistema modificar el encabezado From según las reglas salientes. Esta configuración es independiente del hecho de si tiene una reescritura del dominio, ya que sólo se refiere al URI de solicitud SIP y al encabezado A de la INVITE saliente.

A modo de 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). De forma adecuada, el dominio local de origen (y el dominio de contacto local) se rellenan para indicar el FQDN de callbridge como se indicó anteriormente para las llamadas de Lync. Esto luego refleja el cambio en el encabezado From and Contact del SIP INVITE saliente. Como se muestra en la imagen, se rellenan con el mismo valor y se pueden seleccionar individualmente según los requisitos.

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 paso a paso, no habría ninguna modificación en el encabezado From, como se ve también en el ejemplo anterior (en cuyo caso se estableció el paso a través en la regla de reenvío). El encabezado de contacto siempre se adapta a medida que CMS inicia una nueva llamadaLeg y, por lo tanto, debe agregarse un encabezado de contacto a sí mismo.

Se pueden utilizar diferentes combinaciones de ID de la persona que llama y dominio de contacto local y dominio local desde. El encabezado From en el SIP INVITE saliente se construye como se muestra en la tabla donde la llamada entrante ingresa en el CMS con un encabezado From de usera@from.com.

Paso 3. Tabla de llamadas salientes

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

• La llamada entrante no se gestiona localmente (en el dominio de coincidencia de llamada entrante).
• Se trata de una llamada saliente desde un espacio de CMS (a través de CMA o mediante API en el caso de reuniones programadas de TMS, por ejemplo, o de una llamada saliente impartida por Cisco Meeting Manager (CMM)) o desde un cliente de CMA.

A partir de 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 de SIP (_sips._tcp / _sip._tcp / _sip._udp) para ese dominio en particular como se menciona en el URI de solicitud de SIP. Si la tabla no está vacía, pero no hay coincidencia para el dominio marcado, 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 de CMA o como se hacen a través de TMS o CMM, puede hacerlo de dos maneras. No tiene registros DNS SRV (o CMS no puede resolverlos) ni enruta esas llamadas al control de llamadas (CUCM o Expressway, por ejemplo) y bloquea las llamadas allí.

La imagen muestra una tabla de llamadas salientes de ejemplo:

Con una regla general <match all dominios> al final y la primera regla al dominio de steven.lab sin un proxy SIP para usar relleno (por lo que depende de los registros SRV de DNS para ello).

Tenga en cuenta que se trata de una lista ordenada con un valor de prioridad superior que se cubre primero. En caso de que coincida una regla con el parámetro Behavior establecido en Stop, la llamada no pasará por el resto de la tabla después de esa coincidencia y la llamada falló si ese proxy SIP no pudo rutear la llamada, por ejemplo. Cuando esa configuración se establece en Continue, puede permitir una reserva a una ruta diferente o a un nodo diferente en el clúster. Por ejemplo, puede especificar un proxy SIP diferente para cada regla en el mismo dominio. 

La configuración de Local Contact Domain y Local From Domain se tratan en la sección anterior de la tabla de reenvío de llamadas entrantes. El tipo Trunk permite especificar qué tipo de llamada debe realizarse, 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 estar descifrada o cifrada. Sin embargo, tenga en cuenta que esto no implica ningún cifrado de medios, ya que está configurado 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 una posible reserva a una señalización no cifrada. Si sabe desde el principio que el otro lado está cifrado o no, se recomienda encarecidamente definirlo en consecuencia para evitar cualquier retraso en la configuración de la llamada debido al proceso de repliegue.

Un ejemplo de salida del archivo de registro para una llamada a steven.lab (después de reescribir el dominio en la tabla de reenvío de llamadas entrantes), con el seguimiento DNS y el seguimiento de SIP configurados en detalle, nos muestra los registros SRV que se consultan y el mecanismo de reserva en caso de que el cifrado esté configurado 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 especificar en el objeto de la API un ID de callbridge (o ID de callbridgeGroup). Suponga, por ejemplo, que desea que todas las llamadas salgan de un callbridge concreto para un dominio determinado (por ejemplo, cuando se marca a us.ejemplo.com, le gustaría que saliera de sus servidores basados en EE. UU.). A continuación, asegúrese de que tiene una configuración de API para las reglas de plan de marcaciónSaliente de modo que el puente de llamada distinto del basado en US pueda enrutar la llamada al puente de llamadas de US (en el caso de este ejemplo).

OutboundDialPlanRule (para US callbridge)

• dominio = us.example.com
• sipProxy = <vacío cuando se utiliza 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. que deben permitir realizar esa llamada) (necesita uno por callbridge)

• dominio = us.example.com
• sipProxy = <IP-o-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

---

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

• Configuración e integración de CMS Single Combined Guide
• Configurar Cisco Meeting Server y la guía de CUCM