Explicación del routing de llamadas de Cisco IOS e IOS XE

Introducción

En este documento se explica el routing de llamadas de Cisco IOS® y Cisco IOS XE.

Prerequisites

Requirements

Si bien no se necesitan requisitos formales para leer este documento, se escribe con la expectativa de que el lector ya tiene algún conocimiento de los protocolos de señalización de voz subyacentes que se utilizan para establecer y conectar llamadas telefónicas. Se hace referencia a estos protocolos muchas veces.

Protocolos de señalización: protocolo de inicio de sesión (SIP), H323 (h225 / h245), protocolo de control de gateway de medios (MGCP), protocolo de control de cliente ligero (SCCP), ISDN Q931, E1 R2.

Protocolos de medios: protocolo en tiempo real (RTP), códecs de voz y de vídeo.

Tecnologías analógicas: oído y boca (E&M), suscriptor de intercambio remoto (FXS) y oficina de intercambio remoto (FXO).

Componentes Utilizados

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

• Gateways Cisco IOS e IOS XE
• 2800 / 3800 / 2900 / 3900 / 4300 / 4400 / CSR1000v / CAT8000v / ASR100X / C8200 / C8300 / ISR1100

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.

Antecedentes

Este documento aborda los mecanismos detrás de la coincidencia de pares de marcado entrantes y salientes con tramos de llamadas de red de servicio telefónico básico (POTS) y voz sobre IP (VoIP).

Además de la información de dial-peer, este documento cubre temas importantes que pertenecen al ruteo de llamadas. Estos incluyen la manipulación de dígitos, una descripción general rápida de la manipulación de mensajes del protocolo de inicio de sesión (SIP), algunos métodos para restringir las capacidades de llamada, una descripción general rápida de enlaces de medios y señalización y, por último, un poco de solución de problemas.

Este documento utiliza ejemplos de configuración, así como resultados de los comandos debug y show como puntos de referencia. Las numerosas funciones de este documento están claramente marcadas con la versión que la función se introdujo tanto en Cisco IOS como en Cisco IOS XE. También se puede hacer referencia a esta información rápidamente en la sección Mapa de Ruta de Comandos y Funciones. Si hay un defecto muy notable, se enlaza dentro del texto para que los lectores sean conscientes.

Definiciones comunes

Guía de comandos y funciones

Fundamentos del enrutamiento de llamadas de Cisco IOS / Cisco IOS XE

Los gateways Cisco IOS y Cisco IOS XE utilizan un concepto de par de marcado para controlar el ruteo de llamadas y la negociación de capacidades para cada tramo de una llamada. Un tramo de llamada es la comunicación bidireccional entre dos agentes de llamada. Un agente de llamadas es un dispositivo que inicia, procesa o reenvía llamadas telefónicas. Esto puede ser, y no está limitado a, un equipo de proveedor de telefonía, una puerta de enlace de Cisco, un teléfono IP, un Cisco Unified Communication Manager (CUCM), una conexión de Cisco Unity (CUC), etc. Hay demasiados agentes de llamadas para incluir en la lista.

Escenario: una llamada llega a un gateway de Cisco desde otro agente de llamada y es el tramo de llamada entrante (en tramo). La puerta de enlace procesa la llamada y, en función de su procesamiento, envía la llamada al siguiente agente de llamadas. Este es el tramo de llamada saliente (tramo saliente).

La imagen 1 muestra una llamada de PSTN a CUCM que se enruta a través de una Cisco Voice Gateway y la información del tramo de llamada entrante y saliente respectiva.

Imagen 1: Tramos de llamadas entrantes y salientes ilustrados

Una llamada correcta a través de una puerta de enlace Cisco ALWAYS (consulte la nota) coincide con un dial-peer entrante o saliente para enrutar correctamente. Los pares de marcado entrantes y salientes son similares a los tramos de llamada mencionados anteriormente. En la Imagen 1, la llamada llega desde la PSTN a la puerta de enlace de Cisco y debe coincidir con un par de marcado entrante. A continuación, la puerta de enlace utiliza un par de marcado saliente para enrutar la llamada al siguiente agente de llamadas. Es importante recordar que estos términos se definen desde la perspectiva de Cisco Gateway.

Al hacer coincidir un par de marcado para cada lado de la llamada, un administrador tiene el poder de controlar muchos aspectos de cada tramo de llamada específico. Algunos ejemplos son los códecs de voz, las preferencias de DTMF, la manipulación de dígitos, dónde se debe enrutar la llamada y muchos otros ajustes. Los pares de marcado se pueden configurar con sentencias de coincidencia entrantes y salientes, de modo que es posible hacer coincidir el mismo par de marcado tanto para el segmento entrante como para el saliente si se aplica una configuración de coincidencia entrante y saliente válida a ese par de marcado específico.

La imagen 2 ilustra los mismos tramos de llamada entrante y saliente que la imagen 1, pero con los pares de marcado respectivos para una llamada desde la PSTN a CUCM que se enruta a través de una Cisco Voice Gateway.

Imagen 2: pares de marcado entrantes y salientes ilustrados

Los gateways de voz de Cisco pueden interactuar con muchos tipos diferentes de llamadas y protocolos de voz, incluidos IP a IP, POTS a POTS e IP a POTS o viceversa.

La imagen 3 ilustra una llamada VoIP a VoIP a través de Cisco Unified Border Element (CUBE).

Imagen 3: pares de marcado entrantes y salientes para una llamada de VoIP a VoIP

La imagen 4 muestra una llamada de POTS a POTS a través de una gateway de Cisco.

Imagen 4: pares de marcado entrantes y salientes para una llamada de POTS a POTS

Tipos de pares de marcado de voz

Nota: El número máximo de pares de marcado que se pueden configurar en una gateway de Cisco depende de la memoria disponible (DRAM). Cada par de marcado consume aproximadamente 6 KB de memoria, por lo que debe asegurarse de que el gateway tenga al menos el 20% de la memoria total reservada para otros procesos de la CPU. Un gran número de pares de marcado configurados puede agregar al retardo para rutear una llamada. Esto puede ser significativo ya que la aplicación de voz de Cisco mira a través de pares de marcado de arriba hacia abajo, de manera similar a una lista de control de acceso (ACL). Esto no suele ser un problema en las gateways de Cisco más recientes.

Error de ejemplo:

May 26 12:59:46.406: %DIALPEER_DB-3-ADDPEER_MEM_THRESHOLD: Addition of dial-peers limited by available memory

Coincidencia de par de marcado entrante

Cuando una puerta de enlace de Cisco recibe una solicitud de configuración de llamada, la puerta de enlace comienza a buscar un par de marcado entrante aplicable para esta llamada. Este no es un análisis dígito por dígito; más bien, el mensaje completo se utiliza para determinar qué dial-peer entrante está seleccionado. El orden de los elementos del mensaje comprobado depende en gran medida del protocolo de la llamada, como indican las listas de preferencias definidas en la tabla 1, la tabla 2 y la tabla 3. Un par de marcado sólo necesita satisfacer una de las condiciones para la coincidencia. No es necesario que todos los atributos estén configurados en el par de marcado y que cada atributo coincida con la información de configuración de llamadas. Todos los pares de marcado se buscan según los primeros criterios de coincidencia. La puerta de enlace pasa a los criterios siguientes sólo si no se encuentra ninguna coincidencia.

Tabla 1. Preferencia de selección de par de marcado SIP entrante

Nota: Los dial-peers entrantes elegibles se pueden filtrar por VRF o Arrendatario. si se configura la función aplicable. Para obtener más información, vea las secciones Enrutamiento y reenvío virtuales (VRF) y Búsqueda de pares de marcado y Arrendatarios de clase de voz.

Tabla 2. Preferencia de selección de par de marcado H323 entrante

Tabla 3. Preferencia de selección de par de marcado de POTS de Enbloc entrante

Cuando no existen coincidencias / Dial-Peer predeterminado 0 peer_tag=0, pid:0

Cuando no hay coincidencias elegibles para un par de marcado entrante para llamadas POTS o VoIP, el gateway asigna el par de marcado 0. Esto no es ideal ya que el par de marcado 0 tiene capacidades limitadas y puede causar problemas con las llamadas. El valor atípico de esto son los protocolos SCCP y MGCP que no utilizan pares de marcado para rutear llamadas. Vea la sección MGCP y SCCP para obtener más detalles.

capacidades de dial-peer 0

• No hay mecanismos dtmf-relay.
• Anunció todos los códecs de voz para llamadas VoIP.
• Voz a velocidad de fax.
• La detección de actividad de voz (VAD) está activada.
• Sin compatibilidad con RSVP.
• No hay compatibilidad con la aplicación IVR para llamadas POTS.
• La marcación entrante directa está activada.
• No admite VRF.

Coincidencia de par de marcado saliente

Los pares de marcado salientes se utilizan para rutear llamadas POTS o VoIP desde el gateway al siguiente agente de llamadas. Al igual que la coincidencia de pares de marcado entrante, hay una lista de elementos que la puerta de enlace puede utilizar para hacer coincidir los pares de marcado según el orden de preferencias para el protocolo específico. Sin embargo, a diferencia de los pares de marcado entrantes, si no hay un par de marcado saliente elegible para rutear la llamada, la llamada falla. Al igual que la coincidencia de pares de marcado entrante, se buscan todos los pares de marcado según los primeros criterios de coincidencia. La puerta de enlace pasa a los criterios siguientes sólo si no se encuentra ninguna coincidencia.

Tabla 4. Preferencia de selección de par de marcado SIP saliente

Tabla 5. Preferencia de selección de par de marcado H323 saliente

Tabla 6. Preferencia de selección de par de marcado POTS saliente

Nota: las secciones Búsqueda de par de marcado de cadena de número y Búsqueda de par de marcado URI se centran en cómo la puerta de enlace evalúa una lista de comandos potenciales para cada fila de criterios de coincidencia antes de pasar a los siguientes criterios de coincidencia. Por ejemplo, evalúa todas las posibles coincidencias de destination-pattern y los comandos de coincidencia de destination e164-pattern-map antes de examinar los comandos de número de llamada.

Búsqueda de par de marcado de cadena de número

Preferencia de cadena de número:

Al igual que los URI tienen un orden específico de operaciones para evaluar coincidencias, también hay un conjunto de reglas que se utilizan al evaluar una cadena de dígitos numéricos. El esquema de búsqueda de pares de marcado predeterminado para una gateway de Cisco está configurado en 0. Esto significa que el gateway busca un patrón con la coincidencia más larga (la más específica). Si hay dos pares de marcado con la misma longitud de coincidencia, la puerta de enlace examina la preferencia de par de marcado definida explícitamente. Por último, si ambos son iguales, elige uno en un orden aleatorio.

Existen otros esquemas de búsqueda de pares de marcado disponibles para la configuración; sin embargo, la mayoría de las implementaciones mantienen el valor predeterminado de 0.

Sugerencia: si se están haciendo coincidir los pares de marcado fuera del orden predeterminado, un administrador puede examinar la configuración en ejecución para ver si hay un esquema de búsqueda de pares de marcado no predeterminado.

Gateway(config)# dial-peer hunt ?
  <0-7>  Dial-peer hunting choices, listed in hunting order within each choice:
  0 - Longest match in phone number, explicit preference, random selection.
  1 - Longest match in phone number, explicit preference, least recent use.
  2 - Explicit preference, longest match in phone number, random selection.
  3 - Explicit preference, longest match in phone number, least recent use.
  4 - Least recent use, longest match in phone number, explicit preference.
  5 - Least recent use, explicit preference, longest match in phone number.
  6 - Random selection.
  7 - Least recent use.

Situación: se han configurado pares de marcado elegibles con estas posibles coincidencias y el gateway está evaluando una cadena de dígitos de 2001. El par de marcado 1 puede coincidir con cualquier número entre 2000 y 2999, mientras que el par de marcado 2 puede coincidir entre 2000 y 2009. El par de marcado 2 coincidirá con esta llamada, ya que es la coincidencia más larga (la más específica) para la cadena de dígitos 2001 cuando se emplean los mecanismos de búsqueda de par de marcado predeterminados (búsqueda de par de marcado 0). En otras palabras, la secuencia de números 200 es la secuencia más grande que coincide exactamente con una secuencia de números de la cadena numérica 2001.

!
dial-peer voice 1 voip
 destination-pattern 2...
!
dial-peer voice 2 voip
 destination-pattern 200.
!

La preferencia se define como el peso definido por el administrador para cada par de marcado. Los administradores pueden configurar una preferencia para que la llamada utilice siempre un par de marcado específico antes que los demás. De forma predeterminada, todos los pares de marcado tienen la preferencia 0. Un par de marcado con preferencia 0 coincide antes que otro par de marcado con preferencia 1 a 10. La mayoría de los administradores configuran varios pares de marcado para enviar una llamada a un suscriptor de CUCM específico con un suscriptor de respaldo u otro agente de llamada configurado mediante otro par de marcado con una preferencia menor (que se configura con un número mayor).

Escenario: Dos pares de marcado se configuran con la misma longitud de coincidencia para la cadena de dígitos de 2001. El administrador define una preferencia explícita. El gateway evalúa ambos pares de marcado de la misma manera ya que su longitud de coincidencia es la misma. Sin embargo, el administrador configura el par de marcado 1 con una preferencia más alta para que se elija el par de marcado como el primer par de marcado utilizado en el ruteo de la llamada. El par de marcado 2 permanecería como una opción secundaria si se produce una falla en el primer par de marcado.

!
dial-peer voice 1 voip
 destination-pattern 2...
 preference 1
!
dial-peer voice 2 voip
 destination-pattern 2...
 preference 2
!

Un gateway de Cisco solo intenta enrutar una llamada a través de un dial-peer saliente elegible a la vez. Si se observa una condición de falla en el primer dial-peer seleccionado, el gateway intenta rutear la llamada al siguiente dial-peer elegible. Esto continúa hasta que la llamada se realice correctamente o falle porque ya no quedan más pares de marcado elegibles para intentarlo. Un síntoma común de la búsqueda y la falla del par de marcado es un retraso notable en el tono de llamada mientras se realizan llamadas. Las depuraciones suelen ser necesarias para verificar exactamente por qué falla la llamada en un par de marcado determinado. El comando huntstop se puede emplear en un par de marcado si un administrador no desea que una puerta de enlace busque otro par de marcado cuando se observa una condición de falla.

Escenario: Dos pares de marcado se configuran con la misma longitud de coincidencia para la cadena de dígitos de 2001. El administrador ha definido una preferencia explícita y no desea hacer coincidir el par de marcado 2 para esta llamada en particular. Dado que hay dos pares de marcado con la misma longitud de coincidencia, la preferencia se utiliza para determinar el par de marcado. El par de marcado 1 tiene el número de preferencia configurado más bajo, por lo que se utiliza para enrutar la llamada. Si se produce una condición de falla en el tramo de llamada saliente mediante el par de marcado 1, el gateway detiene inmediatamente la búsqueda del par de marcado ya que se ha configurado el comando huntstop. En este escenario, el par de marcado 2 nunca se utiliza para el ruteo saliente. 

!
dial-peer voice 1 voip
 destination-pattern 2...
 preference 1
 huntstop
!
dial-peer voice 2 voip
 destination-pattern 2...
 preference 2
!

Nota: los comandos huntstop y preference también se pueden utilizar junto con sentencias coincidentes URI, ya que son comandos de configuración de dial-peer generales. Además, las configuraciones de grupos de servidores de clase de voz pueden utilizar los comandos huntstop en 17.4.1a. Consulte la sección Grupos de servidores de destino para obtener más detalles sobre esto.

Búsqueda de pares de marcado URI

