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 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.
Cisco recomienda que tenga conocimiento sobre estos temas:
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.
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:
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.
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).
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.
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:
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.
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.
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:
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)
OutboundDialPlanRules (para todos los callbridges que no sean de EE.UU. que deben permitir realizar esa llamada) (necesita uno por callbridge)
Actualmente, no hay un procedimiento de verificación disponible para esta configuración.
Actualmente no hay información específica de solución de problemas disponible para esta configuración.
NOTE: Para obtener ejemplos de configuración, consulte estas guías:
Revisión | Fecha de publicación | Comentarios |
---|---|---|
1.0 |
30-Sep-2021 |
Versión inicial |