El gateway examina cada criterio de coincidencia y lo agota antes de pasar al siguiente criterio de coincidencia. Un ejemplo de esto sería en una llamada SIP entrante. Basado en la Tabla 1. Preferencia de selección de par de marcado SIP entrante, lo primero que verifica el gateway de Cisco es el URI y evalúa todos los comandos URI potenciales para encontrar uno que se ajuste. Si no hay ninguna coincidencia o no se ha configurado ninguna, el gateway se desplaza al siguiente elemento coincidente y realiza una evaluación de acuerdo con esos criterios. Este proceso se repite hasta que la llamada se enruta en función de una coincidencia o el gateway se queda sin criterios de coincidencia para comprobar.

Cuando se configura un par de marcado entrante o saliente con un comando URI, la puerta de enlace examina el URI recibido en varios encabezados en busca de una posible coincidencia. La preferencia de coincidencia se basa en la coincidencia más específica y la preferencia exacta es Coincidencia completa de URI, Parte de host, Parte de usuario o URI de teléfono. Conocer el orden de las operaciones para la coincidencia de URI puede ser de gran ayuda en la coincidencia de dial-peer con las implementaciones de SIP y CUBE.

Este orden de preferencias se puede manipular usando el comando voice class uri sip preference para especificar el user-id como la primera opción en lugar del host.

Preferencia de URI:

1. La parte del host del URI. Ejemplos: (@a.b.c.d o @host.domain.name)
2. La parte User del URI. Ejemplos: (sip:8675309 o sip:user)
3. El tele-uri. Ejemplo: (tel.: 18005532447)
4. Coincidencia exacta para el URI completo. Ejemplos: (user@host.domain.name, user@a.b.c.d, 8675309@host.domain.name, 8675309@host.domain.name)

Documento de apoyo: Guía de configuración de Cisco Unified Border Element - Cisco IOS XE 17.6 en adelante

Situación: un administrador ha configurado estos pares de marcado y envía una llamada al gateway. El encabezado De de la invitación recibida es De: <sip:testuser@10.10.10.10>. El gateway puede coincidir potencialmente con dos pares de marcado diferentes basados en este encabezado. Dial-Peer 1 basado en la parte del usuario y dial-peer 2 basado en la parte del host. Sin embargo, dado que una coincidencia de host es una preferencia sobre una coincidencia de usuario, el par de marcado 2 se utiliza para el par de marcado entrante en la llamada.

!
voice class uri URI1 sip
 user-id testuser 
!
voice class uri URI2 sip
 host ipv4:10.10.10.10
!
dial-peer voice 1 voip
 sess protocol sipv2
 incoming uri FROM URI1
!
dial-peer voice 2 voip
 sess protocol sipv2
 incoming uri FROM URI2
!

URI de clase de voz 

La coincidencia de URI para pares de marcado entrantes y salientes permite a un administrador la capacidad y flexibilidad de realizar coincidencias en más de una cadena de número de teléfono para protocolos VoIP que admiten URI en sus mensajes. Antes de IOS 15.4(1)T e IOS-XE 3.11S, un URI de solicitud debía contener un user@host alfanumérico; de lo contrario, un gateway de Cisco rechazaría la llamada con un mensaje 4xx. Ahora, un URI puede contener solo la parte del host y el gateway enruta la llamada basándose únicamente en el host proporcionado. Por ejemplo, sip:cisco.com.

Además, antes de IOS 15.4(1)T e IOS XE 3.11S voice-class URI user-ids solo podían ser valores numéricos e.164 (sip:1234@host.com). Esto se modificó para que los administradores puedan configurar las ID de usuario alfanuméricas en CUBE (sip:user@host.com).

La parte de host o de usuario de un URI de clase de voz puede contener patrones de expresiones regulares (regex) que expanden en gran medida los valores posibles con los que se pueden establecer coincidencias.

Gateway(config-voice-uri-class)# user-id .)
% unmatched ()user-id pattern can be of format ^([][0-9A-Za-z\|\/()*+^$&?#--.])*$

Gateway(config-voice-uri-class)# host .)
% unmatched ()host pattern can be of format ^([][0-9A-Za-z\|@\/()*+^$&?#--.])*$

Gateway(config-voice-uri-class)# pattern .)
% unmatched ()pattern pattern can be of format ^([][0-9A-Za-z\|@;:=%!~\/()*+^$&?#--.])*$

Ejemplo: URI de clase de voz

!
voice class uri HOST sip
 host webex.com
 host dns:cisco.webex.com
 host ipv4:10.50.244.2
 host ipv6:[2001:4860:4860::8888]
!
voice class uri USER sip
 user-id username
!
voice class uri PATTERN sip
 pattern 8675309
!
voice class uri HostRegex sip
 host (.*)cisco.com
!
voice class uri ipRegex sip
 host 172\.18\.110\.20[567]
!
voice class uri PatternRegex sip
 pattern 555(.*)
!
voice class uri ipRegex sip
 pattern (172\.18\.110\.10[134]|10\.10\.10\.10)
 ! One Line that matches 172.18.110.101, 172.18.110.103, 172.18.110.104 OR 10.10.10.10
!
voice class uri UserRegex sip
 user-id test(.*)
!

Solo se pueden configurar 10 hosts, 1 patrón o 1 id de usuario por URI de clase de voz, como se muestra en este ejemplo. Si es necesario hacer coincidir más elementos, se recomienda utilizar Regex.

Gateway(config)# voice class uri TEST sip
Gateway(config-voice-uri-class)#host ipv4:10.1.1.1
Gateway(config-voice-uri-class)#host ipv4:10.2.2.2
Gateway(config-voice-uri-class)#host ipv4:10.3.3.3
Gateway(config-voice-uri-class)#host ipv4:10.4.4.4
Gateway(config-voice-uri-class)#host ipv4:10.5.5.5
Gateway(config-voice-uri-class)#host ipv4:10.6.6.6
Gateway(config-voice-uri-class)#host ipv4:10.7.7.7
Gateway(config-voice-uri-class)#host ipv4:10.8.8.8
Gateway(config-voice-uri-class)#host ipv4:10.9.9.9
Gateway(config-voice-uri-class)#host ipv4:10.10.10.10
Gateway(config-voice-uri-class)#host ipv4:10.11.11.11
Error:Maximum of 10 hosts can only be configured.
 
Gateway(config)# voice class uri TEST2 sip
Gateway(config-voice-uri-class)#host dns:1.com
Gateway(config-voice-uri-class)#host dns:2.com
Gateway(config-voice-uri-class)#host dns:3.com
Gateway(config-voice-uri-class)#host dns:4.com
Gateway(config-voice-uri-class)#host dns:5.com
Gateway(config-voice-uri-class)#host dns:6.com
Gateway(config-voice-uri-class)#host dns:7.com
Gateway(config-voice-uri-class)#host dns:8.com
Gateway(config-voice-uri-class)#host dns:9.com
Gateway(config-voice-uri-class)#host dns:10.com
Gateway(config-voice-uri-class)#host dns:11.com
Error:Maximum of 10 hosts can only be configured.
 
Gateway(config)# voice class uri TEST3 sip
Gateway(config-voice-uri-class)#user-id 8675309
Gateway(config-voice-uri-class)#user-id 123456789
Gateway(config-voice-uri-class)#do sh run | s TEST3
voice class uri TEST3 sip
user-id 123456789
 
Gateway(config)# voice class uri TEST4 sip
Gateway(config-voice-uri-class)#pattern 8675309
Gateway(config-voice-uri-class)#pattern 123456789
Gateway(config-voice-uri-class)#do sh run | s TEST4
voice class uri TEST4 sip
pattern 123456789

Coincidencia de par de marcado URI entrante

Esta función se agregó en IOS 15.1(2)T e IOS-XE 3.8S y utiliza un URI de clase de voz configurado y aplicado a un dial-peer entrante. Muchas personas han adoptado el URI entrante a través de la sentencia incoming called-number tradicional para llamadas SIP, ya que es el primer criterio de coincidencia comprobado al seleccionar pares de marcado entrantes. El comando también permite a los administradores la capacidad de hacer coincidir mejor las llamadas que provienen de un agente de llamadas o usuario en particular.

Documentación completa: Guía de configuración de Cisco Unified Border Element - Cisco IOS XE 17.6 en adelante

Casos prácticos comunes

1. Una coincidencia de dial-peer entrante en la parte del host del URI para responder a las solicitudes de ping de OPTIONS de CUCM.
2. Coincidencia de par de marcado entrante en la parte del host del URI para controlar las llamadas entrantes de un distribuidor de servicios de telefonía por Internet (ITSP)
3. Coincidencia de dial-peer entrante en la parte de ID de usuario de la URi para el tratamiento de llamadas de ciertos usuarios o números.

Ejemplo de configuración

Este ejemplo de resultado coincide con el par de marcado 777 para cualquier origen de solicitud SIP de las dos IPs HOST definidas en el URI de clase de voz. El encabezado observado se define como el encabezado De en el par de marcado; sin embargo, un administrador puede definir muchos otros, incluidos VIA, TO y REQUEST (URI de solicitud). Si CUCM envía un ping OPTIONS al CUBE ahora coincide con el par de marcado 777 y el origen my 200 OK responde a OPTIONS desde la interfaz especificada. Si CUCM envía una invitación al CUBE, coincide con el par de marcado 777 como el par de marcado entrante.

!
voice class uri CUCM sip
 host ipv4:10.50.244.2
 host ipv4:10.50.244.20
!
dial-peer voice 777 voip
 description INCOMING URI
 session protocol sipv2
 incoming uri from CUCM
 voice-class sip bind control source-interface Loopback777
 voice-class sip bind media source-interface Loopback777
!

Coincidencia de par de marcado URI saliente

Los gateways de Cisco IOS pueden hacer coincidir un dial-peer saliente mediante un URI aplicando un uri de clase de voz a un dial-peer saliente y agregando un url de ruta de llamada a la configuración global. Cuando esto está presente, el CUBE puede intentar enrutar las llamadas basándose en el URI de la solicitud. Esta función se añadió en IOS 12.3(4)T y está presente en todas las versiones de IOS XE. Se puede observar que, de forma predeterminada, el URI de la solicitud SIP saliente y el URI del encabezado To tienen el destino de sesión del par de marcado saliente. Esto se puede inhabilitar mediante el comando requri-pass que permite que el gateway pase la parte del host URI en el tramo al tramo externo en lugar de reemplazar la parte del host URI con el destino de la sesión. El comando requri-pass se agregó en 15.4(1)T e IOS XE 3.11S.

Ejemplo de configuración

voice service voip
 sip
  call-route url
  requri-passing
!
voice class uri CUCM sip
 host dns:.*.com
!
dial-peer voice 777 voip
 description OUTGOING URI
 session protocol sipv2
 destination uri CUCM
 session target sip-uri
!

Fuente: Guía de configuración de Cisco Unified Border Element - Cisco IOS XE 17.6 en adelante

Además del URI de clase de voz, los administradores pueden utilizar una política de provisión de par de marcado (DPP) para hacer coincidir un URI en el segmento con una coincidencia de par de marcado saliente. Esta función se añadió en IOS 15.4(2)T e IOS XE 3.12S. Una política de provisión de par de marcado requiere la definición de un atributo de coincidencia principal con un atributo de coincidencia secundario que es opcional. La política de provisión se aplica a un par de marcado entrante y cuando se selecciona ese par de marcado para su uso en un tramo de llamada entrante, se invoca la política. El resultado es una selección de par de marcado saliente basada en el atributo de la política de provisión de par de marcado.

La coincidencia de salida puede ser un solo encabezado o varios encabezados, los cuales deben ser verdaderos para coincidir con el par de marcado.

En el ejemplo, hay un URI de clase de voz para los encabezados From y To. Para una coincidencia OR, se configura una política de provisión de par de marcado que contiene dos preferencias. El encabezado From es la primera preferencia y el encabezado To es la preferencia de copia de seguridad. Dial-Peer 1234 se ha diseñado para aplicar la política de provisión para la correspondencia entrante. A continuación, se crearon los pares de marcado 11111 y 22222 que aplican los comandos destination uri-from y destination uri-to respectivamente. Estos comandos apuntan de nuevo a su URI de clase de voz. Para la llamada, puede recibir la invitación, hacer coincidir el dial-peer 1234 y verificar la política de provisión. El dispositivo puede entonces intentar rutear en el encabezado From primero, lo cual es una coincidencia aplicable en el par de marcado 11111. Si esto falla, también puede intentar rutear en el encabezado to con 22222.

El ejemplo también detalla cómo lograr una coincidencia And con las políticas de provisión de par de marcado. Suponiendo que se reciba la misma invitación, puede definir dos encabezados bajo una preferencia y aplicarla al dial-peer entrante.

Ahora, cuando se recibe la invitación, puede verificar si hay pares de marcado salientes elegibles que satisfagan ambos criterios de coincidencia definidos en la política de provisiones. Por lo tanto, en este ejemplo, su par de marcado saliente debe definirse con el encabezado TO y FROM para que coincidan. Si alguno de los dos no es una coincidencia válida, no se utiliza este par de marcado 12345.

Nota: aunque estamos enrutando la llamada en el encabezado De, la invitación que sale del gateway sigue teniendo el URI de solicitud original. Simplemente utilizamos la política de provisión de par de marcado para hacer coincidir un par de marcado saliente y no cambiar el URI de la solicitud.

Ejemplo de configuración:

### Received INVITE
Received: 
INVITE sip:8675309@172.18.110.58:5060 SIP/2.0
From: sipp <sip:sipp@172.18.110.65>;tag=1
To: sut <sip:cube@172.18.110.58:5060>

### Common Configurations
!
voice class uri FROM sip
 user-id sipp
!
voice class uri TO sip
 user-id cube
!

### OR Match
!
voice class dial-peer provision-policy 1
 description match from header. If false, try to header
 preference 1 from
 preference 2 to
!
dial-peer voice 1234 voip
 session protocol sipv2
 destination provision-policy 1
 incoming called-number .
!
dial-peer voice 11111 voip
 destination uri-from FROM
 session protocol sipv2
 session target ipv4:172.18.110.48
!
dial-peer voice 22222 voip
 destination uri-to TO
 session protocol sipv2
 session target ipv4:172.18.110.48
!

### AND Match
!
voice class dial-peer provision-policy 2
 description match from AND to headers
 preference 1 from to
!
dial-peer voice 1234 voip
 session protocol sipv2
 destination provision-policy 2
 incoming called-number .
!
dial-peer voice 12345 voip
 destination uri-from FROM
 destination uri-to TO
 session protocol sipv2
 session target ipv4:172.18.110.48
!

Fuente: Guía de configuración de Cisco Unified Border Element mediante Cisco IOS XE 17.5

session target sip-uri

Antes de IOS 15.4(1)T e IOS XE 3.11S, si la parte del host de un URI era diferente, pero el usuario era el mismo, se necesitarían dos pares de marcado de salida independientes.

Después de esta versión, un administrador puede configurar un par de marcado para mantener varios hosts para el mismo usuario. Por ejemplo, testuser@cisco.com y testuser@webex.com bajo el mismo dial-peer. El uso del sip-uri de destino de sesión activa la resolución DNS del dominio del URI de petición de invitación entrante y determina dinámicamente la IP de destino de sesión.

Ejemplo de configuración:

El gateway recibe dos invitaciones SIP con estos encabezados Invite sip:testuser@cisco.com:5060 SIP/2.0 Invite sip:testuser@webex.com:5060 SIP/2.0 El gateway coincide con la solicitud SIP entrante de testuser@cisco.com y testuser@webex.com en dial-peer 1 debido al comando URI entrante y a que la definición de id de usuario coinciden con testuser. El comando voice-class sip call-route url is present significa que usted evalúa los pares de marcado salientes basándose en el URI de solicitud de esta invitación entrante. Coincide con el par de marcado 2 por las mismas razones por las que coincidió con el par de marcado 1, el id de usuario de testuser. El destino de sesión de este par de marcado es el sip-uri original definido por el destino de sesión "sip-uri" que era un FQDN. Una vez que se ha producido una resolución de DNS y se ha cambiado cisco.com y webex.com por una IP para el routing de capa 3, se envía un mensaje fuera del gateway.

!
ip host cisco.com 10.10.10.10
ip host webex.com 10.10.10.10
!
voice class uri TEST-IN sip
 user-id testuser
!
dial-peer voice 1 voip
 description INCOMING dial-peer
 incoming uri request TEST
 session protocol sipv2
 voice-class sip call-route url
!
dial-peer voice 2 voip
 description OUTBOUND dial-peer
 destination uri TEST
 session protocol sipv2
 session target sip-uri
!

Verificación: 

show voice class uri <uri-name>
show voice class dial-peer provision-policy <number>
debug voip uri

Comodines de par de marcado

Un administrador puede utilizar comodines de par de marcado al definir mecanismos de coincidencia entrantes y salientes que implican una cadena de número. Estos incluyen destination-pattern, incoming called-number, e164-pattern-maps y answer-address, así como el comando prefix. Los comodines de par de marcado son expresiones regulares (regex) disponibles para la configuración que permiten una mayor flexibilidad en la coincidencia de pares de marcado.

Tabla comodín

Salida de la puerta de enlace que muestra las posibles entradas de expresiones regulares.

Gateway(config-dial-peer)# destination-pattern asdfqw4r3~2
Incorrect format for E.164 Number
        regular expression must be of the form  ^[][^0-9,A-F#*.?+%()-]*T?(\$)?$

Estados de par de marcado

Los pares de marcado pueden estar en uno de los dos estados operativos.

1. En funcionamiento
2. Down (inactivo)

Para que un par de marcado esté en un estado operativo válido y sea elegible para usarse con el ruteo de llamadas, debe estar en el estado ACTIVO. Para los pares de marcado de VoIP salientes, esto significa que puede haber mecanismos de coincidencia de salida válidos, así como un destino de sesión válido hacia el cual enrutar la llamada. Para los dial-peers POTS salientes, se puede configurar un mecanismo de coincidencia de salida válido así como un puerto de voz válido. Sólo con pares de marcado entrantes, se debe configurar un mecanismo de coincidencia entrante válido.

El estado busyout se observa cuando un par de marcado se configura con mecanismos keepalive y el destino remoto ha fallado en los parámetros de ese mecanismo keepalive. A continuación, la puerta de enlace mueve el par de marcado a un estado busyout para que ya no se utilice para las decisiones de ruteo de llamadas y, cuando se vuelve a activar el mecanismo de señal de mantenimiento, la puerta de enlace vuelve a poner al par de marcado en un estado activo. Si se selecciona un par de marcado como par de marcado saliente y este par de marcado está en estado busyout, la puerta de enlace falla la llamada con un código de causa 188.

Junto con los estados operativos hay estados administrativos.

1. En funcionamiento
2. Down (inactivo)

Un administrador puede inhabilitar un par de marcado sin quitarlo de la configuración ingresando el comando shutdown en el par de marcado. Para volver a habilitar el dial-per, ingrese no shutdown.

Nota: Un par de marcado con un puerto de voz que está inactivo, apagado o no está operativo, permanece en estado operacional de Activo sin embargo, el Estado de salida se muestra como Inactivo.

 Verificación 

Gateway# show dial-peer voice summary
dial-peer hunt 0
             AD                                    PRE PASS                OUT
TAG    TYPE  MIN  OPER PREFIX    DEST-PATTERN      FER THRU SESS-TARGET    STAT PORT    KEEPALIVE
1      voip  up   up                                0  syst
777    voip  up   up             9...               0  syst ipv4:10.50.244.2
555    voip  up   down           555                0  syst
888    pots  up   up             888                0                      up   0/2/0
999    pots  up   up             999                0                      down 0/2/0
123    voip  up   up             123                0  syst ipv4:10.10.10.10            busyout

Routing y reenvío virtuales (VRF) y búsqueda de pares de marcado

Coincidencia de Dial-Peer Entrante con VRF

A partir de IOS 15.6(3)M e IOS-XE 16.3.1, las gateways de Cisco pueden coincidir con los pares de marcado entrantes mediante ID de VRF. Para aprovechar esto, un administrador debe vincular el par de marcado entrante a una interfaz que, a su vez, vincula el par de marcado al ID de VRF en la interfaz especificada. Una vez que se completa el enlace, las llamadas entrantes se filtran por la puerta de enlace de Cisco para incluir solo los pares de marcado entrantes elegibles que coincidan con el ID de VRF de la interfaz en la que se recibió el paquete. Desde aquí, el par de marcado entrante coincide según el orden de operaciones de coincidencia de par de marcado normal.

Antes de estas versiones de IOS/IOS-XE, Cisco Gateway realizaba una selección de entrada basada en la coincidencia de dial-peer entrante normal sin ningún tipo de filtrado. Esto significa que una llamada VRF1 podría coincidir con un par de marcado VRF2. Además, dado que solo un VRF era compatible con H323 y SIP antes de estas versiones, surgen otros problemas al intentar utilizar funciones de VRF múltiple. El uso de un único VRF para aplicaciones de voz se conocía como configuración VRF-Aware.

Documentación con detección VRF completa: H.323 con detección VRF y SIP para gateways de voz

Documentación completa de varios VRF: Guía de configuración de Cisco Unified Border Element - Cisco IOS XE 17.6 en adelante

Coincidencia de Dial-Peer Saliente con VRF

Los gateways de Cisco tienen la capacidad de unir llamadas a través de VRF sin necesidad de configurar fugas de ruta. Esto significa que una llamada entrante en VRF1 se puede rutear de salida en un par de marcado para VRF2 si se satisface la selección de coincidencia de par de marcado saliente normal. Se pueden emplear grupos de pares de marcado para forzar que el gateway de Cisco mantenga la llamada dentro del mismo VRF.

Ejemplo de Configuración de VRF y Grupo de Dial-Peer

Este ejemplo de configuración tiene VRF1 y VRF2 con dos rangos de IP superpuestos y dos rangos de números de teléfono superpuestos.

Utilice el enlace VRF para asegurarse de que el par de marcado entrante correcto coincida, y los Grupos de par de marcado para asegurarse de que el par de marcado saliente enlazado VRF correcto coincida. Si un paquete SIP para una llamada a 8675309 llega en gig0/0/1.2, el gateway filtra todos los pares de marcado entrantes disponibles según el ID de VRF2. Esto significa que no puede coincidir con el par de marcado 10. Ahora, cuando verifique la cadena de dígitos, puede hacer coincidir el par de marcado 20. El par de marcado 20 tiene un grupo de par de marcado que le indica al gateway que el único par de marcado saliente que se puede igualar también es el par de marcado 20. Este grupo de par de marcado le permite evitar hacer coincidir el par de marcado 10 y cruzar una llamada que viene de VRF1 a VRF2. A partir de ahí, la llamada puede continuar con normalidad.

!
interface GigabitEthernet0/0/1.1
 description VRF1
 encapsulation dot1Q 10
 ip vrf forwarding VRF1
 ip address 10.10.10.10 255.255.255.0
!
interface GigabitEthernet0/0/1.2
 description VRF2
 encapsulation dot1Q 20
 ip vrf forwarding VRF2
 ip address 10.10.10.10 255.255.255.0
!
voice service voip
 no ip address trusted authenticate
 media-address voice-vrf VRF1
 media-address voice-vrf VRF2
 allow-connections sip to sip
 sip
!
voice class dpg 10
 description INBOUND VRF1 to OUTBOUND VRF1
 dial-peer 10 preference 1
!
voice class dpg 20
 description INBOUND VRF2 to OUTBOUND VRF2
 dial-peer 20 preference 1
!
dial-peer voice 10 voip
 description VRF1
 destination-pattern 8675309
 session protocol sipv2
 session target ipv4:10.10.10.20
 destination dpg 10
 incoming called-number 8675309
 voice-class sip bind control source-interface GigabitEthernet0/0/1.1
 voice-class sip bind media source-interface GigabitEthernet0/0/1.1
!
dial-peer voice 20 voip
 description VRF2
 destination-pattern 8675309
 session protocol sipv2
 session target ipv4:10.10.10.20
 destination dpg 20
 incoming called-number 8675309
 voice-class sip bind control source-interface GigabitEthernet0/0/1.2
 voice-class sip bind media source-interface GigabitEthernet0/0/1.2
!

Verificación

Gateway# show vrf brief | i VRF
  VRF1                             1:1                   ipv4        Gi0/0/1.1
  VRF2                             2:2                   ipv4        Gi0/0/1.2

Gateway# show dial-peer voice summary
TAG    TYPE  MIN  OPER PREFIX    DEST-PATTERN      FER THRU SESS-TARGET    STAT PORT    KEEPALIVE    VRF
10     voip  up   up             8675309            0  syst ipv4:10.10.10.20                         VRF1
20     voip  up   up             8675309            0  syst ipv4:10.10.10.20                         VRF2

Gateway# show voice class dpg 10
Voice class dpg: 10      AdminStatus: Up
 Description: INBOUND to OUTBOUND VRF1
 Total dial-peer entries: 1

 Peer Tag       Pref
 --------       ----
 10             1
-------------------------------------

Gateway# show voice class dpg 20
Voice class dpg: 20      AdminStatus: Up
 Description: INBOUND to OUTBOUND VRF2
 Total dial-peer entries: 1

 Peer Tag       Pref
 --------       ----
 20             1
-------------------------------------

Técnicas avanzadas de enrutamiento de llamadas

Con el paso de los años, a medida que crecen las necesidades empresariales, la empresa se expande y requiere más DID, y los administradores empresariales pueden descubrir que los dial-peers básicos no se ajustan bien a la escala. Puede haber situaciones de on-off que deban ser atendidas, o quizás hay demasiados pares de marcado en general. Tener miles de pares de marcado no facilita la administración y la resolución de problemas. El hecho de tener un par de marcado para cada servidor de CUCM o agente de llamada específico comienza a agravar el problema de demasiados pares de marcado porque ahora un administrador necesita configurar un par de marcado para cada cadena de dígitos. Si hay más de un proveedor de SIP conectado a un gateway o varias personas diferentes que utilizan el mismo CUBE, el aislamiento de un arrendatario específico resulta muy difícil.

Cisco ha recogido estos comentarios y ha creado un conjunto de elementos que pueden solucionar estos problemas y mucho más. Los grupos de pares de marcado, los arrendatarios de clase de voz, los grupos de servidores de destino, los mapas de patrones e164 y los grupos troncales POTS permiten que un administrador resuelva todos los problemas enumerados y muchos más no incluidos.

Grupos de pares de marcado

Los grupos de dial-peer fueron agregados en IOS 15.4(1)T e IOS-XE 3.11S y los dial-peers POTS fueron agregados como una opción en IOS 15.5(1)T e IOS-XE 3.14S. Un grupo de dial-peer permite a los administradores especificar un dial-peer exacto para el ruteo saliente basado en el dial-peer entrante coincidente. Una vez que se hace coincidir un par de marcado entrante con un grupo de par de marcado configurado, la llamada utiliza el par de marcado definido en el grupo de par de marcado incluso si el patrón de destino no coincide. El único requisito previo es que el par de marcado saliente debe estar activo, por lo que debe configurarse un método de coincidencia saliente; sin embargo, esto no se usa realmente para enrutar la llamada.

La mejor manera de describir los grupos de pares de marcado es compararlos con el concepto de rutas estáticas en una tabla de ruteo. Se trata de decisiones estáticas de enrutamiento de entrada a salida que eliminan algunas conjeturas para el gateway, ya que le indican exactamente cómo enrutar la llamada. 

Documentación completa: Guía de configuración de Cisco Unified Border Element - Cisco IOS XE 17.6 en adelante

Ejemplo de configuración

Con este ejemplo, el número llamado es 8675309. Esto coincide con el par de marcado 1234 basado en la sentencia de número llamado entrante. Este par de marcado se configura con un grupo de par de marcado que establece que la llamada puede ahora rutear los pares de marcado 2, luego 3 y finalmente 1 si falla el par de marcado 2. Esto hace que el gateway intente ahora rutear el dial-peer 2 de llamada tal como se le ha indicado explícitamente a través del grupo de dial-peer que es lo que puede hacer.

Nota: El patrón de destino en el par de marcado 1, 2 y 3 no es el número llamado de 8675309. Esto está bien y la llamada sigue enrutándose sin problemas.

Recuerde, como se discutió en la sección de estados de par de marcado, necesita algo/cualquier cosa configurada como una sentencia de coincidencia saliente. En este caso, el patrón de destino es solamente llevar el par de marcado a un estado operacional Up, y la cadena de dígitos de ese comando nunca se evalúa. Se recomienda configurar un patrón como destination-pattern AAAA ya que éste es un patrón de destino válido. Dado que este es técnicamente un par de marcado válido, otras llamadas podrían coincidir con él. Por lo tanto, la cadena de dígitos AAAA significa que nunca se puede utilizar para otra cosa que no sea un escenario específico que involucre a un grupo de dial-peer ya que la probabilidad de una llamada entrante para AAAA es muy, muy baja.

!
dial-peer voice 1 voip
 description Server 1
 destination-pattern ^1234$
 session target ipv4:1.1.1.1
!
dial-peer voice 2 voip
 description Server 2
 destination-pattern ^5678$
 session target ipv4:2.2.2.2
!
dial-peer voice 3 voip
 description Server 3
 destination-pattern AAAA
 session target ipv4:3.3.3.3
!
voice class dpg 1
 description Dial-peer Group for specific called number 8675309
 dial-peer 2 preference 1
 dial-peer 3 preference 2
 dial-peer 1 preference 3
!
dial-peer voice 1234 voip
 description INCOMING dial-peer with DPG
 incoming called-number ^8675309$
 destination dpg 1
!

Verificación

Gateway# show voice class dpg 1
Voice class dpg: 1       AdminStatus: Up
 Description: Dial-peer Group for specific called number 1234
 Total dial-peer entries: 3

 Peer Tag       Pref
 --------       ----
 2              1
 3              2
 1              3
-------------------------------------

E164-Pattern-Maps

Esta función brinda a los administradores la capacidad de reducir el número total de pares de marcado al combinar muchas coincidencias de número posibles (patrones de destino, número llamado entrante, etc.) en un único mapa de patrón. Se agregó soporte de correspondencia de patrones de marcado de salida e164 en IOS 15.2(4)M e IOS XE 3.7S, mientras que se agregó soporte de correspondencia de patrones de marcado de entrada e164 en IOS 15.4(1)T e IOS XE 3.11S.

Un mapa de patrones e164 se puede configurar a través de la CLI o preconfigurado y se guarda como un archivo .cfg. A continuación, se agrega el archivo .cfg a la memoria flash de la puerta de enlace y, a continuación, se hace referencia a él al configurar el resto del comando. El archivo .cfg puede utilizar 5000 entradas.

Las entradas de ambos métodos de configuración pueden utilizar todos los comodines de par de marcado normales para una agregación adicional.

Documentación completa: Guía de configuración de Cisco Unified Border Element - Cisco IOS XE 17.6 en adelante

Ejemplo de configuración de CLI - Llamar a números

!
voice class e164-pattern-map 1
 description E164 Pattern Map for calling numbers
 e164 919574100.
 e164 919574300.
 e164 8675309
!
dial-peer voice 1 voip
 description INBOUND Dial-peer based on CALLING #
 incoming calling e164-pattern-map 1
!
dial-peer voice 11 voip
 description OUTBOUND Dial-peer based on CALLING #
 destination calling e164-pattern-map 1
!

Ejemplo de configuración de CLI: número llamado

!
voice class e164-pattern-map 2
 description E164 Pattern Map for called 800 numbers
 e164 91800T
 e164 91855T
 e164 91888T
!
dial-peer voice 2 voip
 description INBOUND Dial-peer based on CALLED #
 incoming called e164-pattern-map 2
!
dial-peer voice 22 voip
 description OUTBOUND Dial-peer based on CALLED #
 destination e164-pattern-map 2
!

Ejemplo de Configuración de Flash

!
voice class e164-pattern-map <tag>
 description FILEPATH for E164 Pattern Map
 url flash:<filepath>/e164-pattern-list.cfg
!
dial-peer voice ### voip
 description E164 Pattern Map Dial-peer
 incoming calling e164-pattern-map <tag>
!

voice class e164-pattern-map load <tag>

Verificación

Gateway# show voice class e164-pattern-map 1

e164-pattern-map 1
-----------------------------------------
  Description: CUCM phones
  It has 3 entries
  It is not populated from a file.
  Map is valid.

E164 pattern
-------------------
8675309
1...
[2-5]...$

Defectos notables

El ID de bug de Cisco CSCva64393e164-pattern-map no analiza la última línea del archivo de configuración.

Grupos de servidores de destino

Los grupos de servidores proporcionan a los administradores la capacidad de configurar varios destinos (destinos de sesión) en el mismo dial-peer VOIP. De forma predeterminada, el criterio de ordenación es la preferencia definida en las entradas del grupo de servidores. La búsqueda por turnos se puede emplear cuando se utiliza el comando hunt-scheme round-robin. Los grupos de servidores se agregaron en Cisco IOS 15.4(1)T y Cisco IOS XE 3.11S. En Cisco IOS XE 17.4.1a se agregaron códigos de error de búsqueda configurable a las configuraciones de grupo de servidores de clase de voz. Es decir, puede configurar un solo código de error, por ejemplo 404 Not Found, y el error SIP normalmente activaría el dispositivo para probar la siguiente opción en el grupo de servidores. Con config huntstop 1 resp-code 404 en su lugar dentro del grupo de servidores, la búsqueda puede detenerse. También se pueden configurar para un rango como: huntstop 1 resp-code 401 a 599.

Nota: El número máximo de entradas es de 5 por grupo de servidores.

Documentación completa: Guía de configuración de Cisco Unified Border Element - Cisco IOS XE 17.6 en adelante

Ejemplo de configuración: Normal

!
voice class server-group 1
 hunt-scheme round-robin
 ipv4 10.50.244.2 port 5060 preference 1
 ipv4 10.50.244.62
 ipv6 2010:AB8:0:2::1 port 2323 preference 3
 ipv6 2010:AB8:0:2::2 port 2222
!
dial-peer voice 1 voip
 session protocol sipv2
 destination-pattern 8675309
 session server-group 1
!

Verificación

Gateway# show voice class server-group 1
Voice class server-group: 1
 AdminStatus: Up OperStatus: Up
 Hunt-Scheme: round-robin Last returned server:
 Description:
 Total server entries: 4

 Pref Type IP Address IP Port
 ---- ---- ---------- -------
 1 ipv4 10.50.244.2     5060
 0 ipv4 10.50.244.62
 3 ipv6 2010:AB8:0:2::1 2323
 0 ipv6 2010:AB8:0:2::2 2222
[..truncated..]

Grupo de servidores de destino y opciones keepalive

Tenga en cuenta que los grupos de servidores no siguen los mecanismos normales de mantenimiento de opciones fuera de diálogo. Utilizan una función denominada perfil de opción de mantenimiento. Esto permite que la puerta de enlace supervise cada agente de llamada definido en el grupo de servidores específico.

Ejemplo de Option-keepalive con un grupo de servidores

!
voice class server-group 1
 hunt-scheme round-robin
 ipv4 10.50.244.2
 ipv4 10.50.244.62
!
dial-peer voice 1 voip
 session protocol sipv2
 session server-group 1
 voice-class sip options-keepalive profile 1
!

Verificación

Gateway# show voice class sip-options-keepalive 1
Voice class sip-options-keepalive: 1             AdminStat: Up
 Description:
 Transport: system               Sip Profiles: 0
 Interval(seconds) Up: 5                 Down: 5
 Retry: 5

  Peer Tag      Server Group    OOD SessID      OOD Stat        IfIndex
  --------      ------------    ----------      --------        -------
  1             1                               Active          87

  Server Group: 1                OOD Stat: Active
   OOD SessID   OOD Stat
   ----------   --------
   1            Active
   2            Active

 OOD SessID: 1                   OOD Stat: Active
  Target: ipv4:10.50.244.2
  Transport: system              Sip Profiles: 0

 OOD SessID: 2                   OOD Stat: Active
  Target: ipv4:10.50.244.62
  Transport: system              Sip Profiles: 0

Proxy saliente

La configuración de Proxy SIP saliente se puede agregar a las configuraciones de VoIP de servicio de voz, arrendatario de clase de voz o par de marcado para especificar el destino para un paquete SIP de capa 3.

Es decir, el destino de sesión en un par de marcado se puede utilizar para crear el paquete SIP, pero el proxy saliente puede ser el lugar donde se envía el paquete en la Capa 3.

!
voice service voip
 sip
  outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
!
voice class tenant 100
 outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
!
dial-peer voice 100 voip
 session target ipv4:192.168.1.1
 voice-class sip outbound-proxy dns:la01.sipconnect-us10.cisco-bcld.com
!

Se puede observar que la configuración predeterminada para un par de marcado es voice-class sip outbound-proxy systemque puede hacer que un par de marcado utilice el servicio de voz global voip > sip configuration.

Este comportamiento se puede inhabilitar y obligar a un par de marcado a retroceder y utilizar el destino de sesión como el destino de capa 3 por par de marcado con esta configuración:

dial-peer voice 777 voip
 no voice-class sip outbound-proxy

Grupos troncales POTS

Los Trunk Groups son una colección de puertos de voz físicos con capacidades de señalización similares. Esta es una función que se puede emplear para reducir el número total de pares de marcado POTS que se deben configurar. Los grupos troncales se introdujeron en IOS en la versión 12.1(3)T y están presentes en todas las versiones de Cisco IOS XE.

Documentación completa: Mejoras de routing basado en portadora y troncal de gateway

Ejemplo de configuración

!
trunk group PSTN
 description PSTN voice-ports
!
trunk group FXO
 description FXO voice-ports
!
voice-port 0/2/0
 trunk-group PSTN 1
!
voice-port 0/2/1
 trunk-group PSTN 2
!
voice-port 0/2/2
 trunk-group FXO 1
!
voice-port 0/2/3
 trunk-group FXO 2
!
dial-peer voice 1234 pots
 trunkgroup PSTN 1
 trunkgroup FXO 2
!

Arrendatarios de clase de voz

Cisco IOS 15.6(2)T y Cisco IOS XE 16.3.1 introdujeron los arrendatarios de clase de voz que permiten que cada arrendatario tenga sus propias configuraciones individuales. Un arrendatario puede ser un proveedor de telefonía, Cisco Unified Communication Manager (CUCM) o cualquier otro agente de llamadas de terceros para el que un administrador desee disponer de una configuración global específica. En primer lugar, un administrador crea un arrendatario de clase de voz y define los parámetros. El arrendatario de la clase de voz se aplica al par de marcado específico o a la opción. Esta nueva configuración proporciona a los administradores otro nivel de control sobre las llamadas más allá de los pares de marcado y la configuración global.

Con 17.8.1a, las configuraciones de arrendatario de clase de voz se pueden configurar con un comando sip-listen (junto con el comando de enlace de control SIP adecuado) para definir el puerto no seguro o seguro de ese arrendatario. Esto significa que el arrendatario 1 podría escuchar el SIP no seguro en UDP 5060 + VRF rojo mientras que el arrendatario 2 escucha el SIP en TCP TLS 5070 + VRF azul. Después de hacer coincidir el arrendatario en función de los pares de marcado entrantes de puerto de escucha + enlace + vrf opcional, se filtran los pares de marcado entrantes por aquellos que tienen aplicado el arrendatario.

Documentación completa: Guía de configuración de Cisco Unified Border Element - Cisco IOS XE 17.6 en adelante

Orden normal de preferencia de comando sin arrendatarios

1. comando Dial-peer
2. Comando global (servicio de voz voip y sip-ua)

Orden de preferencia de comando con arrendatarios

1. comando Dial-peer
2. Arrendatario, comando
3. Comando global (voice service voip y sip-ua)

Ejemplo de Configuración de Varios Arrendatarios

Tiene dos arrendatarios 777 y 999. Los ha configurado con configuraciones ligeramente diferentes y los ha aplicado a los pares de marcado. Esto significa que las llamadas que utilizan los diferentes pares de marcado tienen configuraciones basadas en pares de marcado, así como configuraciones específicas de arrendatario. Las opciones enumeradas son solo un fragmento de la potencia de los arrendatarios de clase de voz. Consulte la documentación para ver qué se puede configurar en un arrendatario. Se recomienda emplear mecanismos de coincidencia estrictos como URI de clase de voz o etiquetar números con ciertas cadenas numéricas para separar la coincidencia de dial-peer de arrendatario, o incluso configurar VRF para que el arrendatario A nunca se superponga con el arrendatario B y coincida accidentalmente con un dial-peer que no pueden.

!
voice class tenant 999
 asymmetric payload full
 bind control source-interface GigabitEthernet0/0/0.228
 bind media source-interface GigabitEthernet0/0/0.228
 g729 annexb-all
!
voice class tenant 777
 sip-server ipv4:192.168.1.2
 bind control source-interface Loopback0
 bind media source-interface Loopback0
 pass-thru content sdp
!
dial-peer voice 999 voip
 destination-pattern 8675309
 session protocol sipv2
 incoming called-number 8675309
 voice-class sip tenant 999
!
dial-peer voice 777 voip
 destination-pattern 8675309
 session protocol sipv2
 session target sip-server
 voice-class sip tenant 777
!

Verificación

Actualmente, no hay comandos individuales para ver las configuraciones de arrendatario de clase de voz. Este comando puede ser suficiente para filtrar la configuración en ejecución a la información del arrendatario solamente.

show run | sec tenant

Nota: el Id. de bug Cisco CSCvf28730 es donde el estado show sip-ua register no refleja el estado del registro de trunk SIP en un arrendatario de clase de voz.

ILS URI Calls CUBE (cadena de ruta de clase de voz)

Las cadenas de ruta se utilizan con el servicio de búsqueda entre clústeres (ILS) de CUCM y se pueden configurar para permitir que los gateways de Cisco enruten llamadas VoIP a través de la cadena de ruta incluida en la invitación SIP recibida desde un CUCM 9.5+ que ejecuta el servicio ILS. Esta función se añadió en Cisco IOS 15.3(3)M y Cisco IOS XE 3.10S. La mayoría de las conexiones ILS son de CUCM a CUCM y los administradores no se molestan en incluir un CUBE para la conexión troncal entre clústeres. Sin embargo, si necesita realizar la función con CUBE en el centro, las opciones están ahí. CUCM necesita tener la configuración Send ILS Learned Destination Route String habilitada en el perfil SIP aplicada al troncal SIP para enviar el encabezado x-cisco-dest-route-string a CUBE

Documentación completa: Guía de configuración de interoperabilidad de aplicaciones empresariales para H.323 a SIP y SIP a SIP, Cisco IOS Release 15M&T

Ejemplo de configuración CUCM - SIP - CUBE - SIP - CUCM

!
voice service voip
 sip
  call-route dest-route-string
!
voice class route-string rt1
 pattern london.uk.eu
!
voice class sip route-string rt2
 pattern *.eu
!
voice class sip-hdr-passthrulist hdr1
 passthru-hdr x-cisco-dest-route-string
!
dial-peer voice 1 voip
 description INBOUND dial-peer
 session protocol sipv2
 voice-class sip pass-thru headers hdr1
 incoming called-number .
!
dial-peer voice 2 voip
 description OUTBOUND dial-peer
 destination route-string rt2
 session protocol sipv2
 session target ipv4:172.16.104.178
!

Verificación

show voice class route-string

Técnicas de enrutamiento de llamadas antiguas

Los elementos que se tratan en esta sección se consideran técnicas antiguas. Aunque la capacidad de configurarlos sigue presente en una puerta de enlace de Cisco, no se recomienda utilizar estos comandos en las configuraciones modernas. Este documento solo los trata porque se pueden encontrar mientras se trabaja con configuraciones heredadas o cuando se realizan actualizaciones.

DNIS-Map

Los mapas DNIS podrían ser considerados el precursor de lo que ahora sería un mapa-patrón-E164. Los mapas DNIS se agregaron a Cisco IOS en 12.2(2)XB y siempre han existido en Cisco IOS XE.

Si hay mapas DNIS configurados, valdría la pena convertirlos a la función e164-pattern-map más robusta.

Sintaxis del comando: Referencia de comandos de voz de Cisco IOS - D a I

Ejemplo de configuración

!
voice dnis-map 34
 dnis 8675309
!
dial-peer voice 88 voip
 dnis-map 34
!

Etiquetas de grupos troncales

Las etiquetas de grupo troncal se agregaron en Cisco IOS 12.2(11)T y existen en todas las versiones de Cisco IOS XE. El propósito de una etiqueta trunk-group es similar a un Carrier-ID en el sentido de que se puede utilizar para aumentar la coincidencia de pares de marcado. Esto está disponible para la configuración dentro de grupos troncales POTS, pares de marcado VOIP y POTS, así como grupos de origen de voz. El uso de etiquetas de grupos troncales rara vez se observa en las configuraciones modernas de Cisco Gateway.

Sintaxis del comando: Referencia de comandos de voz de Cisco IOS - T a Z

Ejemplo de configuración

!
dial-peer voice 112 pots
 trunk-group-label source north3
 trunk-group-label target east17
!

Tipo de numeración

Con las integraciones ISDN Q.931 existe la posibilidad de hacer coincidir un par de marcado basado en el número de llamada o llamado, así como el tipo de número ITU específico del mensaje de CONFIGURACIÓN Q.931. Esto se puede configurar mediante el comando numbered-type en un dial-peer VOIP o POTS. El tipo de numeración no se puede utilizar solo y se debe utilizar junto con destination-pattern, answer-address o incoming called-number. Esto significa que tanto la condición de la sentencia de coincidencia entrante / saliente como el tipo de número deben coincidir para que el par de marcado sea un éxito y sea considerado para el ruteo de llamadas entrantes y salientes.

La coincidencia de numeración se puede considerar como un mecanismo de filtrado de par de marcado en lugar de un mecanismo de coincidencia. Esto se debe a que un par de marcado con y sin un comando de tipo de numeración aplicado se considera la misma ponderación de preferencia predeterminada si no se aplica ninguna preferencia del administrador. Esto es diferente a carrier-id que, cuando se aplica a un dial-peer junto con otro mecanismo de coincidencia, agrega preferencia a ese dial-peer sobre otros si ambas condiciones son verdaderas.

La coincidencia de tipo de numeración se agregó en Cisco IOS 12.0(7)XR1 y está presente en todas las versiones de Cisco IOS XE. Con el declive de las líneas POTS ISDN tradicionales implementadas en redes de colaboración, el uso del tipo de numeración rara vez se ve en las implementaciones modernas.

Sintaxis del comando: Referencia de comandos de voz de Cisco IOS - K a R

Ejemplo de configuración

Este par de marcado puede coincidir de 4085150000 a 4085159999 sólo si el tipo de número ISDN es Nacional.

!
dial-peer voice 408 voip
 numbering-type national
 destination-pattern 408515....
 session target ipv4:10.1.1.2
!

Tipos de número posibles:

Datos del par de marcado

Los pares de marcado de datos se introdujeron en Cisco IOS 12.2(13)T y el uso de dichos pares de marcado fue para llamadas entrantes de módem de datos en una gateway de Cisco. Este dial-peer es solo para uso en la dirección entrante y rara vez se ve en las implementaciones modernas.

Sintaxis del comando: Referencia de comandos de voz de Cisco IOS - D a I

Ejemplo de configuración

!
dial-peer data 100 pots
 incoming called-number 100
!

Voice Source-Group

Esta función se añadió en la versión 15.1(2)T, pero no se ha implementado en muchas implementaciones modernas. Normalmente se implementan otros métodos de seguridad para IOS/CUBE.

La descripción general de la seguridad de la aplicación CUBE se puede ver en este informe técnico que comienza en la sección 4.2.

Especificación de gestión y capacidad de gestión de Cisco Unified Border Element (CUBE)

Sintaxis del comando: Función Voice Source-Group

Permisos de par de marcado

Esta configuración permite que un administrador restrinja un par de marcado para permitir solamente conexiones entrantes (término / terminación) o conexiones de salida (origen / origen). Esto sería como configurar explícitamente un par de marcado entrante para que sólo se utilice para llamadas entrantes y un par de marcado saliente para llamadas salientes. El valor predeterminado para cualquier par de marcado es permitir las conexiones entrantes y salientes. Esta CLI no se suele implementar en las implementaciones modernas.

Router(config)# dial-peer voice 1 voip
Router(config-dial-peer)# permission ?
 both allow both orig/term on this dialpeer
 none no orig/term allowed on this dialpeer
 orig allow only orig on this dialpeer
 term allow only term on this dialpeer

Manipulación de URI y dígitos

En algún momento de una implementación de colaboración, un administrador puede necesitar manipular dígitos o un encabezado URI/SIP. Los gateways de Cisco cuentan con numerosos métodos de manipulación de dígitos que permiten al administrador controlar completamente cómo y cuándo se puede manipular un dígito. Sin embargo, esto no siempre es fácil y algunas personas se abruman con las diferentes opciones o el administrador no sabe que existe una opción.

Manipulación de dígitos mediante pares de marcado POTS

Los dial-peers POTS tienen algunas técnicas de manipulación de dígitos únicas para ellos que los dial-peers VOIP no tienen.

La primera es la eliminación de dígitos explícitamente definidos con justificación izquierda en un patrón de destino. Esto se puede inhabilitar mediante el comando no digit-strip en el dial-peer POTS.

Ejemplo:

En este ejemplo, 9011T se define como la cadena para destination-pattern.

Con esto en su lugar, puede recibir una llamada para 90113227045555. Esto coincide con el par de marcado para el ruteo de llamadas salientes, y los dígitos explícitamente definidos de 9011 se eliminan antes de que la llamada se rutee fuera del puerto de voz. 

!
dial-peer voice 1 pots
 destination-pattern 9011T
 port 0/0/0:23
!

En este ejemplo se muestra una configuración sin dígitos en su lugar.

Si se llama al mismo número, se envía el 9011 .

!
dial-peer voice 1 pots
 destination-pattern 9011T
 port 0/0/0:23
 no digit-strip
!

La segunda es la capacidad de especificar cuántos dígitos desea reenviar en el dial-peer POTS.

Tome este ejemplo cuando reciba una llamada al 918005532447 de CUCM. En esta situación, desea quitar el 9, pero enviar el resto del número empezando por el 1.

Si configura el comando forward-digits en el dial-peer POTS, puede especificar exactamente cuántos dígitos envía.

!
dial-peer voice 1 pots
 destination-pattern 918005532447
 forward-digits 11
 port 0/2/0
!

Por último, los pares de marcado POTS pueden hacer uso del comando prefix para agregar dígitos a una llamada antes de rutear el puerto de voz. Este ejemplo elimina el 91 definido explícitamente y el prefijo 007 al número antes de enviar la llamada al puerto de voz.

!
dial-peer voice 1 pots
 destination-pattern 91T
 prefix 007
 port 0/1/0:15
!

Manipulación de dígitos mediante reglas y perfiles de traducción de voz

Las reglas de traducción de voz son expresiones regulares (regex) que se utilizan para transformar dígitos. Las reglas de traducción y los perfiles se agregaron a Cisco IOS en 12.0(7)XR1. Una regla de traducción se aplica a los perfiles de traducción de voz que luego se aplican a un par de marcado o puerto de voz. Las reglas de traducción contienen una entrada de coincidencia y una salida de modificación. Junto con la entrada de coincidencia en el número, hay una entrada de coincidencia y modificación para el plan y el tipo ISDN. La combinación de cadena de número de coincidencia, plan y tipo se considera una coincidencia. Esto significa que todas las entradas de coincidencia definidas deben ser verdaderas para que la traducción tenga lugar. 

Las reglas de traducción tienen la capacidad de cambiar los protocolos de señalización Llamada, Llamada, Llamada de redirección, Destino de redirección y Devolución de llamada en ISDN, SIP y H323. Las reglas de traducción coinciden según una búsqueda de arriba hacia abajo, por lo que el orden de las reglas es de suma importancia. Si se encuentra una coincidencia en una regla superior, el gateway detiene inmediatamente la búsqueda y procesa la traducción. Las reglas de traducción no pueden cambiar encabezados sip no numéricos como testuser@10.10.10.10. Para esta manipulación, utilice un perfil SIP.

Las reglas de transición se pueden utilizar para bloquear llamadas en gateways de Cisco.

Preferencia de selección de perfil de traducción

1. Perfil de traducción de voz entrante en el puerto de voz
2. Perfil de traducción de voz entrante en grupo troncal aplicado a interfaz serial
3. Perfil de traducción de voz entrante en el dial-peer entrante
4. Perfil de traducción de voz entrante definido mediante puertos de servicio de voz
5. Perfil de traducción de voz entrante definido mediante global 'voip-incoming translation-profile'
6. Perfil de traducción de voz saliente definido mediante puertos de servicio de voz
7. Outbound voice translation-profile o translate-outgoing en el dial-peer de salida
8. Outbound voice translation-profile on Trunk Group applied to Serial Interface
9. Perfil de traducción de voz saliente en el puerto de voz

Además de las reglas de conversión regex y wilcards de dial-peer, las reglas de traducción tienen sus propios caracteres regex.

Conjuntos de modificaciones

• Los conjuntos se especifican como \0, \1, \2, etc.
• \0 coincide con cualquier elemento comprendido entre el primer conjunto de coincidencias. Esto también se puede lograr a través de un carácter de signo et: &.
• \1 coincide con el primer conjunto de ( ) del conjunto de coincidencias
• \2 coincide con el segundo conjunto de ( ) del conjunto de coincidencias
• Y así sucesivamente.

Ejemplo de regla de traducción con dos conjuntos

En este ejemplo, puede examinar el número 000111000222.

Desea quitar los ceros del número y obtener un número final de 111222.

Para hacer esto, configure el conjunto 1 y 2 para capturar el 111 y el 222 respectivamente mientras descarta los 0.

!
voice translation-rule 333
 rule 1 /000\(111\)000\(222\)/ /\1\2/
!
voice translation-profile SET-EXAMPLE
 translate called 333
!

Gateway# test voice translation-rule 333 000111000222
Matched with rule 1
Original number: 000111000222   Translated number: 111222
Original number type: none      Translated number type: none
Original number plan: none      Translated number plan: none

Ejemplo para quitar el patrón de marcación externa 9 de un número marcado

!
voice translation-rule 9
 rule 1 /^9\(.*\)/ /\1/
!
voice translation-profile STRIP-9
 translate called 9
!
dial-peer voice 9 voip
 translation-profile outgoing STRIP-9
!
voice-port 0/0/0
 translation-profile outgoing STRIP-9
!

Gateway# test voice translation-rule 9 918675309
Matched with rule 1
Original number: 918675309      Translated number: 18675309
Original number type: none      Translated number type: none
Original number plan: none      Translated number plan: none

Truncar el número llamado a 4 dígitos

!
voice translation-rule 4
 rule 1 /.*\(....\)/ /\1/
!
voice translation-profile STRIP-TO-4
 translate called 4
!

Gateway# test voice translation-rule 4 8675309
Matched with rule 1
Original number: 8675309        Translated number: 5309
Original number type: none      Translated number type: none
Original number plan: none      Translated number plan: none

Eliminación de más + del número marcado

!
voice translation-rule 999
 rule 1 /\+\(.*\)/ /\1/
!
voice translation-profile STRIP-PLUS
 translate called 999
!
Gateway# test voice translation-rule 999 +8675309
Matched with rule 1
Original number: +8675309       Translated number: 8675309
Original number type: none      Translated number type: none
Original number plan: none      Translated number plan: none 

Las reglas de traducción también se pueden aplicar directamente a un par de marcado sin aplicarlas primero a un perfil de traducción.

!
voice translation-rule 1
 rule 1 /1234/ /8678309/
!
voice translation-rule 2
 rule 2 /^4...$/ /1408515\0/
!
dial-peer voice 1 voip
 translate-outgoing called 1
!
dial-peer voice 2 voip
 translate-outgoing calling 2
!

Perfil de traducción en grupo de enlaces

!
trunk group <name>
 translation-profile incoming <profile-name>
 translation-profile outgoing <profile-name>
!

Depurar reglas y perfiles de traducción de voz

debug voip ccapi inout
debug voice translation
debug dialpeer
test voice translation-rule <number> <string> type <type> plan <plan>

Voice Class e164-translation

La función de traducción de clase de voz e164 es una función más reciente de Cisco IOS XE que permite a un administrador crear una lista de sentencias coincidentes y modificar sentencias para cargarlas a través de un archivo de configuración desde la memoria flash o un directorio de red. Esto es similar al concepto de la función e164-pattern-map que se describe en este documento. Esto permite a un administrador configurar hasta 100 traducciones dentro de un archivo de configuración y aplicarlas en un único perfil de traducción. Para obtener más información, consulte la Referencia de Comandos de Voz de Cisco IOS

Siga esta sintaxis para el archivo .cfg:

pattern1_to_be_matched<tab>replaced_pattern<space><enter>
pattern1_to_be_matched<tab>replaced_pattern<space><enter>

Nota: El espacio final es muy importante y la importación puede fallar sin ese paso de formato adicional.

Sample.cfg

+111111	8897 
+222222	8312 
928747	+123456789 
737362	+987654321 

Este archivo entonces hace referencia como tal:

voice class e164-translation 164
 url ftp://username:password@10.10.10.10/sample.cfg

Ahora se aplica a un perfil de traducción normalmente y, desde allí, se aplica a los pares de marcado utilizando la sintaxis normal del perfil de traducción.

voice translation-profile e164
 translate calling voice-class e164-translation 164
 translate called voice-class e164-translation 164

El comando show voice class e164-translation e164-translation-number se puede utilizar para ver el contenido del perfil de traducción.

Manipulación de dígitos mediante mapas ISDN

Los MAPS ISDN son una técnica más antigua para modificar dígitos. Esto se agregó en Cisco IOS 12.0(6)T y la mayoría de las configuraciones nuevas no utilizan esta función, ya que no son tan robustas como las reglas de traducción de voz y los perfiles. Los mapas ISDN se definen bajo la interfaz Serial.

Ejemplo de configuración

Serial0/0/0:23
 isdn map address ^911 plan isdn type unknown
 isdn map address ^1.......... plan isdn type national
 isdn map address ^2......... plan isdn type national
 isdn map address ^3......... plan isdn type national
 isdn map address ^4......... plan isdn type national
 isdn map address ^5......... plan isdn type national
 isdn map address ^6......... plan isdn type national
 isdn map address ^7......... plan isdn type national
 isdn map address ^8......... plan isdn type national
 isdn map address ^9......... plan isdn type national

Manipulación de dígitos mediante expansión numérica (num-exp)

Al igual que los Mapas ISDN, la expansión de número es una técnica más antigua que se agregó en Cisco IOS 11.3(1)T y no se usa mucho en las redes nuevas. Esta función se añadió antes de que existieran las reglas de traducción de voz y los perfiles. La expansión de número es un cambio global de dígitos que se aplica a todos los pares de marcado de una gateway de Cisco. La modificación se aplica al número al que se llama después de que el par de marcado haya sido igualado, y justo antes de que la llamada se envíe al siguiente agente de llamada.

Ejemplo de configuración

num-exp 4... 18005554...
num-exp 1234 8675309

Perfiles SIP entrantes/salientes

Los perfiles SIP son sentencias de coincidencia de expresiones regulares (regex) sólidas que permiten a un administrador cambiar cualquier aspecto de un mensaje SIP que incluya encabezados SDP y SIP. Se pueden habilitar globalmente por par de marcado o por arrendatario. Los perfiles SIP están disponibles para modificaciones entrantes que comienzan con Cisco IOS 15.4(2)T y Cisco IOS XE 3.12S . Dado que los perfiles SIP son tan sólidos, este documento solo cubre algunos ejemplos específicos. Los perfiles SIP también añaden la capacidad para que los encabezados SIP personalizados se modifiquen o agreguen en IOS 15.5(2)T e IOS-XE 3.13S.

Puntos clave sobre los perfiles SIP entrantes y salientes

• Los perfiles SIP entrantes cambian el mensaje ANTES de que el CUBE procese el mensaje para el enrutamiento de llamadas.
• Los perfiles SIP salientes cambian el mensaje DESPUÉS de que el CUBE haya procesado el enrutamiento de llamadas y antes de que el mensaje se envíe al siguiente salto.

Otras notas sobre sip-profile Configuration: 

• Los perfiles SIP no pueden manipular los atributos m=image SDP. La mejora para esto fue archivada bajo el ID de bug Cisco CSCsr20474  Además, los perfiles SIP no pueden quitar o agregar valores a SDP. Sólo usted puede modificar estos valores. Sin embargo, es posible modificar un valor SDP en un valor nulo especificando el valor completo y, a continuación, estableciendo el resultado en un conjunto de comillas vacías sin espacio.
• No se realiza ninguna comprobación para ver si el comando actual que se está ingresando ya existe o si ya existe una versión de ese comando al ingresar comandos dentro de la clase de voz sip-profile. Si un administrador pega una línea 7 veces en un perfil SIP, se muestra 7 veces en la configuración en ejecución. Se recomienda quitar el comando que se está modificando y luego ingresar el nuevo comando al editar sip-profiles para evitar la presencia de varios comandos.

Documentación completa: Guía de configuración de Cisco Unified Border Element - Cisco IOS XE 17.6 en adelante

Herramienta de prueba de perfiles SIP: Herramienta de prueba de perfiles SIP

Sintaxis de ejemplo de perfil SIP entrante/saliente

!
voice class sip-profiles <number>
 request <message-type> sip-header <header> modify "match-pattern" "replace-pattern"
 request <message-type> sip-header <header> add "add-pattern"
 request <message-type> sip-header <header> remove 

 request <message-type> sdp-header <header> modify "match-pattern" "replace-pattern"
 request <message-type> sdp-header <header> add "add-pattern"
 request <message-type> sdp-header <header> remove

 response <number> sip-header <header> modify "match-pattern" "replace-pattern"
 response <number> sip-header <header> add "add-pattern"
 response <number> sip-header <header> remove

 response <number> sdp-header <header> modify "match-pattern" "replace-pattern"
 response <number> sdp-header <header> add "add-pattern"
 response <number> sdp-header <header> remove
!

Ejemplo de perfil SIP entrante/saliente con números

voice class sip-profiles 200
 rule 1 response ANY sip-header Remote-Party-ID modify "match-pattern" "replace-pattern"
 rule 2 response ANY sdp-header Audio-Attribute modify "match-pattern" "replace-pattern"

Métodos de aplicación de perfil SIP saliente

! Global Application 
voice service voip
 sip
  sip-profiles <number>
!
! Tenant Application
voice class tenant <tag>
 sip-profiles <tag>
!
! Dial-peer Application
dial-peer voice <tag> voip
 voice-class sip profiles <number>
!

Métodos de aplicación de perfil SIP entrante

Nota: se requiere habilitar sip-profile inbound bajo voice service voip sip si se utiliza la aplicación global, el arrendatario o la aplicación dial-peer.

! Global Application 
voice service voip
 sip
  sip-profiles inbound
  sip-profiles <number> inbound
!

! Tenant Application
voice service voip
 sip
  sip-profiles inbound
!
voice class tenant <tag>
 sip-profiles <tag> inbound
!

! Dial-Peer Application
voice service voip
 sip
  sip-profiles inbound
!
dial-peer voice <tag> voip
 voice-class sip profiles <number> inbound
!

Ejemplo de perfil SIP para modificar los mensajes de señal de mantenimiento de OPTIONS.

!
voice class sip-options-keepalive 200
 transport tcp tls
 sip-profiles 299
!

Ejemplo de perfil SIP para modificar el host, el dominio o ambas partes de un URI.

! Host
!
voice class sip-profiles 1
 request ANY sip-header Contact modify "sip:(.*)@" "sip:8675309@"
!
! Domain
!
voice class sip-profiles 2
 request ANY sip-header Contact modify "10.67.138.241:5060" "cisco.com"
!
! Note: Port is optional
!
! Modify Both User and Host
!
voice class sip-profiles 3
 request ANY sip-header Contact modify "sip:(.*)>" "sip:8675309@cisco.com>"
!

Ejemplo de perfil SIP para agregar, modificar o eliminar encabezados de desvío.

! Add
!
voice class sip-profiles 777
 request INVITE sip-header Diversion add "Diversion: <sip:1234@cisco.com>"
!
!
! Modify
!
voice class sip-profiles 888
 request INVITE sip-header Diversion modify "sip:(.*)>" "sip:1234@cisco.com>"
!
!
! Remove
!
voice class sip-profiles 999
 request INVITE sip-header Diversion remove
!

Ejemplo de perfil SIP para modificar la parte del nombre de identificación de llamada de los encabezados SIP.

!
voice class sip-profiles 123
 request INVITE sip-header From modify "\".*\"" "\"TEST CLID*\""
!

Ejemplo de perfil SIP para cambiar una sesión 183 en curso por una sesión 180 sonando.

!
voice class sip-profiles 789
 response 183 sip-header SIP-StatusLine modify "SIP/2.0 183 Session in Progress" "SIP/2.0 180 Ringing"
!

Ejemplo de perfil SIP para interoperabilidad de audio unidireccional o no unidireccional con un proveedor.

!
voice class sip-profiles 200
 request ANY sdp-header Audio-Attribute modify "a=inactive" "a=sendrecv"
 request ANY sdp-header Audio-Connection-Info modify "0.0.0.0" "10.10.10.10" 
!
! where 10.10.10.10 is CUBE's provider facing IP address

Ejemplo de perfil SIP para quitar el método UPDATE por problemas de interoperabilidad.

!
voice class sip-profiles 200
 request ANY sip-header Allow-Header modify ", UPDATE" ""
!

Ejemplo de perfil SIP que muestra el uso de SET dentro del perfil SIP. Este es el mismo concepto de conjuntos descrito en la sección voice translation-rule.

!
voice class sip-profiles 1
 request ANY sip-header Contact modify "sip:(.*)@" "sip:\1@"
!

Configuración de la lógica IF y los saltos de línea nueva con un perfil SIP.

Los saltos de línea nuevos son compatibles con los perfiles SIP; sin embargo, solo hay un caso práctico muy específico para estos. Dado que los perfiles SIP no tienen ninguna lógica If, Then, Else, ahora existe una manera de realizar modificaciones en un encabezado basándose en una entrada de otro encabezado. Por ejemplo, un administrador sólo desea modificar un encabezado de desvío si el encabezado FROM contiene 1234@cisco.com. Utilizando el salto de línea nueva podemos suplantar la sentencia IF dentro de un perfil SIP. Vea el ejemplo de configuración: Usted coincide con 1234 en cualquier dominio en el encabezado De. A continuación, vuelva al primer conjunto y agregue un nuevo salto de línea \x0D\x0AD. Por último, agregue el encabezado que desee. Observe que este método sólo le permite AGREGAR un encabezado. No hay forma de modificar otro encabezado. Por lo tanto, solo cumple parcialmente los requisitos que un administrador deseaba alcanzar anteriormente.

!
voice class sip-profiles 1
 request INVITE sip-header From modify “(.*sip:1234@.*)” “\1\x0D\x0ADiversion: <sip:5678@example.com>”
!

Ejemplo de perfil SIP con lógica OR.

!
voice class sip-profiles 123
 request ANY sdp-header Audio-Attribute modify "(a=sendonly|a=recvonly|a=inactive)" "a=sendrecv"
 response ANY sdp-header Audio-Attribute modify "(a=sendonly|a=recvonly|a=inactive)" "a=sendrecv"
!

Ejemplo de inspección SIP de capa 7 mediante perfil SIP.

### Usage
10.21.15.10 replace with private IP of CUBE
a.b.c.d replace with public IP
------------------------------------------------------

### Inbound from ITSP Layer 7 Fixup
!
voice class sip-profiles 888
 request INVITE sip-header SIP-Req-URI modify "@.*;" "@10.21.15.100;"
!
voice service voip
 sip
  sip-profiles inbound
!

### Outbound Layer 7 Fixup
!
voice class sip-profiles 777
 request ANY sip-header Contact modify "<sip:(.*)@10.21.15.100:5060>" "<sip:\1 a.b.c.d:5060>" 
 response ANY sip-header Contact modify "<sip:(.*)@10.21.15.100:5060>" "<sip:\1 a.b.c.d:5060>" 
 request ANY sip-header Via modify "SIP(.*) 10.21.15.100(.*)" "SIP\1 a.b.c.d\2" 
 request ANY sdp-header Session-Owner modify "(.*IP4 ).*" "\1a.b.c.d" 
 request ANY sdp-header Connection-Info modify "IN IP4 10.21.15.100" "IN IP4 a.b.c.d" 
 request ANY sdp-header Audio-Connection-Info modify "IN IP4 10.21.15.100" "IN IP4 a.b.c.d" 
 response ANY sdp-header Session-Owner modify "(.*IP4 ).*" "\1a.b.c.d" 
 response ANY sdp-header Audio-Connection-Info modify "IN IP4 10.21.15.100" "IN IP4 a.b.c.d" 
 response ANY sdp-header Connection-Info modify "IN IP4 10.21.15.100" "IN IP4 a.b.c.d"
 request ANY sip-header Remote-Party-ID modify "<sip:(.*)@10.21.15.100>" "<sip:\1 a.b.c.d>" 
 response ANY sip-header Remote-Party-ID modify "<sip:(.*)@10.21.15.100>" "<sip:\1 a.b.c.d>"
!

### Apply to dial-peers for the side of the CUBE facing the ITSP
!
dial-peer voice 1 voip
 voice-class sip profiles 777
 voice-class sip profile 888 inbound
!
dial-peer voice 2 voip
 voice-class sip profiles 777
 voice-class sip profile 888 inbound
!

Copylist SIP

Las listas de copia SIP son una extensión de los perfiles SIP que permite que el gateway COPIE un encabezado del segmento interno de una llamada y, a continuación, PEGUE en otro punto del mensaje SIP de salida del segmento externo. La compatibilidad con la lista de copia SIP se agregó en Cisco IOS 15.1(3)T y Cisco IOS XE 3.6S. Se trata de una forma muy eficaz de crear encabezados dinámicos basados en otros encabezados del segmento interno de la llamada.

El caso práctico más común es copiar dinámicamente un encabezado FROM a un encabezado diferente como diversion o p-asserted-id para que el valor de la parte de usuario sea el usuario from. Esto se realiza principalmente para fines de autenticación e identificación de llamadas.

Documentación completa: Guía de configuración de Cisco Unified Border Element - Cisco IOS XE 17.6 en adelante

Ejemplo de Copylist SIP

!
! Create Copylist to copy the FROM header on the inbound message specified later.
!
voice class sip-copylist <number>
 sip-header From
!
! Apply this to the inbound dial-peer of the call.
!
dial-peer voice <tag> voip
 voice-class sip copy-list <number>
!
! Create SIP Profile to take From (peer-header) stored as variable "u01" and apply to a header of choice.
! This example modifies the user portion of the Contact by copying the user portion of the From header to the user portion of the Contact header.
!
voice class sip-profiles <number>
 request INVITE peer-header sip From copy "<sip:(.*)@" u01
 request INVITE sip-header Contact modify "<sip:(.*)>" "<sip:\u01@10.50.244.2>" 
!
! Apply the SIP profile to an outbound dial-peer
!
dial-peer voice <tag> voip
 voice-class sip profiles <number>
!

Depuración de Perfiles SIP y Copylist

debug voip ccapi inout
debug ccsip mess
debug ccsip info
debug ccsip feature sip-profile 

Salida de depuración de la lista de copias SIP de ejemplo

### Ingress from CUCM
Received:
INVITE sip:1001@10.50.228.61:5060 SIP/2.0
Via: SIP/2.0/TCP 10.50.244.3:5060;branch=z9hG4bKaad21bc3ae7e
From: "5001" <sip:5001@10.50.244.3>;tag=100442~cdffff43-5020-4e79-a10b-99d406971010-36470319
Contact: <sip:5001@10.50.244.3:5060;transport=tcp>

### Copylist Details
00440: Mar  8 18:59:49.796: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_peer_copy_pattern: sed_match succeeded
000441: Mar  8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_application_peer_copy_pattern: SIP Profiles COPY variables AVL tree created
000442: Mar  8 18:59:49.797: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_prefix_slash_in_copy_var_val: ret_dst: 5001
000443: Mar  8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_application_peer_copy_pattern: SIP Profiles COPY variable: u1 val: 5001
000444: Mar  8 18:59:49.797: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_modify_remove_header: Header before modification : Contact: <sip:5001@10.50.228.61:5060>
000445: Mar  8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_check_and_get_variables_in_replace_pattern: Node found: COPY variable: u1 val: 5001
000446: Mar  8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_check_and_get_variables_in_replace_pattern: substituted_replace_pattern :  : @168.117.64.94>
000448: Mar  8 18:59:49.797: //187/D6138E000000/SIP/Info/info/64/sip_profiles_check_and_get_variables_in_replace_pattern: Final substituted_replace_pattern : <sip:5001@168.117.64.94>
000449: Mar  8 18:59:49.797: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_app_modify_header: Passing substituted replace pattern
000450: Mar  8 18:59:49.798: //-1/xxxxxxxxxxxx/SIP/Info/info/64/sip_profiles_application_modify_remove_header: Header after modification : Contact: <sip:5001@168.117.64.94>
000451: Mar  8 18:59:49.798: //187/D6138E000000/SIP/Msg/ccsipDisplayMsg:

### Egress from CUBE
Sent:
INVITE sip:1001@14.50.228.63:5060 SIP/2.0
Via: SIP/2.0/UDP 10.50.228.61:5060;branch=z9hG4bK3C7CD
Remote-Party-ID: "5001" <sip:5001@10.50.228.61>;party=calling;screen=yes;privacy=off
From: "5001" <sip:5001@10.50.228.61>;tag=34C458-D6
Contact: <sip:5001@168.117.64.94>

Notas especiales

Señalización de protocolo y enlace de medios

Todos los protocolos de señalización permiten a los administradores la capacidad de vincular la señalización a una interfaz específica. De forma predeterminada, una puerta de enlace sin un enlace definido estático y, a continuación, la puerta de enlace origina la señalización de una llamada desde la interfaz física que atraviesa el paquete. Con el enlace en un par de marcado, el paquete incluye encabezados de origen, mensajería y paquetes de la interfaz especificada, pero el paquete real todavía se enruta a través de la interfaz física. El enlace de par de marcado siempre reemplaza al enlace voip del servicio de voz global y del arrendatario de clase de voz con el protocolo de inicio de sesión (SIP).

Muchas veces los administradores enlazan la señalización a un loopback. Al ser una interfaz lógica, ningún paquete atraviesa esta interfaz. Para realizar capturas de paquetes, la captura debe realizarse en una interfaz física. El comando show ip cef <remote-ip> muestra la interfaz física que un paquete utiliza para rutear a la IP de destino/remota incluso si la configuración está vinculada a una interfaz virtual.

El enlace de medios y señalización no siempre tiene que ser la misma IP. Si un administrador necesita enlazar a una interfaz específica para la señalización a / desde un CUCM pero el audio / medios entre el teléfono y el gateway puede necesitar enlazar a otra interfaz.

Ejemplo de configuración

Este ejemplo muestra un par de marcado enlazado al loopback 1 y recibe una llamada de CUCM.

Aunque los medios y la señalización (control) están enlazados al loopback 1, el comando show ip cef muestra que cualquier paquete enviado a CUCM sale de la interfaz física GigabitEthernet0/0/1.

!
dial-peer voice 2 voip
 description "Incoming call from CUCM"
 session protocol sipv2
 incoming called-number .
 voice-class sip bind control source-interface Loopback1
 voice-class sip bind media source-interface Loopback1
!

Orden de operaciones para enlace de aplicaciones de capa 7

1. Según la sentencia bind en el dial-peer entrante/saliente coincidente.
2. De acuerdo con los enlaces bajo el arrendatario de clase de voz asignado al par de marcado entrante/saliente coincidente.
3. De acuerdo con la declaración vinculante global.
4. Según la interfaz física de capa 3, se espera que el paquete salga en función de la tabla de ruteo.

Comandos de enlace SIP

! Per Dial-peer
!
dial-peer voice 1 voip
 voice-class sip bind control source-interface <interface>
 voice-class sip bind media source-interface <interface>
!
! Global Binding
!
voice service voip
 sip
   bind control source-interface <interface>
   bind media source-interface <interface>
!

Comandos de enlace MGCP

!
mgcp bind control source-interface <interface>
mgcp bind media source-interface <interface>
!

Comandos de enlace SCCP

!
sccp local <interface>
!
sccp ccm group <number>
 bind interface <interface>
!

Comandos de enlace H323

!
inteface <interface>
 !
 ! Media Bind Command:
 h323-gateway voip interface
 !
 ! Signaling Bind Command:
 h323-gateway voip bind srcaddr <a.b.c.d>
!

Pares de marcado DNS y VoIP

DNS con VOIP se utiliza como cualquier otra solución DNS. Una configuración común es utilizar dns de destino de sesión:FQDN.com.

Una puerta de enlace de Cisco realiza una resolución DNS incluso cuando no se ha configurado globalmente ninguna búsqueda de dominio IP en la puerta de enlace. Esto significa que aunque esté inhabilitando DNS, los pares de marcado VOIP aún resuelven la entrada DNS. Sin embargo, recientemente en Cisco IOS XE 3.16S hubo algunos cambios en la funcionalidad general de DNS dentro de las plataformas Cisco IOS XE.

Después de este cambio, los pares de marcado configurados con dns de destino de sesión:FQDN.com ahora obedecen al hecho de que DNS está inhabilitado sin búsqueda de dominio IP.
Recomiendo asegurarse siempre de que el comando "ip domain lookup" esté configurado cuando se trabaje con DNS para evitar este problema.

Para las conexiones SIP salientes, CUBE realiza este orden de operaciones para la resolución DNS.

1. búsqueda de consulta SRV
2. Búsqueda de registros
3. Búsqueda de registros AAAA

Para obtener información sobre cómo se crea el SRV, o cómo saltar el SRV y realizar una consulta de registro A en un destino de sesión, refiérase a la documentación completa: Guía de Configuración de Cisco Unified Border Element - Cisco IOS XE 17.6 en adelante

Para las conexiones SIP entrantes en las que un gateway IOS necesita resolver un encabezado para responder a un mensaje, el gateway puede utilizar este orden de operaciones para la resolución DNS

1. Búsqueda de registros
2. Búsqueda de registros AAAA

En Cisco IOS XE 17.9.1, CUBE puede verificar la disponibilidad de los destinos de sesión DNS por medio de mecanismos de señal de mantenimiento de opciones. Consulte la documentación completa:

Guía de configuración de Cisco Unified Border Element - Cisco IOS XE 17.6 en adelante

Ejemplos de Configuración de DNS de IOS

ip host _sip._udp.cucmgroup.lab.local srv 1 50 5060 cucm1.lab.local
ip host _sip._udp.cucmgroup.lab.local srv 1 50 5060 cucm2.lab.local
ip host _sip._udp.cucmgroup.lab.local srv 1 50 5060 cucm3.lab.local

ip host cucm1.lab.local 10.0.0.1
ip host cucm2.lab.local 10.0.0.2
ip host cucm3.lab.local 10.0.0.3

ip domain name lab.local
ip name-server 8.8.8.8

Nota: La compatibilidad con DNS SRV en Cisco IOS XE se admite en 15.6(1)S / 3.17.00.S y versiones posteriores.

Comandos de verificación y depuración de DNS

show host
clear host all *
!
debug ip dns view
debug ip domain
debug ccsip info
debug ccsip error

DNS Testing 3.15S y posteriores

### Domain Name Verification
Gateway# sh run | s lookup
no ip domain lookup

### Checking the host table for no entry
Gateway# show host
Name lookup view: Global
Default domain is cisco.com
Name/address lookup uses static mappings

Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate
       temp - temporary, perm - permanent
       NA - Not Applicable None - Not defined

Host                      Port  Flags      Age Type   Address(es)

### Verification of no PING on a FQDN
Gateway# ping cucm.cisco.com
Translating "cucm.cisco.com"
% Unrecognized host or address, or protocol not running.

### Made a test call here

### Checking logs to see if it worked
Gateway# sh log | s INVITE sip:
INVITE sip:9001@14.50.228.70:5060 SIP/2.0
INVITE sip:5001@cucm.cisco.com:5060 SIP/2.0

### Host Table now has an entry
Gateway# sh host
Name lookup view: Global
Default domain is cisco.com
Name/address lookup uses static mappings

Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate
       temp - temporary, perm - permanent
       NA - Not Applicable None - Not defined

Host                      Port  Flags      Age Type   Address(es)
cucm.cisco.com            None  (temp, OK)  0   IP    10.50.244.2

### CCSIP All output showing a proper DNS Query for the FQDN on the dial-peer.
001338: Mar  9 15:29:07.437: //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_free: Freed msg=0x7FE9873AE560
001339: Mar  9 15:29:07.437: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_srv_query: TYPE SRV query for _sip._udp.cucm.cisco.com and type:1
001340: Mar  9 15:29:07.438: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: DNS query for cucm.cisco.com and type:1
001341: Mar  9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_a_query: TYPE A query successful for cucm.cisco.com
001342: Mar  9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_query: ttl for A records = 3600 seconds
001343: Mar  9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: IP Address of cucm.cisco.com is:
001344: Mar  9 15:29:07.441: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: 10.50.244.2

DNS Testing 3.16S y superior.

### Checking the command is present
Gateway# sh run | s lookup
no ip domain lookup

### Verifying the gateway cannot ping a FQDN
Gateway# ping cucm.cisco.com
% Unrecognized host or address, or protocol not running.

### Checking the Host Table for entries
Gateway# sh host
Default domain is cisco.com
Name servers are 10.50.244.52
NAME  TTL  CLASS   TYPE      DATA/ADDRESS
-----------------------------------------

### Made a test call here

### CCSIP All Outbound showing the failed call
000974: *Mar  9 15:53:01.222: //-1/xxxxxxxxxxxx/SIP/Info/info/1024/httpish_msg_free: Freed msg=0x7FF31DAAA848
000975: *Mar  9 15:53:01.222: //-1/xxxxxxxxxxxx/SIP/Info/notify/8192/sip_dns_type_srv_query: TYPE SRV query for _sip._udp.cucm.cisco.com and type:1
000976: *Mar  9 15:53:01.224: //-1/xxxxxxxxxxxx/SIP/Info/info/8192/sip_dns_type_a_aaaa_query: DNS query for cucm.cisco.com and type:1
000977: *Mar  9 15:53:01.225: //-1/xxxxxxxxxxxx/SIP/Error/sip_dns_type_a_query:
 TYPE A query failed for cucm.cisco.com
000978: *Mar  9 15:53:01.225: //-1/xxxxxxxxxxxx/SIP/Error/_send_dns_fail:
 DNS Query for cucm.cisco.com failed
000984: *Mar  9 20:53:01.225: %VOICE_IEC-3-GW: SIP: Internal Error (DNS query fail): IEC=10.1.128.7.47.0 on callID 6 GUID=37B668DF044111E7A950D832C82B325C

Conexiones y ancho de banda máximos

De forma predeterminada, los pares de marcado VOIP y POTS permiten conexiones ilimitadas (llamadas) y ancho de banda (sólo pares de marcado VOIP). Para los trunks que tienen un límite en el número de llamadas o ancho de banda que se pueden utilizar, puede ser útil emplear los comandos max-conn o max-bandwidth. max-conn se agregó en Cisco IOS 11.3(1)T y está presente en todas las versiones de Cisco IOS XE mientras que max-bandwidth se agregó en 15.2(2)T e IOS-XE 3.7S.

Ejemplo de configuración:

Aquí le indica al gateway que limite el par de marcado de 1 a 30 llamadas usando "max-conn 30".
El par de marcado 2 está limitando el ancho de banda para ese par de marcado de modo que no excedamos el límite asignado.

!
dial-peer voice 1 voip
 description ITSP SIP Trunk - 30 Max Calls!
 session protocol sipv2
 sess target ipv4:10.10.10.10
 destination-pattern 8675309$
 max-conn 30
!
dial-peer voice 2 voip
 description SIP Trunk with Bandwidth Restrictions!
 session protocol sipv2
 sess target ipv4:10.10.10.10
 destination-pattern 123456789$
 max-bandwidth 400
!

Error de ejemplo cuando se cruza el umbral de conexión máxima.

000308: Oct  5 19:01:02.603: %CALL_CONTROL-6-MAX_CONNECTIONS: Maximum number of connections reached for dial-peer 1
 
000309: Oct  5 19:01:02.603: %VOICE_IEC-3-GW: CCAPI: Internal Error (Dial-peer connections exceeded): IEC=10.1.181.1.21.0 on callID 0
000310: Oct  5 19:01:02.604: %SIP-3-MAXCONNCAC: Call rejected due to CAC based on maximum number of connections on dial-peer 1, sent response 503

000311: Oct  5 19:01:02.604: //17084/86B070800000/SIP/Msg/ccsipDisplayMsg:
Sent:
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/TCP 10.50.244.62:5060;branch=z9hG4bKb78c35aa21b0
From: <sip:9001@10.50.244.62>;tag=72531~2e8ca155-3f0b-4f07-a1b2-b14ef77ceb7f-26250846
To: <sip:1234@10.50.245.70>;tag=3E19564D-1684
Date: Thu, 05 Oct 2017 19:01:02 GMT
Call-ID: 86b07080-9d61816e-b762-3ef4320e@10.50.244.62
CSeq: 101 INVITE
Allow-Events: telephone-event
Warning: 399 10.50.245.70 "Maximum Number of Connections reached for dial-peer 1"
Server: Cisco-SIPGateway/IOS-15.4.3.S4
Content-Length: 0

Marcación entrante directa (DID)

Marcación en una etapa

Con la marcación entrante directa habilitada en los pares de marcado POTS, los mensajes entrantes pueden contener todos los dígitos necesarios para rutear la llamada. La puerta de enlace de Cisco no puede realizar una recopilación de dígitos posterior. Cuando el router o la gateway buscan un par de marcado saliente, el dispositivo utiliza la cadena de marcado entrante completa. Esta coincidencia es de longitud variable de forma predeterminada. Esta coincidencia no se realiza dígito por dígito porque, según la definición de DID, se han recibido todos los dígitos. Ésta es la configuración predeterminada para los pares de marcado POTS.

Documentación completa: Introducción a Direct-Inward-Dial (DID) en interfaces IOS Voice Digital (T1/E1)

Ejemplo de configuración

!
dial-peer voice 1 pots
 incoming called-number 8675309
 voice-port 0/0/0
 direct-inward-dial
!

Marcación en dos fases

Si el par de marcado POTS entrante se configura con no direct-inward-dial, el router o la gateway ingresa al modo de recolección de dígitos (los dígitos se recolectan dentro de la banda). La coincidencia de pares de marcado salientes se realiza dígito por dígito. El router o la gateway verifica las coincidencias de pares de marcado después de que el dispositivo haya recibido cada dígito y luego enruta la llamada cuando se realiza una coincidencia completa.

Ejemplo de configuración

!
dial-peer voice 1 pots
 incoming called-number 8675309
 voice-port 0/0/0
 no direct-inward-dial
!

Bloqueo de llamadas

Cada protocolo gestiona el bloqueo de llamadas de forma un poco diferente. La mayoría de los protocolos pueden hacer uso del patrón de rechazo de regla de traducción que bloquea basándose en una cadena de dígitos. Si un administrador desea seguir aplicando un perfil de traducción entrante para la manipulación normal de dígitos, pero no bloquear ningún número dentro de, existe la opción de implementar un bloque de llamada mediante el comando call-block translation-profile.

!
voice translation-rule 164
 rule 1 reject /8675309/
!
voice translation-profile CALLBLOCK
 translate calling 164
!
dial-peer voice 1 pots
 desc INCOMING VOICE-PORT with BLOCK
 translation-profile incoming ANOTHER
 call-block translation-profile incoming CALLBLOCK
 call-block disconnect-cause incoming invalid-number
 incoming called-number .
 port 0/0/0:23
!

Gateway#test voice translation-rule 164 8675309
8675309 blocked on rule 1

En E1 R2 existe la posibilidad de que un administrador bloquee las llamadas a cobro revertido. Esto se ve y se utiliza principalmente en implementaciones de Brasil, pero se puede configurar a través de cualquier grupo personalizado de casos.

Las dos opciones son:

1. Bloquee la llamada a cobro revertido entrante según la categoría II-8 que se recibe del switch de la compañía telefónica. Este es el mecanismo predeterminado y todos los gateways de Cisco lo realizan sin ninguna configuración. Este método de bloqueo requiere un switch de compañía telefónica más reciente que admita el marcado basado en categorías. Para inhabilitar este método, utilice el comando collect-call-enable en el grupo cas-customer.
2. Utilice la función de respuesta doble en un grupo personalizado CAS R2-digital E1 R2. La configuración de respuesta doble desactiva el bloqueo basado en categorías y lo sustituye por la función de respuesta doble. Esto funciona respondiendo primero a la llamada entrante e iniciando un temporizador de 1 segundo. Después de 1 segundo, el gateway envía una versión en forma de un comando CLEAR BWD. La compañía telefónica puede entonces enviar un CLEAR FWD al gateway y la llamada se puede desconectar. Un temporizador se inicia después de que el gateway envía el CLEAR BWD y, si este temporizador caduca, el gateway envía otra señal de RESPUESTA, suponiendo que la llamada no es una llamada a cobro revertido y desde aquí la llamada continúa de la forma habitual. Este temporizador se puede configurar usando cc-reanswer-to dentro del grupo cas-custom.

Mensaje de bloque de categoría II-8 (debug vpm signal)

009228: Nov 21 12:02:00.955 GMT: //-1/BF12BE36BAC8/VTSP:(0/0/0:0):-1:1:2/vtsp_report_cas_digit: 
   Begin Digit=8, Mode=CC_TONE_R2_MF_BACKWARD_MODE
009229: Nov 21 12:02:00.955 GMT: htsp_digit_ready_up(0/0/0:0(2)): Rx digit='8'
009230: Nov 21 12:02:00.955 GMT: R2 Incoming Voice(0/0): DSX (E1 0/0/0:1): STATE: R2_IN_CATEGORY R2 Got Event 8
009231: Nov 21 12:02:00.955 GMT: Enter r2_comp_category
009232: Nov 21 12:02:00.955 GMT:  R2 Event : 8
009233: Nov 21 12:02:00.955 GMT:  #######R2_II8 TRUE########
009234: Nov 21 12:02:00.955 GMT:  ####### collect_call_enable = 0
009235: Nov 21 12:02:00.955 GMT:  ############sending B7 ##########
009236: Nov 21 12:02:00.955 GMT: r2_reg_generate_digits(0/0/0:0(2)): Tx digit '7'
009237: Nov 21 12:02:01.055 GMT: //-1/BF12BE36BAC8/VTSP:(0/0/0:0):-1:1:2/vtsp_report_cas_digit: 
   End Digit=8, Mode=CC_TONE_R2_MF_BACKWARD_MODE
009238: Nov 21 12:02:01.055 GMT: htsp_digit_ready(0/0/0:0(2)): Rx digit='#'
009239: Nov 21 12:02:01.055 GMT: R2 Incoming Voice(0/0): DSX (E1 0/0/0:1): STATE: R2_IN_CATEGORY R2 Got Event R2_TONE_OFF
009240: Nov 21 12:02:01.055 GMT: Enter r2_comp_category
009241: Nov 21 12:02:01.055 GMT: r2_reg_generate_digits(0/0/0:0(2)): Tx digit '#'
009242: Nov 21 12:02:01.359 GMT: htsp_dsp_message: SEND_SIG_STATUS: state=0x8 timestamp=22365 systime=225097425
009243: Nov 21 12:02:01.359 GMT: htsp_process_event: [0/0/0:0(2), R2_Q421_IC_WAIT_ANSWER, E_DSP_SIG_1000]
009244: Nov 21 12:02:01.359 GMT: r2_q421_ic_clr_fwd_idle(0/0/0:0(2)) Rx CLEAR FWD
009245: Nov 21 12:02:01.359 GMT: r2_reg_channel_disconnected(0/0/0:0(2))
009246: Nov 21 12:02:01.359 GMT: R2 Incoming Voice(0/0): DSX (E1 0/0/0:1): STATE: R2_IN_CATEGORY R2 Got Event R2_STOP
009247: Nov 21 12:02:01.359 GMT: Enter r2_comp_category
009248: Nov 21 12:02:01.359 GMT: htsp_timer - 2000 msec
009249: Nov 21 12:02:01.359 GMT: htsp_process_event: [0/0/0:0(2), R2_Q421_IC_CLR_FWD, E_HTSP_RELEASE_REQ]
009250: Nov 21 12:02:01.359 GMT: r2_q421_null_release(0/0/0:0(2)) E_HTSP_RELEASE_REQ
009251: Nov 21 12:02:01.359 GMT: r2_reg_process_event: [0/0/0:0(2), R2_REG_COLLECTING, E_R2_REG_DISCONNECT(91)]
009252: Nov 21 12:02:01.359 GMT: r2_reg_disconnect_collect(0/0/0:0(2))
009253: Nov 21 12:02:01.359 GMT: r2_reg_timer_stop(0/0/0:0(2))
009254: Nov 21 12:02:01.711 GMT: htsp_process_event: [0/0/0:0(1), R2_Q421_IC_CLR_FWD, E_HTSP_EVENT_TIMER]
009255: Nov 21 12:02:01.711 GMT: htsp_timer_stop
009256: Nov 21 12:02:01.711 GMT: r2_q421_clr_fwd_idle(0/0/0:0(1)) Tx IDLEvnm_dsp_set_sig_state:[R2 Q.421 0/0/0:0(1)] set signal state = 0x8
009257: Nov 21 12:02:01.711 GMT: r2_reg_channel_disconnected(0/0/0:0(1))
009258: Nov 21 12:02:01.711 GMT: //682206/0C63B263B9C9/VTSP:(0/0/0:0):0:1:1/vtsp_do_call_history: 
   Coder Rate=5
009259: Nov 21 12:02:01.711 GMT: r2_reg_process_event: [0/0/0:0(1), R2_REG_IDLE, E_R2_REG_DISCONNECT(91)]

Ejemplo de Configuración de Doble Respuesta

!
controller e1 0/0/0
 ds0-group 0 timeslots 1-15,17-31 type r2-digital r2-compelled ani
 cas-custom 0
  country brazil
  double-answer
  cc-reanswer-to 3000
!

Depuraciones de doble respuesta (señal debug vpm)

### Answer the call and start a 1 second timer
May 23 09:52:59.180 BR: r2_q421_ic_answer(0/0/0:0(18)) Tx ANSWER seizure: delay 0 ms,elapsed 12404 msvnm_dsp_set_sig_state:[R2 Q.421 0/0/0:0(18)] set signal state = 0x4
May 23 09:52:59.180 BR: r2_reg_channel_connected(0/0/0:0(18))
May 23 09:52:59.180 BR: htsp_timer - 1000 msec
May 23 09:52:59.180 BR: //23899578/92233E71B421/CCAPI/cc_api_voice_mode_event:
   Call Id=23899578
May 23 09:52:59.180 BR: //23899578/92233E71B421/CCAPI/cc_api_voice_mode_event:
   Call Entry(Context=0x1E73AD8)
May 23 09:52:59.180 BR: htsp_process_event: [0/0/0:0(18), R2_Q421_IC_DOUBLE_ANS_ANS, E_HTSP_VOICE_CUT_THROUGH] all
May 23 09:52:59.184 BR: //23899578/92233E71B421/CCAPI/cc_process_notify_bridge_done:
   Conference Id=0x10AD1, Call Id1=23899578, Call Id2=23899579
May 23 09:52:59.184 BR: r2_reg_process_event: [0/0/0:0(18), R2_REG_WAIT_FOR_CONNECT, E_R2_REG_CONNECT(90)] 
May 23 09:52:59.184 BR: r2_reg_connect(0/0/0:0(18))

### One Second Passes and we clear the call and start a 2 second timer
May 23 09:53:00.180 BR: htsp_process_event: [0/0/0:0(18), R2_Q421_IC_DOUBLE_ANS_ANS, E_HTSP_EVENT_TIMER]
May 23 09:53:00.180 BR: r2_q421_ic_d_answ_answ_to(0/0/0:0(18)) E_TIMER_EVENT
May 23 09:53:00.180 BR: htsp_timer - 2000 msec
May 23 09:53:00.180 BR: r2_q421_ic_d_answ_answ_to(0/0/0:0(18)) Tx CLEAR BWDvnm_dsp_set_sig_state:[R2 Q.421 0/0/0:0(18)] set signal state = 0xC
May 23 09:53:00.824 BR: htsp_process_event: [0/0/0:0(18), R2_Q421_IC_DOUBLE_ANS_RLS, E_DSP_SIG_1000]
May 23 09:53:00.824 BR: r2_q421_ic_answer_clr_fwd(0/0/0:0(18)) Rx CLEAR FWD
May 23 09:53:00.824 BR: r2_reg_channel_disconnected(0/0/0:0(18))
May 23 09:53:00.824 BR: htsp_timer - 2000 msec
May 23 09:53:00.824 BR: r2_reg_process_event: [0/0/0:0(18), R2_REG_CONNECTED, E_R2_REG_DISCONNECT(91)] 
May 23 09:53:00.824 BR: r2_reg_disconnect_idle(0/0/0:0(18))
May 23 09:53:00.824 BR: R2 Incoming Voice(0/0): DSX (E1 0/0/0:17): STATE: R2_IN_IDLE R2 Got Event R2_STOP
May 23 09:53:00.824 BR: r2_reg_timer_stop(0/0/0:0(18))

### 2 second passes and the gateway release the call
May 23 09:53:02.824 BR: htsp_process_event: [0/0/0:0(18), R2_Q421_IC_CLR_FWD, E_HTSP_EVENT_TIMER]
May 23 09:53:02.824 BR: htsp_timer_stop 
May 23 09:53:02.824 BR: r2_reg_channel_disconnected(0/0/0:0(18))
May 23 09:53:02.824 BR: //23899578/92233E71B421/VTSP:(0/0/0:0):17:1:1/vtsp_cc_call_disconnected:  
   Cause Value=16
May 23 09:53:02.824 BR: //23899578/92233E71B421/CCAPI/cc_api_call_disconnected:
   Cause Value=16, Interface=0xB41CEBC, Call Id=23899578

recepción superpuesta ISDN

Hay implicaciones para la coincidencia de dial-peer entrante cuando el comando isdn superposición-receiving se configura en las interfaces ISDN. Después de recibir cada dígito en la capa ISDN, se verifican las coincidencias de los pares de marcado. Si se realiza una coincidencia completa, la llamada se enruta inmediatamente (a la aplicación de sesión en este caso) sin esperar dígitos adicionales. El terminador T se puede utilizar para suspender esta coincidencia dígito a dígito y forzar al router o gateway a esperar hasta que se reciban todos los dígitos. El T se refiere al temporizador entre dígitos T302 en el nivel ISDN, configurable bajo la interfaz serial asociada con la interfaz ISDN. ISDN también proporciona otros mecanismos para indicar el fin de los dígitos, como la configuración del Elemento de información de envío completo (IE) en los mensajes de información Q.931.

Número llamado vacío

El mensaje de advertencia que se muestra se muestra cuando el par de marcado está configurado con el número T llamado entrante.

Ejemplo de Salida

Gateway(config)# dial-peer voice 1 pots
Gateway(config-dial-peer)# incoming called-number T
Warning: Pattern T defines a match with zero or more digits and hence could 
match with an empty number. If this is not the desired behaviour please 
configure pattern .T instead to match on one or more digits

Notas especiales sobre la coincidencia de par de marcado entrante con un número llamado vacío.

• Un número llamado nulo se considera menos calificado en comparación con un puerto de voz y/o en algunos casos una dirección de respuesta. Por lo tanto, una coincidencia basada en un número llamado nulo puede ocurrir solamente si no hay una coincidencia basada en la dirección de respuesta o el número de puerto.

• En caso de marcado superpuesto, un número llamado nulo no coincide con el número T llamado entrante porque no se ha producido el tiempo de espera.

• Un número llamado nulo puede coincidir con el número llamado entrante T solamente en el caso de ENBLOCK y no hay coincidencia debido a answer-address y port-number. La advertencia que se muestra cuando un administrador configura el número de llamada entrante T se refiere a este caso específico.

Clase de restricción

La clase de restricción (COR) es una forma de limitar las llamadas en un gateway de Cisco. COR se describe a menudo como un mecanismo de bloqueo y llave. Los bloqueos se asignan a pares de marcado con una lista COR saliente. Las claves se asignan a pares de marcado con una lista COR entrante. Cuando se aplican listas COR, los pares de marcado salientes disponibles son aquellos que la tecla puede desbloquear. Este filtrado se produce antes de que se verifique el resto de los métodos de coincidencia de pares de marcado salientes.

Dos reglas importantes con clase de restricción:

1. Si no hay lista COR saliente aplicada, la llamada siempre se enruta.
2. Si no hay ninguna lista COR entrante, la llamada siempre se enruta.

La configuración de la clase de restricción (COR), la clase de restricción de partición lógica (LPCOR) y LPCOR con códigos de autorización forzosos (FAC) están fuera del alcance de este documento, pero se puede hacer referencia a estos documentos para su lectura posterior.

Dial-peers de Cisco Unified Communications Manager Express (CUCME)

CME crea pares de marcado del sistema para los grupos de registros de voz y teléfonos móviles. No se pueden ver en la configuración en ejecución. Para realizar cambios en los pares de marcado CME, los cambios deben realizarse en el agrupamiento real de registro de voz o ephone. Al ver las salidas del resumen de voz de show dial-peer, los dial-peer que comienzan con 2000 son teléfonos SCCP y los dial-peers que comienzan con 4000 son agrupamientos de registro de voz SIP. Este par de marcado se muestra como par de marcado entrante para llamadas de teléfonos registrados de CME y par de marcado saliente en depuraciones para llamadas a teléfonos registrados de CME.

Salida de ejemplo para show dial-peer voice summary with CME.

Gateway# show dial-peer voice sum | s 2000|4000
20001  pots  up   up             1001$              0                           50/0/1
20002  pots  up   up             4001$              0                           50/0/2
20003  pots  up   up             4002$              0                           50/0/3
20004  pots  up   up             7001$              0                           50/0/4
20005  pots  up   up             3009$              0                           50/0/5
20006  pots  up   up             8810....$          0                           50/0/10
20007  pots  up   up             8811....$          0                           50/0/11
40001  voip  up   up             14085151111$       0  syst ipv4:14.50.214.67:50
40002  voip  up   up             19725252222$       0  syst ipv4:14.50.214.67:50
40003  voip  up   up             85225353333$       0  syst ipv4:14.50.214.67:50
40004  voip  up   up             442084445555$      0  syst ipv4:14.50.214.67:50
40005  voip  up   up             911$               0  syst ipv4:14.50.214.67:50
40006  voip  up   up             18005550100$       0  syst ipv4:14.50.214.67:50
40008  voip  up   up             2001$              0  syst ipv4:14.50.214.51:50

 Ejemplo de salida para show voice register dial-peers with SIP CME.

Gateway# show voice register dial-peers
Dial-peers for Pool 2:

dial-peer voice 40006 voip
 destination-pattern 14085151111$
 session target ipv4:14.50.214.67:5060
 session protocol sipv2
 dtmf-relay rtp-nte
 digit collect kpml
 codec  g711ulaw bytes 160
 no vad
  call-fwd-all         8888
  after-hours-exempt   FALSE

dial-peer voice 40005 voip
 destination-pattern 19725252222$
 session target ipv4:14.50.214.67:5060
 session protocol sipv2
 dtmf-relay rtp-nte
 digit collect kpml
 codec  g711ulaw bytes 160
 no vad
  after-hours-exempt   FALSE

MGCP y SCCP con Dial-Peers

MGCP y SCCP siguen sus propias reglas para los pares de marcado. El único concepto que utilizan es que deben configurarse con el puerto de voz deseado para la llamada. El resto lo gestiona el proceso STCAPP y MGCPAPP. Cuando examina la configuración de estos pares de marcado, tienen el comando service mgcpapp o service stcapp. Estos habilitan el par de marcado para la aplicación de elección, así como le indican a la aplicación qué par de marcado puede manejar.

Al depurar estos protocolos, el resultado nunca muestra una coincidencia de dial-peer entrante. Esto siempre puede mostrarse como dial-peer 0. Porque no existe. El agente de llamadas que maneja la aplicación ya ha elegido a qué puerto enviar la llamada y la coincidencia de par de marcado entrante es inútil ya que el gateway no tiene control sobre ese tramo de la llamada. Sin embargo, se puede observar una coincidencia de par de marcado saliente. Esto es meramente para show ya que, en última instancia, el agente de llamada que maneja el proceso también tiene control sobre ese lado de la llamada.

Recuerde, el par de marcado sólo le indica a la aplicación de elección qué puerto de voz físico controlar. Dado que la mayor parte de esto es controlado por un agente de llamadas externo y el gateway, simplemente hace lo que se le dice. Va a omitir el procedimiento subyacente de esta sección y proporcionar algunas configuraciones para comenzar.

Configuración de muestra de MGCP [con configuración automática de CUCM*]

!
mgcp call-agent 10.10.10.10
mgcp
!
ccm-manager mgcp [codec-all]
ccm-manager config server 10.10.10.10
ccm-manager config
ccm-manger redundant-host 10.10.10.20
!
voice-port 0/0/0
 description The MGCP port to register
 no shut
!
dial-peer voice 1 pots
 description Defining the Port for the MGCP application
 service mgcpapp
 port 0/0/0
!
hostname myrouter
ip domain name cisco.com
ip name server 10.10.10.30
!
ip tftp source-interface gig0/0/0
!

Documentación completa de MGCP: Guía de configuración de interoperabilidad y Cisco Unified Communications Manager, Cisco IOS Release 15M&T

Ejemplo de configuración SCCP/STP [con configuración automática de CUCM*]

!
stcapp ccm-group 1
stcapp
!
sccp local gig0/0/0
sccp ccm 10.10.10.10 id 1 priority 1 version 7.0+
sccp ccm 10.10.10.20 id 1 priority 2 version 7.0+
sccp
!
sccp ccm group 1
 bind interface gig0/0/0
 associate ccm 1 priority 1
 associate ccm 2 priority 2
!
ccm-manager config server 10.10.10.10
ccm-manager sccp local gig0/0/0
ccm-manager sccp
!
voice-port 0/0/0
 description The SCCP port to register
 no shut
!
dial-peer voice 1 pots
 description Defining the Port for the SCCP application
 service stcapp
 port 0/0/0
!
ip tftp source-interface gig0/0/0
!

Si un administrador no desea que CUCM configure la puerta de enlace, simplemente quite los comandos ccm-manager. La configuración de dial-peer se incluye para llevar a casa el punto sobre cómo funciona el concepto. Con las configuraciones del administrador de CCM presentes, CUCM crea estos pares de marcado basados en la configuración del puerto en CUCM, por lo que no hay necesidad de definir realmente el par de marcado. Los dial-peers creados por CUCM generalmente comienzan con 999 y luego tienen tres dígitos más.

SIP DSAPP con pares de marcado

SIP DSAPP se añadió en Cisco IOS XE 16.12.1+ y CUCM 12.5.1SU+

Con esta función, CUCM puede registrar y gestionar puertos de voz analógicos como FXS. El ruteo de llamadas con DSAPP es ligeramente diferente de MGCP o SCCP ya que los pares de marcado aún coinciden normalmente. Es decir, el gateway puede recopilar dígitos del puerto FXS y realizar una búsqueda de par de marcado en los pares de marcado VOIP. Después de encontrar una coincidencia, se envía INVITE a CUCM enblock para que CUCM realice un análisis de dígitos adicional.

Configuración SIP DSAP de muestra [con configuración automática de CUCM*] | IOS-XE 16.12.1+ y CUCM 12.5.1SU+

!
dsapp line
!
voice service voip
 sip
  bind control source-interface GigabitEthernet0/0/0
  bind media source-interface GigabitEthernet0/0/0
  session transport tcp
!
application
 service dsapp
  param dialpeer 777
!
global
 service default dsapp
!
ccm-manager config server 10.10.10.10
ccm-manager sipana auto-config local GigabitEthernet0/0/0
!
dial-peer voice 777 voip
 destination-pattern 9T
 session protocol sipv2
 session target ipv4:10.10.10.10
 session transport tcp
 incoming called-number .
 voice-class sip extension gw-ana
 voice-class sip bind control source-interface GigabitEthernet0/0/0
 dtmf-relay rtp-nte
 codec g711ulaw
!
dial-peer voice 19990100 pots
 service dsapp
 destination-pattern 7776
 voice-class sip extension gw-ana
 port 0/1/0
!
sip-ua
 registrar ipv4:10.10.10.10 expires 3600 tcp
!

Documentación completa de SIP DSAPP: Guía de configuración del software de gateway de voz Cisco VG450

Troubleshooting y Verificación del Ruteo de Llamadas

Consulte este documento para obtener información más detallada.

Configuración de la recopilación de depuración para gateways de Unified Border Element (CUBE) y Time-Division Multiplexing (TDM)