El conjunto de documentos para este producto aspira al uso de un lenguaje no discriminatorio. A los fines de esta documentación, "no discriminatorio" se refiere al lenguaje que no implica discriminación por motivos de edad, discapacidad, género, identidad de raza, identidad étnica, orientación sexual, nivel socioeconómico e interseccionalidad. Puede haber excepciones en la documentación debido al lenguaje que se encuentra ya en las interfaces de usuario del software del producto, el lenguaje utilizado en función de la documentación de la RFP o el lenguaje utilizado por un producto de terceros al que se hace referencia. Obtenga más información sobre cómo Cisco utiliza el lenguaje inclusivo.
Cisco ha traducido este documento combinando la traducción automática y los recursos humanos a fin de ofrecer a nuestros usuarios en todo el mundo contenido en su propio idioma. Tenga en cuenta que incluso la mejor traducción automática podría no ser tan precisa como la proporcionada por un traductor profesional. Cisco Systems, Inc. no asume ninguna responsabilidad por la precisión de estas traducciones y recomienda remitirse siempre al documento original escrito en inglés (insertar vínculo URL).
El propósito de este documento es explicar el ruteo de llamadas IOS y IOS-XE y los mecanismos detrás de la coincidencia de pares de marcado entrantes y salientes con los tramos de llamada de red de Servicio telefónico sencillo antiguo (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 de enlace de señales y medios rápida y, por último, un poco de resolución de problemas.
Este documento utiliza ejemplos de configuración, así como los resultados de los comandos debug y show como puntos de referencia. Las muchas funciones de este documento están claramente marcadas con la versión que la función se introdujo tanto en IOS como en IOS-XE. También se puede hacer referencia rápidamente a esta información consultando la sección Mapa de Ruta de Comandos y Funciones. Si hay un defecto notable, se vincula dentro del texto para que los lectores lo sepan.
Colaborado por Kyzer Davis y editado por Ramiro Amaya, Ingenieros del TAC de Cisco
Aunque no hay requisitos previos formales necesarios para leer este documento, se escribe con la expectativa de que el lector ya tenga algún conocimiento práctico de los protocolos de señalización de voz subyacentes que se utilizan para establecer y conectar llamadas telefónicas. A estos protocolos se hace referencia muchas veces a lo largo del libro.
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 códecs de vídeo.
Tecnologías analógicas: Oído y Boca (E&M), Suscriptor de Intercambio Extranjero (FXS) y Oficina de Intercambio Extranjero (FXO).
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.
Atributo | Descripción |
---|---|
Cadena de dígitos | También se conoce como cadena de números, número de teléfono, número o número E164. Consta de dígitos completos de 0 a 9 con un símbolo opcional de suma (+).
|
Servicio de identificación de número marcado (DNIS) | Se trata del número llamado o del número de destino de una llamada. |
Identificación automática de números (ANI) | Se trata del número que llama o del número que llama originario de una llamada.También se puede llamar Identificador de línea de llamada (CLID), que también se puede denominar ID de la persona que llama. |
Identificador uniforme de recursos (URI) | Un URI es un sip: o tel: cadena utilizada más comúnmente con los protocolos VoIP SIP y H323.
|
ID de operador | Ejemplos de CID: Nota: CSCua14749 |
Cadena de ruta | Encabezado propietario de Cisco para cadenas de ruta ILS que se utilizan con SIP.
|
ENUM | ENUM es un protocolo que utiliza el servicio de nombres de dominio (DNS) para traducir números de teléfono E164 a URI. Esto no se trata en este documento. |
PSTN | Red telefónica pública conmutada |
ITSP | Proveedor de servicios de telefonía por Internet |
SBC | Controlador de límite de sesión. Este es el dispositivo que se mantiene como punto de demarcación entre una LAN del cliente y una red ITSP/PSTN |
Función | Versión del IOS | Versión IOS-XE |
Expansión del número (num-exp) Marcado entre pares (POTS y VOIP) answer-address destination-pattern incoming called-number destino de sesión (IPv4 y DNS) Max Connections (max-conn) direct-inward-dial dígitos de reenvío (POTS) prefijo (POTS) timeouts inter-digit (voice-port) |
11.3(1)T | Todos |
dial-peer terminator |
12.0 | Todos |
huntstop |
12.0(5)T | Todos |
Mapas ISDN | 12.0(6)T | Todos |
Esquemas de búsqueda de par de marcado |
12.0(7)XK | Todos |
Regla y perfil de traducción de voz translate-output tipo de numeración banda de dígitos (POTS) |
12.0.(7)XR1 | Todos |
session target (sip-server) | 12.1(1)T | Todos |
Grupo troncal POTS | ‘12.1(3)T’ | Todos |
DNIS-Map (Saliente) | 12.2(2)XB |
Todos |
trunk-group-label | ‘12.2(11)T’ |
Todos |
Dial-peer (Datos) | 12.2(13)T |
Todos |
URI de clase de voz (saliente) | ‘12.3(4)T’ |
Todos |
objetivo de sesión (IPv6) | 12.4(22)T |
Todos |
Perfiles SIP (salientes) | 15.0(1)M |
Todos |
URI de clase de voz (entrante) voice source-group |
15.1(2)T |
3,8 S |
Lista de copias SIP objetivo de la sesión (Secretario) |
15.1(3)T |
3,6 S |
call-route (url) |
15.2(1)T |
3,3 S |
max-bandwidth |
15.2(2)T |
3,7 S |
E164-Pattern-Maps (saliente) | 15.2(4)M | 3,7 S |
Cadena de ruta de clase de voz call-route (dest-route-string) |
15.3(3)M | 3,10 S |
Grupos de pares de marcado (VOIP) E164-Pattern-Maps (entrante) Grupo de servidores de destino paso a petición session target (sip-uri) |
15.4(1)T |
3,11S |
Política de aprovisionamiento de par de marcado Perfiles SIP (entrante) |
15.4(2)T | 3,12 S |
Grupo de par de marcado (POTS) | 15.5(1)T | 3,14S |
Arrendatarios de clase de voz | 15.6(2)T | 16.3.1 |
Filtrado VRF para pares de marcado | 15.6(3)M | 16.3.1 |
e164-translation | n/a | 16.8.1 |
SIP DSAPP | n/a | 16.12.1 |
Huntstop para grupos de servidores | n/a | 17.4.1 |
puerto de escucha SIP para arrendatario Filtrado de arrendatarios para pares de marcado |
n/a | 17.8.1 |
Los gateways Cisco IOS e IOS-XE utilizan un concepto de dial-peer 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 se limita a equipos 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 enumerar.
Situación: Una llamada que llega a una gateway de Cisco desde otro agente de llamada 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 llamada. Este es el tramo de llamada saliente (tramo externo).
Imagen 1 muestra una llamada de PSTN a CUCM ruteando a través de una gateway de voz de Cisco y la información correspondiente del tramo de llamada entrante y saliente.
Imagen 1: Ilustración de tramos de llamadas entrantes y salientes
Una llamada exitosa a través de una puerta de enlace de Cisco SIEMPRE* coincide con un par de marcado entrante o saliente para rutear correctamente. Los pares de marcado entrantes y salientes son similares a los tramos de llamada mencionados anteriormente. En la Imagen 1, la llamada que llega de la PSTN en la puerta de enlace de Cisco debe coincidir con un par de marcado entrante. A continuación, el gateway utiliza un dial-peer saliente para rutear 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 puede controlar muchos aspectos de cada tramo de llamada específico. Algunos ejemplos de estos son los códecs de voz, las preferencias de DTMF, la manipulación de dígitos, dónde se va a enrutar la llamada y muchas otras configuraciones. Los pares de marcado se pueden configurar con las sentencias de coincidencia entrantes y salientes, de modo que es posible que coincidan con el mismo par de marcado tanto para el tramo entrante como para el tramo saliente si se aplica una configuración válida de coincidencia entrante y saliente a ese par de marcado específico.
La imagen 2 ilustra los mismos tramos de llamadas entrantes y salientes que la imagen 1, pero con los pares de marcado respectivos para una llamada de PSTN a CUCM ruteando a través de una gateway de voz de Cisco.
Imagen 2: pares de marcado entrantes y salientes ilustrados
Los gateways de voz de Cisco pueden interactuar muchos tipos diferentes de llamadas de voz y protocolos, incluidos IP a IP, POTS a POTS e IP a POTS o viceversa.
Imagen 3 muestra una llamada de VoIP a VoIP a través de Cisco Unified Border Element (CUBE).
Imagen 3: pares de marcado entrantes y salientes para una llamada Voip a VoIP
La imagen 4 muestra una llamada de POTS a POTS a través de una puerta de enlace de Cisco.
Imagen 4: pares de marcado entrantes y salientes para una llamada POTS a POTS
POTS | Los pares de marcado del servicio de telefonía convencional se corresponden con conexiones analógicas como FXS analógicas, FXO, ISDN T1/E1s, E1 R2 y conexiones Ear y Mouth (E&M). Éstos envían o reciben una llamada a / desde un puerto de voz físico en el gateway. |
VOIP | Los pares de marcado de Voz sobre IP se utilizan principalmente para controlar las conexiones H323 y SIP hacia y desde el gateway. Estos pares de marcado envían y reciben señalización desde direcciones IPv4 e IPv6, así como nombres de dominio completamente calificados (FQDN) mediante el sistema de nombres de dominio (DNS). — Los pares de marcado VoIP también se pueden utilizar para la señalización Voice over Frame Relay (VoFR), Voice over ATM (VoATM), Voice over High-Level Data Link Control (VoHDLC) y Registration, Admission, and Status (RAS) y los destinos de sesión para estos pares de marcado también pueden incluir los valores de asentamientos y ENUM. Nota: Algunos de estos tipos de configuraciones son tecnologías antiguas que no se ven en redes más recientes y con IOS-XE algunos ya no son compatibles. Como resultado, no se tratan en este documento. |
MMOIP | Los pares de marcado Multimedia Mail Over IP se utilizan para enviar correos electrónicos a servidores de intercambio. Estos se utilizan principalmente para el envío de faxes en rampa/fuera de rampa t37. Estos tipos de par de marcado no están dentro del alcance de este documento. |
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 asegúrese de que la gateway tenga al menos el 20% de la memoria total reservada para otros procesos de CPU. Un gran número de pares de marcado configurados puede agregar al retraso para rutear una llamada. Esto puede ser significativo ya que la aplicación de voz de Cisco busca a través de pares de marcado desde arriba hacia abajo, de forma similar a una lista de control de acceso (ACL). Esto no suele ser un problema en los 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
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 se selecciona. El orden de los elementos del mensaje verificado depende en gran medida del protocolo para la llamada según lo indicado por las listas de preferencias definidas en la Tabla 1, la Tabla 2 y la Tabla 3. Un par de marcado sólo necesita cumplir 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. Se busca a todos los pares de marcado en función de los primeros criterios de coincidencia. El gateway pasa a los siguientes criterios sólo si no se encuentra ninguna coincidencia.
Tabla 1. Preferencia de selección de par de marcado SIP entrante
Preferencia | Criterios de coincidencia |
Comandos de par de marcado |
1 | URI |
uri entrante mediante <uri-tag> |
2 | URI |
incoming uri request <uri-tag> |
3 | URI | uri entrante a <uri-tag> |
4 | URI | uri entrante de <uri-tag> |
5 | Número llamado |
incoming called-number <number-string> incoming called e164-pattern-map <pattern-map-number> |
6 | Número que llama | incoming calling e164-pattern-map <pattern-map-number> answer-address <number-string> |
7 | Destination-pattern (ANI) | destination-pattern <number-string> |
8 | Carrier-ID | carrier-id source <string> |
Nota: Los pares de marcado entrantes elegibles pueden ser filtrados por VRF o Arrendatario si se configura la función correspondiente. Para obtener más información, vea las secciones Ruteo y Reenvío Virtual (VRF) y Búsqueda de par de marcado y Arrendatarios de clase de voz.
Tabla 2. Preferencia de selección de par de marcado H323 entrante
Preferencia | Criterios de coincidencia | Comandos de par de marcado |
1 | URI | uri entrante llamado <uri-tag> uri entrante que llama <uri-tag> |
2 | Número llamado | incoming called-number <number-string> incoming called e164-pattern-map <pattern-map-number> |
3 | Número que llama | incoming calling e164-pattern-map <pattern-map-number> answer-address <number-string> |
4 | Destination-pattern (ANI) |
destination-pattern <number-string> |
5 | Carrier-ID |
carrier-id source <string> |
Tabla 3. Preferencia de selección de par de marcado POTS de entrada
Preferencia | Criterios de coincidencia | Comandos de par de marcado |
1 | Número llamado | incoming called-number <number-string> |
2 | Número que llama | answer-address <number-string> |
3 | Destination-pattern (ANI) | destination-pattern <number-string> |
4 | Puerto de voz | port <voice-port-number> |
Cuando No Existen Coincidencias / Dial-Peer predeterminado 0 peer_tag=0, pid:0
Cuando no hay coincidencias elegibles para un dial-peer entrante para llamadas POTS o VoIP, el gateway asigna el dial-peer 0. Esto no es ideal, ya que el dial-peer 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. Consulte la sección MGCP y SCCP para obtener más detalles.
dial-peer 0 capabilities
Los pares de marcado salientes se utilizan para enrutar llamadas POTS o VoIP desde el gateway al siguiente agente de llamadas. Al igual que la coincidencia de dial-peer entrante, hay una lista de elementos que el gateway puede utilizar para hacer coincidir los dial-peers en función del orden de preferencia para el protocolo específico. Sin embargo, a diferencia de los pares de marcado entrantes, si no hay un par de marcado saliente que cumpla los requisitos para rutear la llamada, la llamada entonces falla. Al igual que la coincidencia de pares de marcado entrante, se busca a todos los pares de marcado en función de los primeros criterios de coincidencia. El gateway pasa a los siguientes criterios sólo si no se encuentra ninguna coincidencia.
Tabla 4. Preferencia de selección de par de marcado SIP saliente
Preferencia | Criterios de coincidencia | Comandos de par de marcado* |
1 | Dial-Peer Group Dial-Peer | destination dpg <dpg-tag> (DPG configurado en dial-peer entrante) |
2 | URI de política de aprovisionamiento de par de marcado | destination uri-from <uri-tag> (DPP configurado en dial-peer entrante) |
3 | Cadena de ruta ILS | destination route-string <route-string-tag> |
4 | URI y Carrier-ID | destination uri <uri-tag> AND carrier-id target <string> |
5 | Número al que se ha llamado y ID de operador | destination-pattern <number-string> AND carrier-id target <string> |
6 | URI | destination uri <uri-tag> |
7 | Número llamado | destination-pattern <DNIS-number> destination e164-pattern-map <pattern-map-number> dnis-map <dnis-map-number> |
8 | Número que llama | destino que llama a e164-pattern-map <pattern-map-number> |
Tabla 5. Preferencia de selección de par de marcado H323 saliente
Preferencia | Criterios de coincidencia | Comandos de par de marcado* |
1 | Dial-Peer Group Dial-Peer | destination dpg <dpg-tag> (configurado en dial-peer entrante) |
2 | URI y Carrier-ID | destination uri <uri-tag> AND carrier-id target <string> |
3 | Número al que se ha llamado y ID de operador | destination-pattern <number-string> AND carrier-id target <string> |
4 | URI | destination uri <uri-tag> |
5 | Número llamado | destination-pattern <number-string> destination e164-pattern-map <pattern-map-number> dnis-map <dnis-map-number> |
6 | Número que llama | destino que llama a e164-pattern-map <pattern-map-number> |
Tabla 6. Preferencia de selección de par de marcado POTS saliente
Preferencia | Criterios de coincidencia | Comandos de par de marcado* |
1 | Dial-Peer Group Dial-Peer | destination dpg <dpg-tag> (configurado en dial-peer entrante) |
2 | URI y Carrier-ID | destination uri <uri-tag> AND carrier-id target <string> |
3 | Número al que se ha llamado y ID de operador | destination-pattern <number-string> AND carrier-id target <string> |
4 | URI | destination uri <uri-tag> |
5 | Número llamado | destination-pattern <DNIS-number> dnis-map <map-number> |
Nota: * La sección Búsqueda de par de marcado de cadena de número y Búsqueda de par de marcado URI explica cómo la gateway evalúa una lista de comandos potenciales para cada fila de criterios de coincidencia antes de pasar a los siguientes criterios de coincidencia. es decir, Evaluar todas las coincidencias potenciales destination-pattern y los comandos de coincidencia e164-pattern-map de destino antes de examinar los comandos del número que llama.
Preferencia de cadena de número:
Al igual que los URI tienen un orden de operaciones específico para evaluar coincidencias, también hay un conjunto de reglas que se utilizan para evaluar una cadena numérica de dígitos. El esquema de búsqueda de par de marcado predeterminado para una gateway de Cisco se establece en 0. Esto significa que la puerta de enlace 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, el gateway observa la preferencia de par de marcado definida explícitamente. Por último, si ambos son iguales, elige uno en orden aleatorio.
Hay otros esquemas de búsqueda de par de marcado disponibles para la configuración; sin embargo, la mayoría de las implementaciones mantienen el valor predeterminado de 0.
Sugerencia: si los dial-peers coinciden fuera del orden predeterminado, un administrador debe examinar la configuración en ejecución para un esquema de búsqueda de dial-peer 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: Los pares de marcado que cumplen los requisitos se han configurado con las siguientes coincidencias posibles y el gateway está evaluando una cadena de dígitos de 2001. El par de marcado 1 puede coincidir con cualquier número de 2000 a 2999, mientras que el par de marcado 2 puede coincidir de 2000 a 2009. El par de marcado 2 se igualaría para esta llamada ya que es la coincidencia más larga (la más específica) para la cadena de dígitos 2001 cuando se utilizan los mecanismos de búsqueda de par de marcado predeterminados (dial-peer hunt 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 en la cadena de números 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 siempre utilice un dial-peer específico antes que otros. De forma predeterminada, todos los pares de marcado son 0. Un dial-peer con preferencia 0 se compara antes de otro dial-peer con preferencia de 1 a 10. La mayoría de los administradores configuran varios pares de marcado para enviar una llamada a un suscriptor CUCM específico con un suscriptor de respaldo u otro agente de llamada configurado usando otro par de marcado con menor preferencia (que se configura con un número mayor).
Situación: 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 dial-peer 1 con una preferencia más alta para que se elija dial-peer como el primer dial-peer utilizado en el ruteo de la llamada. El par de marcado 2 permanecería como opción secundaria si se produjera 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
!
Una gateway de Cisco sólo intenta rutear una llamada a través de un par de marcado saliente que cumple los requisitos a la vez. Si se observa una condición de falla en el primer dial-peer seleccionado, el gateway entonces intenta rutear la llamada al siguiente dial-peer elegible. Esto continúa hasta que la llamada se realiza correctamente o falla porque no quedan más pares de marcado aptos para intentarlo. Un síntoma común de búsqueda y fallo de dial-peer es un retraso notable en la recepción de llamada mientras se realizan las llamadas. Normalmente, las depuraciones son necesarias para verificar exactamente por qué falla la llamada en un par de marcado determinado. El comando huntstop se puede emplear en un dial-peer si un administrador no desea que un gateway busque otro dial-peer cuando se observa una condición de falla.
Situación: 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 dial-peer 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 usando dial-peer 1, entonces el gateway detiene inmediatamente la búsqueda de dial-peer ya que el comando huntstop está configurado. En este escenario, el dial-peer 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: También se pueden utilizar los comandos huntstop y preference junto con las sentencias coincidentes de URI, ya que son comandos de configuración de dial-peer generales. Además, las configuraciones de clase de servidor-grupo de voz pueden utilizar los comandos huntstop en 17.4.1a. Consulte la sección Grupos de servidores de destino para obtener más información sobre esto.
El gateway examina cada criterio de coincidencia y lo agota antes de pasar a los siguientes criterios de coincidencia. Un ejemplo de esto sería en una llamada SIP entrante. Basado en el cuadro 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, la puerta de enlace pasa al siguiente elemento coincidente y realiza una evaluación según esos criterios. Este proceso se repite hasta que la llamada se rutea en función de una coincidencia o el gateway se queda sin los criterios de coincidencia para verificar.
Cuando se configura un dial-peer entrante o saliente con un comando URI, el gateway examina el URI que se recibió en varios encabezados para una coincidencia potencial. La preferencia de coincidencia se basa en la coincidencia más específica y la preferencia exacta es la coincidencia URI completa, la porción de host, la porción de usuario o la URI de teléfono. Conocer el orden de las operaciones para la coincidencia de URI puede ayudar en gran medida en la coincidencia de pares de marcado con implementaciones de SIP y CUBE.
Este orden de preferencia se puede manipular usando el comando voice class uri sip preference para especificar el id de usuario como la primera opción en lugar del host.
Preferencia de URI:
Documento de apoyo: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-inbnd-dp-match-uri.pdf
Situación: Un administrador ha configurado los pares de marcado siguientes y envía una llamada al gateway. El encabezado FROM de la INVITE recibida es "De: <sip:testuser@10.10.10.10>" El gateway puede potencialmente coincidir con dos pares de marcado diferentes según 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 por encima de una coincidencia de usuario, el dial-peer 2 se utiliza para el dial-peer 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 !
La coincidencia de URI para los 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 los protocolos VoIP que admiten URI en sus mensajes. Antes de IOS 15.4(1)T y IOS-XE 3.11S, un URI de solicitud tenía que contener un "user@host" alfanumérico si no un gateway de Cisco rechazaría la llamada con un mensaje 4xx. Ahora, un URI puede contener sólo la parte del host y el gateway enruta la llamada basándose únicamente en el host proporcionado. es decir, sip:cisco.com.
Además, antes de IOS 15.4(1)T y IOS-XE 3.11S voice-class URI user-ids sólo podían ser valores e.164 numéricos (sip:1234@host.com). Esto se modificó para que los administradores puedan configurar ID de usuario alfanuméricos en CUBE (sip:user@host.com)
La parte de host o usuario de un uri de clase de voz puede contener patrones de expresiones regulares (regex) que amplían en gran medida los valores posibles que se pueden comparar.
Gateway(config-voice-uri-class)# user-id .) % unmatched ()user-id pattern should be of format ^([][0-9A-Za-z\|\/()*+^$&?#--.])*$
Gateway(config-voice-uri-class)# host .)
% unmatched ()host pattern should be of format ^([][0-9A-Za-z\|@\/()*+^$&?#--.])*$
Gateway(config-voice-uri-class)# pattern .)
% unmatched ()pattern pattern should be of format ^([][0-9A-Za-z\|@;:=%!~\/()*+^$&?#--.])*$
URI de clase de voz de ejemplo
! voice class uri HOST sip host webex.com host dns:cisco.webex.com host ipv4:14.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(.*) !
Sólo se pueden configurar 10 hosts, 1 patrón o 1 ID de usuario por uri de clase de voz, como se muestra en el siguiente ejemplo. Si hay que buscar más elementos coincidentes, se recomienda utilizar Regex.
Gateway(config)# voice class uri TEST sip Gateway(config-voice-uri-class)#host ipv4:1.1.1.1 Gateway(config-voice-uri-class)#host ipv4:2.2.2.2 Gateway(config-voice-uri-class)#host ipv4:3.3.3.3 Gateway(config-voice-uri-class)#host ipv4:4.4.4.4 Gateway(config-voice-uri-class)#host ipv4:5.5.5.5 Gateway(config-voice-uri-class)#host ipv4:6.6.6.6 Gateway(config-voice-uri-class)#host ipv4:7.7.7.7 Gateway(config-voice-uri-class)#host ipv4:8.8.8.8 Gateway(config-voice-uri-class)#host ipv4:9.9.9.9 Gateway(config-voice-uri-class)#host ipv4:10.10.10.10 Gateway(config-voice-uri-class)#host ipv4:11.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
Esta función se agregó en IOS 15.1(2)T y IOS-XE 3.8S y utiliza un voice class uri configurado y aplicado a un par de marcado entrante. La URI entrante ha sido adoptada por muchos clientes con respecto a la incoming called-number para las 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 procedentes de un agente de llamadas o usuario determinado.
Documentación completa: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-inbnd-dp-match-uri.html
Casos prácticos comunes
Ejemplo de configuración
El siguiente ejemplo de salida coincide con dial-peer 777 para cualquier solicitud SIP proveniente de las dos IP HOST definidas en el uri de clase de voz. El encabezado que se está viendo se define como el encabezado FROM en el dial-peer; 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 dial-peer 777 y origina mi respuesta 200 OK a las OPTIONS desde la interfaz especificada. Si mi CUCM envía una INVITE al CUBE coincide con el dial-peer 777 como dial-peer entrante.
! voice class uri CUCM sip
host ipv4:14.50.244.2
host ipv4:14.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 !
Las gateways de Cisco IOS pueden coincidir con un dial-peer saliente usando un URI aplicando un voice class uri a un dial-peer saliente y agregando url de ruta de llamada a la configuración global. Cuando esté presente, el CUBE intentará enrutar las llamadas basándose en el URI de solicitud. Esta función se agregó en IOS 12.3(4)T y está presente en todas las versiones IOS-XE. Debe tenerse en cuenta que, de forma predeterminada, el URI de solicitud de SIP saliente y el URI de encabezado To van a tener el destino de sesión del par de marcado saliente. Esto se puede inhabilitar mediante el comando paso a petición que permite que el gateway pase la parte del host URI del tramo interno al tramo externo en lugar de reemplazar la parte del host URI con el destino de sesión. El comando paso a petición 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 !
Además de voice class uri, los administradores pueden utilizar dial-peer provision-policy (DPP) para que coincida con un URI de segmento para una coincidencia de par de marcado saliente. Esta función se agregó en IOS 15.4(2)T y IOS-XE 3.12S. R dial-peer provision-policy requiere definir un atributo de coincidencia principal con un atributo de coincidencia secundario como opcional. La política de provisión se aplica a un par de marcado entrante y cuando ese par de marcado se selecciona para su uso en un tramo de llamada entrante, se invoca la política. El resultado es una selección de dial-peer saliente basada en el atributo de la política de provisión de dial-peer.
La coincidencia saliente puede ser un solo encabezado o varios encabezados que todos deben ser verdaderos para que coincida con el dial-peer.
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 respaldo. El par de marcado 1234 se ha creado para aplicar la política de provisión para la coincidencia entrante. Luego, el dial-peer 11111 y 22222 incorporado que aplican los comandos uri-from de destino y uri-to de destino respectivamente. Estos comandos vuelven a llamar a su URI de clase de voz. Para la llamada, recibiremos la INVITE, coincidamos con el dial-peer 1234 y comprobaremos la provisión-política. Luego, el dispositivo intentará rutear primero en el encabezado From que como coincidencia aplicable en el dial-peer 11111. Si esto falla, también podemos intentar rutear en el encabezado a con 2222.
En el ejemplo también se detalla cómo alcanzar una coincidencia AND con políticas de provisión de par de marcado. Suponiendo que se reciba la misma INVITE, podemos definir dos encabezados bajo una preferencia y aplicarlo al dial-peer entrante.
Ahora, cuando se recibe la invitación, comprobará si hay pares de marcado salientes elegibles que cumplan los dos criterios de coincidencia definidos en la política de provisión. Por lo tanto, en este ejemplo, nuestro dial-peer saliente necesita definirse con el encabezado TO y FROM para que se coincida. Si alguno de los dos no es una coincidencia válida, no se utiliza el dial-peer 12345.
Nota: Aunque estamos enrutando la llamada en el encabezado FROM, la INVITE que sale de la puerta de enlace aún tiene 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 cambiamos el URI de solicitud.
Ejemplo de configuración:
### Recieved 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
!
session target sip-uri
Antes de IOS 15.4(1)T y IOS-XE 3.11S si la parte de host de un URI era diferente pero el usuario era el mismo, esto requeriría dos pares de marcado salientes independientes.
Después de esta versión, un administrador puede configurar un par de marcado para prestar servicio a varios hosts para el mismo usuario. es decir, testuser@cisco.com y testuser@webex.com en el mismo dial-peer. El uso de session target sip-uri activa la resolución DNS del dominio de INVITE Req-URI entrante y determina dinámicamente la IP de destino de la sesión.
Ejemplo de configuración:
El gateway recibe dos SIP INVITE con los siguientes 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 la definición user-id coinciden con "testuser". El comando voice-class sip call-route url está presente significa que evaluamos los pares de marcado salientes en base al URI de solicitud de este INVITE entrante. Weans que coincidimos con dial-peer 2 por las mismas razones por las que coincidimos con dial-peer 1, el user-id de "testuser". El destino de sesión de este dial-peer es el sip-uri original tal como se define en "session target sip-uri" que era un FQDN. Después de que se haya realizado una resolución de DNS y cambiamos cisco.com y webex.com a una IP para el ruteo de capa 3, enviamos un mensaje desde el 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
Un administrador puede utilizar comodines de par de marcado al definir mecanismos de coincidencia de entrada y de salida 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 sobre la coincidencia de pares de marcado.
Tabla comodín
Carácter | Definición | Examples |
* | En un par de marcado, este es un valor literal de * (asterisco) en el teclado. | 12345* |
N.º | En un par de marcado, este es un valor literal de # (almohadilla) en el teclado. | 8675309# |
, | Inserta una pausa de 1 segundo entre dígitos. También se puede utilizar una coma entre paréntesis [ ] para dividir un rango continuo. |
9,,,,,555 91[1-3,5-9]8675309 |
. | Carácter Regex para hacer coincidir cualquier valor 0-9, A-F y *, #, + Se pueden definir hasta 15 caracteres de punto por par de marcado, aunque la CLI permite que un administrador configure tantos como estime oportuno. Si se requieren más de 15 puntos, utilice T. |
2.... 91[2-9]...[2-9]...... |
% | Regex para el dígito anterior que ocurre cero o más veces. | |
+ | Cuando se utiliza al principio de una cadena significa un literal + utilizado en números E164. Cuando se utiliza en cualquier otro lugar de la cadena, se trata de un valor regex para el dígito anterior que se produce una o más veces. |
+19191112222 |
? | Regex para el dígito anterior que ocurre cero o una vez. | (206)?5015111 (0)?(1)?(1)?21933... |
^ | El carácter Regex indica el comienzo de la cadena cuando se utiliza fuera de corchetes Cuando se utiliza entre corchetes, se trata como una declaración de exclusión o de NO COINCIDIR Esto ya no es necesario en versiones posteriores, ya que la puerta de enlace asume automáticamente un ^ al procesar una cadena de registro sin un ^. |
^8675309 91[^135]555 |
$ | Regex para indicar el final de una cadena. | 8675309 $ |
\ | Carácter de escape para significar un valor literal |
|
[ ] | Los paréntesis definen un intervalo de caracteres para una única posición. Las comas se deben utilizar para romper cadenas continuas. |
[1-5]0000 [2,5-8]0000 |
( ) | Los paréntesis definen un grupo de caracteres en un conjunto. |
9(258) 7777 |
T | Coincidencia de longitud variable de hasta 32 dígitos. El router espera que se produzca el tiempo de espera entre dígitos antes de rutear la llamada. El valor predeterminado para el tiempo de espera entre dígitos es de 10 segundos y se puede modificar a través de tiempos de espera entre dígitos en un puerto de voz. T también hace referencia al temporizador T302 |
9011T |
- | Se utiliza entre paréntesis para definir el intervalo. |
[5-9]1234 |
Salida de la puerta de enlace que muestra las posibles entradas de expresión regular
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?(\$)?$
Los pares de marcado pueden estar en uno de los dos estados operativos.
Para que un par de marcado se encuentre en un estado operativo válido y cumpla los requisitos para ser utilizado con el enrutamiento de llamadas, debe estar en estado UP. Para los pares de marcado VOIP salientes esto significa que debe haber un mecanismo de coincidencia saliente válido así como un destino de sesión válido para rutear la llamada hacia. Para los pares de marcado POTS salientes se deben configurar mecanismos de coincidencia saliente válidos así como un puerto de voz válido. Con los pares de marcado entrantes sólo se debe configurar un mecanismo de coincidencia entrante válido.
El estado busyout se observa cuando se configura un par de marcado con mecanismos keepalive y el destino remoto ha fallado los parámetros de ese mecanismo keepalive. A continuación, el gateway traslada el par de marcado a un estado busyout, de modo que ya no se utiliza para las decisiones de ruteo de llamadas y cuando se completa de nuevo el mecanismo keepalive, el gateway vuelve a poner el par de marcado en un estado activo. Si se selecciona un par de marcado como par de marcado saliente y este par de marcado se encuentra en estado busyout, el gateway falla la llamada con un código de causa 188.
Junto con los estados operativos hay estados administrativos.
Un administrador puede inhabilitar un dial-peer sin quitarlo de la configuración ingresando el comando shutdown en el dial-peer. Para volver a habilitar el dial-per, introduzca no shutdown.
Nota: Un dial-peer con un puerto de voz inactivo, apagado o no operativo permanece en estado operativo de UP 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:14.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
A partir de IOS 15.6(3)M y IOS-XE 16.3.1, las gateways de Cisco pueden coincidir con los pares de marcado entrantes usando ID de VRF. Para aprovechar esta ventaja, un administrador debe enlazar el dial-peer entrante a una interfaz que, a su vez, enlaza el dial-peer al VRF ID en la interfaz especificada. Una vez que el enlace se ha completado, las llamadas entrantes son filtradas por el gateway de Cisco para incluir solamente 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 dial-peer entrante se compara en función del orden de operaciones de coincidencia de dial-peer normal.
Antes de estas versiones IOS / IOS-XE, la gateway de Cisco realizaría una selección entrante basada en la coincidencia regular de dial-peer entrante sin ningún filtrado. Esto significa que una llamada VRF1 puede ser coincidida por un dial-peer VRF2. Además, dado que solo un VRF era soportado por H323 y SIP antes de estas versiones, surgen otros problemas al intentar utilizar las funciones de VRF múltiple. El uso de un único VRF para las aplicaciones de voz se conocía como configuración que reconoce VRF.
Documentación completa con identificación de VRF: http://www.cisco.com/c/en/us/td/docs/ios/12_4t/12_4t15/vrfawvgw.html
Documentación completa de Multi-VRF: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-multi-vrf.html
Cisco Gateways tiene la capacidad de enlazar 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 dial-peer para VRF2 si se satisface la selección normal de coincidencia de dial-peer saliente. Los grupos de pares de marcado se pueden emplear para obligar al gateway de Cisco a mantener la llamada dentro del mismo VRF.
Ejemplo de Configuración de Grupo de Peers de Marcado y VRF
Este ejemplo de configuración tiene VRF1 y VRF2 con dos rangos IP superpuestos y dos rangos de números de teléfono superpuestos.
Utilizamos el enlace VRF para asegurarse de que coincide el dial-peer entrante correcto y de que los grupos de par de marcado se aseguran de que coincide el dial-peer saliente de VRF correcto.\ 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 basándose en el ID VRF2. Esto significa que no podemos hacer coincidir el dial-peer 10. Ahora que comprobamos la cadena de dígitos coincidimos con dial-peer 20. Dial-peer 20 tiene un grupo de dial-peer que le dice a la gateway que el único dial-peer saliente que se puede igualar también es dial-peer 20. Este grupo de dial-peer nos permite evitar la coincidencia de dial-peer 10 y el cruce de una llamada que viene de VRF1 a VRF2. A partir de ahí, la llamada debe continuar como siempre.
! 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 -------------------------------------
A lo largo de los años, a medida que crecen las necesidades empresariales, la empresa se expande y necesita más DID para los administradores empresariales, lo que puede hacer que los pares de marcado básicos no se adapten bien a la escala. Es posible que haya situaciones en las que hay que hacer frente, o tal vez haya demasiados pares de marcado en general. Tener miles de dial-peers no facilita la administración y la resolución de problemas. Tener un par de marcado para cada servidor CUCM específico o agente de llamada 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. Quizás haya más de un proveedor SIP conectado a una puerta de enlace o varios clientes diferentes que utilizan el mismo CUBE. Esto dificulta mucho el aislamiento de un arrendatario específico.
Cisco ha tomado esta información y ha creado un conjunto de elementos que pueden abordar estos problemas, entre otros. Los grupos de pares de marcado, los arrendatarios de clase de voz, los grupos de servidores de destino, e164-pattern-maps y los grupos troncales de POTS permiten que un administrador resuelva todos los problemas anteriores y muchos otros que no aparecen en la lista.
Se agregaron grupos de pares de marcado en IOS 15.4(1)T y IOS-XE 3.11S y se agregaron pares de marcado POTS como opción en IOS 15.5(1)T e IOS-XE 3.14S. Un grupo de par de marcado permite a los administradores especificar un par de marcado exacto para el ruteo saliente basado en el par de marcado entrante coincidente. Una vez que coincide un dial-peer entrante con un grupo de dial-peer configurado, la llamada utiliza el dial-peer definido en el grupo dial-peer incluso si el destination-pattern no coincide. El único requisito previo es que el par de marcado saliente debe ser ACTIVO, por lo que se debe configurar un método de coincidencia saliente, pero esto no se utiliza realmente para rutear la llamada.
La mejor manera de describir los grupos de par de marcado es compararlos con el concepto de rutas estáticas en una tabla de ruteo. Estas son estáticas entrantes para las decisiones de ruteo saliente que eliminan algunas conjeturas para el gateway porque le dicen exactamente cómo rutear la llamada.
Documentación completa: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-outbound-dial-peer.html
Ejemplo de configuración
Con el siguiente ejemplo, el número llamado es 8675309. Esto coincide con el dial-peer 1234 basado en la sentencia del número llamado entrante. Este dial-peer se configura con un grupo de dial-peer que indica que la llamada debe rutear ahora los dial-peers 2, luego 3 y finalmente 1 si falla el dial-peer 2. Sabiendo esto, el gateway ahora intenta rutear el dial-peer 2 de llamada saliente, como se le ha dicho explícitamente a través del grupo dial-peer que es lo que debe hacer.
Observe cómo el patrón de destino en el par de marcado 1, 2 y 3 no es el número marcado de 8675309. Esto está bien y la llamada sigue enrutándose sin problemas. Recuerde, como se describe en la sección "estados de par de marcado", que necesitamos algo/cualquier cosa configurada como una instrucción coincidente saliente. En nuestro caso, el patrón de destino es sólo para llevar el dial-peer a un estado operativo 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. Puesto que esto 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 es posible que nunca la utilicemos para nada que no sea nuestro escenario específico que involucre a un grupo de pares de marcado, ya que la probabilidad de que una llamada llegue a AAAA es 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 -------------------------------------
Esta función permite a los administradores reducir el número total de pares de marcado combinando muchas coincidencias de números posibles (patrones de destino, número de llamada entrante, etc.) en un único mapa de patrones. Se agregó soporte de dial-peer saliente e164-pattern-map en IOS 15.2(4)M e IOS-XE 3.7S mientras se agregó soporte de dial-peer entrante e164-pattern-map en IOS 15.4(1)T e IOS-XE 3.11S.
Se puede configurar un mapa de patrones e164 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 del gateway y, a continuación, se hace referencia al mismo cuando se configura 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 mayor agregación.
Documentación completa:http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/vd-mdp-dialpeer.html
Ejemplo de Configuración de CLI: Números de Llamada
! 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 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
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
Los grupos de servidores permiten a los administradores configurar varios destinos (session-target) 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 caza de ordenamiento cíclico se puede utilizar mediante el comando hunt-esquema round-robin. Los grupos de servidores se agregaron en IOS 15.4(1)T e IOS-XE 3.11S. En IOS-XE 17.4.1un código de error huntstop configurable fue agregado a las configuraciones de grupo de clase de servidor de voz. Es decir, puede configurar un solo código de error, digamos 404 El error SIP no encontrado normalmente activaría el dispositivo para probar la siguiente opción en el grupo de servidores. Con la configuración huntstop 1 resp-code 404 en su lugar dentro del grupo de servidores; la caza se detendrá. Estos 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 5 por grupo de servidores.
Documentación completa: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/multiple-server-groups.html
Ejemplo de configuración - Normal
! voice class server-group 1 hunt-scheme round-robin ipv4 14.50.244.2 port 5060 preference 1 ipv4 14.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 14.50.244.2 5060
0 ipv4 14.50.244.62
3 ipv6 2010:AB8:0:2::1 2323
0 ipv6 2010:AB8:0:2::2 2222
[..truncated..]
Cabe señalar que los grupos de servidores no siguen los mecanismos de keepalive de opciones fuera de diálogo normales. Utilizan una función llamada option-keepalive profile. Esto permite que la gateway monitoree cada agente de llamada definido en el grupo de servidores específico.
Ejemplo de keepalive de opciones con grupo de servidores
! voice class server-group 1 hunt-scheme round-robin ipv4 14.50.244.2 ipv4 14.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:14.50.244.2 Transport: system Sip Profiles: 0 OOD SessID: 2 OOD Stat: Active Target: ipv4:14.50.244.62 Transport: system Sip Profiles: 0
Los grupos troncales son una colección de puertos de voz físicos con capacidades de señalización similares. Se trata de una función que se puede utilizar para reducir el número total de pares de marcado POTS que se deben configurar. Los grupos troncales se introdujeron en el IOS en 12.1(3)T y están presentes en todas las versiones de IOS-XE.
Documentación completa: http://www.cisco.com/c/en/us/td/docs/ios/12_2/12_2x/12_2xu/feature/guide/ftpg_str.html#wp1034848
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 !
IOS 15.6(2)T y IOS-XE 16.3.1 introdujeron arrendatarios de clase de voz que permiten a cada arrendatario tener 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 tener una configuración global específica. En primer lugar, un administrador crea un arrendatario de clase de voz y define los parámetros. A continuación, el arrendatario de clase de voz se aplica al dial-peer o a la opción específica. Esta nueva configuración ofrece a los administradores otro nivel de control sobre las llamadas que van más allá de los pares de marcado y la configuración global.
A partir de 17.8.1a, las configuraciones del arrendatario de clase de voz se pueden configurar con un comando sip-hear (junto con el comando de enlace de control SIP adecuado) para definir el puerto no seguro o seguro del arrendatario. Esto significa que el arrendatario 1 podría escuchar por SIP inseguro en UDP 5060 + VRF rojo mientras el arrendatario 2 escucha SIP en TCP TLS 5070 + VRF azul. Después de hacer coincidir el arrendatario en función del puerto de escucha + bind + vrf opcional, los pares de marcado entrantes se filtran a aquellos que tienen aplicado el arrendatario.
Documentación completa:http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-multi-tenants.html
Escucha SIP en arrendatario:https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/ios-xe/config/ios-xe-book/m_voi-cube-multi-tenants.html
Orden normal de preferencia de comando sin arrendatarios
Orden de preferencia de comando con arrendatarios
Ejemplo de Configuración de Varios Arrendatarios
Tenemos dos arrendatarios 777 y 999. Los hemos configurado con configuraciones ligeramente diferentes y los hemos aplicado a nuestros pares de marcado. Esto significa que las llamadas que utilizan los diferentes pares de marcado tienen las configuraciones basadas en el par de marcado así como las configuraciones específicas del arrendatario. Las siguientes opciones son sólo un fragmento del poder 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 el etiquetado de números con cadenas de números para separar la coincidencia de pares de marcado de arrendatarios, o incluso configurar VRF para que el Arrendatario A nunca se superponga con el Arrendatario B y coincida accidentalmente con un par de marcado que no deberían.
!
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 los arrendatarios de clase de voz. El siguiente comando debe ser suficiente para filtrar la configuración en ejecución a sólo la información del arrendatario.
show run | sec tenant
Nota: CSCvf28730 , donde show sip-ua register status no refleja el estado del registro troncal SIP en un arrendatario de clase de voz.
Las cadenas de ruta se utilizan con CUCM Intercluster Lookup Service (ILS) y se pueden configurar para permitir que Cisco Gateways enrute llamadas VoIP a través de la cadena de ruta incluida en SIP INVITE recibida de un CUCM 9.5+ que ejecuta el servicio ILS. Esta función se agregó en IOS 15.3(3)M y IOS-XE 3.10S. La mayoría de las conexiones ILS son de CUCM a CUCM y los administradores no se molestan en involucrar un CUBE para el enlace troncal entre clústeres. Sin embargo, si necesitamos realizar la función con CUBE en el medio, las opciones están ahí. CUCM necesita tener la configuración Send ILS Learned Destination Route String habilitada en el perfil SIP aplicado al troncal SIP para enviar el encabezado x-cisco-dest-route-string a CUBE
Documentación completa:http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube_interop/configuration/15-mt/cube-interop-15-mt-book/voi-cube-ils-service.html
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
Los elementos que se tratan en esta sección se consideran técnicas antiguas. Si bien la capacidad de configurarlos todavía está presente en una puerta de enlace de Cisco, no se recomienda utilizar estos comandos en configuraciones modernas. Este documento solo los cubre porque se pueden encontrar mientras se trabaja con configuraciones antiguas o cuando se realizan actualizaciones.
Los mapas DNIS podrían considerarse el precursor de lo que sería un mapa de patrones E164. Los mapas DNIS se agregaron al IOS en 12.2(2)XB y siempre han existido en IOS-XE.
Si hay mapas DNIS configurados, valdría la pena convertirlos a la función e164-pattern-map más robusta.
Sintaxis de comandos: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-d2.html#wp3372710070
Ejemplo de configuración:
! voice dnis-map 34 dnis 8675309 ! dial-peer voice 88 voip dnis-map 34 !
Las etiquetas de grupo troncal se agregaron en IOS 12.2(11)T y existen en todas las versiones IOS-XE. El propósito de una etiqueta de grupo troncal 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 de troncales POTS, pares de marcado VOIP y POTS, así como grupos de origen de voz. El uso de las etiquetas de grupo de enlaces que rara vez se ven en las configuraciones modernas de Cisco Gateway.
Sintaxis de comandos: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr5/vcr5-cr-book/vcr-t3.html#wp2051313870
Ejemplo de configuración:
! dial-peer voice 112 pots trunk-group-label source north3 trunk-group-label target east17 !
Con las integraciones ISDN Q.931 existe la posibilidad de hacer coincidir un par de marcado basado en el número que llama o al que llama, así como en el tipo de número ITU específico de la mensajería Q.931 SETUP. Esto se puede configurar a través del comando number-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 tanto la condición de la instrucción coincidente entrante/saliente COMO el tipo de número debe coincidir para que el par de marcado se considere correcto 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 el mismo peso de preferencia predeterminado si no se aplica ninguna preferencia de 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 IOS 12.0(7)XR1 y está presente en todas las versiones de IOS-XE. Con la disminución de las líneas ISDN POTS tradicionales que se implementan en las redes de colaboración, el uso del tipo de numeración rara vez se ve en implementaciones modernas.
Sintaxis de comandos: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr3/vcr3-cr-book/vcr-n1.html#wp3304694174
Ejemplo de configuración:
Este dial-peer puede coincidir 4085150000 a 4085159999 solamente 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úmeros posibles:
Abreviado | Representación abreviada del número completo según admite esta red |
Internacional | Número llamado para alcanzar un suscriptor en otro país |
Nacional | Número llamado para alcanzar un suscriptor en el mismo país, pero fuera de la red local |
Red | Número administrativo o de servicio específico de la red de servicio |
Reservado | Reservado para extensión |
Suscriptor | Número llamado para alcanzar un suscriptor en la misma red local |
Desconocido | La red desconoce el tipo de número |
Los pares de marcado de datos se introdujeron en el IOS 12.2(13)T y la utilidad de dichos pares de marcado fue para las llamadas de módem de datos entrantes en una gateway de Cisco. Este dial-peer sólo se utiliza en la dirección entrante y rara vez se ve en implementaciones modernas.
Sintaxis de comandos: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr2/vcr2-cr-book/vcr-d1.html#wp1448833490
Ejemplo de configuración:
! dial-peer data 100 pots incoming called-number 100 !
Esta función se agregó en 15.1(2)T, pero no se implementa en muchas implementaciones modernas. Por lo general, se implementan otros métodos de seguridad para IOS/CUBE.
La descripción general de CUBE Application Security se puede ver en el siguiente informe técnico a partir de la sección 4.2.
Sintaxis de comandos: https://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-border-element/116440-configure-vsg-00.html
Esta configuración permite que un administrador restrinja un par de marcado para permitir conexiones entrantes solamente (término / finalización) o conexiones de salida (orig / originate). Esto sería como configurar explícitamente un dial-peer entrante para que sólo se utilice para llamadas entrantes y un dial-peer saliente para llamadas salientes. El valor predeterminado para cualquier par de marcado es permitir tanto las conexiones entrantes como las salientes. Esta CLI no suele implementarse en 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
En algún momento de una implementación de colaboración, un administrador puede necesitar manipular dígitos o un encabezado URI/SIP. Cisco Gateways cuenta con numerosos métodos para la manipulación de dígitos, lo que permite al administrador controlar por completo cómo y cuándo se debe manipular un dígito. Sin embargo, esto puede ser desalentador para algunos ya que están abrumados con las diferentes opciones O el administrador no sabe que existe una opción.
Los pares de marcado POTS tienen algunas técnicas únicas de manipulación de dígitos que los pares de marcado VOIP no tienen.
La primera es la eliminación de dígitos explícitamente definidos con justificación a la izquierda en un patrón de destino. Esto se puede inhabilitar usando el comando no digit-stripteen el dial-peer POTS.
Ejemplo:
En este ejemplo hemos definido 9011T como la cadena para el patrón de destino.
Con esto en su lugar, recibimos una llamada para el 90113227045555. Esto coincide con nuestro dial-peer 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 !
El siguiente ejemplo muestra una configuración sin tira de 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 desearíamos reenviar en el dial-peer POTS.
Tome el siguiente ejemplo donde recibimos una llamada para el 91 8005532447 de CUCM. En esta situación, queremos eliminar el 9 pero enviar el resto del número empezando por el 1.
Si configuramos el comando forward-digits en el dial-peer POTS, podemos especificar exactamente cuántos dígitos enviamos.
! dial-peer voice 1 pots destination-pattern 918005532447 forward-digits 11 port 0/2/0 !
Por último, los pares de marcado POTS pueden utilizar el comando prefix para agregar dígitos a una llamada antes de rutear el puerto de voz. El siguiente ejemplo elimina el 91 definido explícitamente y el prefijo 007 del 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 !
Las reglas de traducción de voz son expresiones regulares (regex) utilizadas para transformar dígitos. Las reglas de traducción y los perfiles se agregaron al 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 a un 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 coincidencia y modificación de entrada para el tipo y plan ISDN. La combinación de cadena de número de coincidencia, plan y tipo se considera una coincidencia AND. 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 Llamadas, Llamadas, Llamadas redirigidas, Destino redirigido y Número de devolución de llamada en los protocolos de señalización ISDN, SIP y H323. Las reglas de traducción coinciden en función de una búsqueda descendente, por lo que el orden de las reglas es de suma importancia. Si se encuentra una coincidencia en una regla superior, la puerta de enlace detiene inmediatamente la búsqueda y procesa la traducción. Las reglas de traducción no pueden cambiar los 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 Cisco Gateways.
Preferencia de selección de perfil de traducción
Además de las reglas de traducción de pares de marcado (dial-peer regex) y wilcards translation-rules, tienen sus propios caracteres regex.
Carácter | Definición |
* | Cuando se utiliza en las reglas de traducción, esto es regex para 0 o más del carácter anterior. Para hacer coincidir un literal *, utilice un carácter de escape: \* |
\ | Normalmente se utiliza para escapar de conjuntos en la regla de traducción \( \) |
Y | Ampersand se utiliza para traer cualquier coincidencia en la coincidencia inicial establecida para el conjunto de modificaciones |
( ) | Los elementos envueltos entre paréntesis se consideran un conjunto. |
^ | Define el inicio explícito de una cadena. A diferencia de dial-peers translation-rules no definen el comienzo de la cadena. Esto significa que definir una cadena sin un ^ puede coincidir en cualquier parte de la cadena de entrada, lo que puede llevar a traducciones no deseadas en medio de un número. |
Conjuntos de modificaciones
Ejemplo de regla de traducción con dos conjuntos
En este ejemplo examinamos el número 000111000222.
Queremos eliminar los 0 del número y obtener un número final de 111222.
Para ello, configuramos los conjuntos 1 y 2 para atrapar los 111 y 222 respectivamente mientras se descartan los 0s.
! 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 9 de marcación saliente de un número llamado
! 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
Truncación del 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 llamado
! 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 aplicarse 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> !
Depuración de 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>
La función de traducción de clase de voz e164 es una función IOS-XE más reciente que permite a un administrador crear una lista de declaraciones de coincidencia y modificar instrucciones que se cargarán a través de un archivo de configuración desde la memoria flash o un directorio de red. Esto es similar al concepto para 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 la sintaxis siguiente 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 fallará sin ese paso de formato adicional.
Sample.cfg
+111111 8897 +222222 8312 928747 +123456789 737362 +987654321
A continuación, este archivo se refiere a las siguientes referencias:
voice class e164-translation 164 url ftp://username:password@10.10.10.10/sample.cfg
Ahora se aplica normalmente a un perfil de traducción y, a partir de ahí, 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.
Gracias a Swati Sharma por detallar este proceso para el documento
Los MAPS ISDN son una técnica más antigua para modificar dígitos. Esto se agregó en 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 en 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
Al igual que ISDN Maps Number Expansion (Expansión del número de mapas de ISDN) es una técnica más antigua que se agrega en IOS 11.3(1)T y que no se utiliza mucho en las nuevas redes. Esta función se agregó antes de que existieran las reglas de traducción de voz y los perfiles. La expansión del número es un cambio global de dígitos aplicado a todos los pares de marcado en un Cisco Gateway. La modificación se aplica al número llamado DESPUÉS de que el par de marcado haya coincidido 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
Los perfiles SIP son instrucciones de coincidencia de expresiones regulares (regex) robustas que permiten a un administrador cambiar cualquier aspecto de un mensaje SIP, incluidos los encabezados SDP y SIP. Se pueden habilitar globalmente, por dial-peer o por arrendatario. Los perfiles SIP están disponibles para las modificaciones entrantes que comienzan con IOS 15.4(2)T y IOS-XE 3.12S . Dado que los perfiles SIP son tan robustos que este documento sólo abarca algunos ejemplos específicos. Los perfiles SIP también añaden la capacidad de modificar o agregar encabezados SIP personalizados en IOS 15.5(2)T e IOS-XE 3.13S.
Puntos clave sobre perfiles SIP entrantes frente a salientes
Otras notas sobre la configuración de sip-profile:
Documentación completa: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-sip-param-mod.html?bookSearch=true
Herramienta de prueba de perfiles SIP:https://cway.cisco.com/tools/SipProfileTest/
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
Tenga en cuenta: Se requiere habilitar "sip-profile inbound" en 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 mensajes keepalive de OPCIONES
!
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 quitar encabezados de desviación
! 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 ID de la persona que llama 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 a un timbre 180.
! 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 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 para 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 saltos de lógica IF y de línea nueva con un perfil SIP.
Los saltos de línea nuevos se admiten en los perfiles SIP, pero solo hay un caso práctico muy específico para ellos. Dado que los perfiles SIP no tienen ningún IF, entonces, la lógica Else ahora hay forma de realizar modificaciones a un encabezado basadas en una entrada de otro encabezado. Es decir, un administrador sólo desea modificar un encabezado de desviación si el encabezado FROM contiene 1234@cisco.com. Utilizando el salto de línea nueva, podemos "imitar" la sentencia IF dentro de un perfil SIP. Vea el ejemplo de configuración a continuación: Coincidimos con 1234 en cualquier dominio del encabezado From. A continuación, pasamos el primer conjunto y agregamos un nuevo salto de línea "\x0D\x0AD". Finalmente agregamos el encabezado que queremos. Observe que este método sólo nos permite AGREGAR un encabezado. No hay forma de modificar otro encabezado. Por lo tanto, esto solo cumple parcialmente los requisitos que un administrador deseaba cumplir 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 a través de 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
!
SIP Copylist es una extensión de perfiles SIP que permite al gateway COPY un encabezado desde el tramo interno de una llamada y, a continuación, PASTE a otro punto del mensaje SIP de salida en el tramo externo. El soporte de lista de reproducción SIP se agregó en IOS 15.1(3)T e IOS-XE 3.6S. Esta es una forma poco eficaz de crear encabezados dinámicos basados en otros encabezados desde el tramo de la llamada.
El caso práctico más común es copiar dinámicamente un encabezado FROM a un encabezado diferente, como desviación o id-afirmado-p, de modo que el valor de la parte del usuario sea el del usuario. Esto se realiza principalmente para fines de autenticación y de identificación de llamada.
Documentación completa: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/copy_sip_headers.html?bookSearch=true
Ejemplo de Lista 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@14.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 lista de copias
debug voip ccapi inout debug ccsip mess debug ccsip info debug ccsip feature sip-profile
Salida de depuración de la lista de copia SIP de ejemplo
### Ingress from CUCM Received: INVITE sip:1001@14.50.228.61:5060 SIP/2.0 Via: SIP/2.0/TCP 14.50.244.3:5060;branch=z9hG4bKaad21bc3ae7e From: "5001" <sip:5001@14.50.244.3>;tag=100442~cdffff43-5020-4e79-a10b-99d406971010-36470319 Contact: <sip:5001@14.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@14.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 : : @165.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@165.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@165.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 14.50.228.61:5060;branch=z9hG4bK3C7CD Remote-Party-ID: "5001" <sip:5001@14.50.228.61>;party=calling;screen=yes;privacy=off From: "5001" <sip:5001@14.50.228.61>;tag=34C458-D6 Contact: <sip:5001@165.117.64.94>
Todos los protocolos de señalización permiten a los administradores enlazar la señalización a una interfaz específica. De forma predeterminada, un gateway sin un enlace estático definido el gateway 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 rutea a través de la interfaz física. El enlace de par de marcado siempre reemplaza el enlace voip de la clase de voz y del servicio de voz global con el protocolo de inicio de sesión (SIP).
Muchas veces los administradores enlazan la señalización a un loopback. Al tratarse de una interfaz lógica, no hay paquetes que atraviesen 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 remota/de destino incluso si la configuración está enlazada a una interfaz virtual.
El enlace de medios y señalización no siempre necesita ser la misma IP. Si un administrador necesita enlazar a una interfaz específica para señalizar hacia/desde un CUCM, pero es posible que el audio/medio entre el teléfono y la puerta de enlace deba conectarse a otra interfaz.
Ejemplo de configuración
Este ejemplo muestra un dial-peer 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 show ip cef muestra que cualquier paquete enviado a CUCM sale en 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 el enlace de aplicaciones de capa 7
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> !
DNS con VOIP se utiliza sólo en 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 hay búsqueda de dominio ip configurada globalmente en la puerta de enlace. Esto significa que aunque desactivamos el DNS, los pares de marcado VOIP aún resuelven la entrada DNS. Sin embargo rRecientemente, en IOS-XE 3.16S hubo algunos cambios en la funcionalidad DNS general dentro de las plataformas 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 que siempre se asegure de que el comando "ip domain lookup" esté configurado al trabajar con DNS para evitar este problema.
Para las conexiones SIP salientes, realizamos el siguiente orden de operaciones para la resolución de DNS.
Para obtener información sobre cómo se crea el SRV o cómo omitir el SRV y realizar una consulta de registro A en un destino de sesión, consulte la documentación completa: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-sip-dns-srv-rfc2782.html
Para las conexiones SIP entrantes donde una gateway IOS necesita resolver un encabezado para responder a un mensaje, la gateway utilizará el siguiente orden de operaciones para la resolución de DNS
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 IOS-XE es compatible con 15.6(1)S / 3.17.00.S y versiones superiores
Comandos de depuración y verificación de DNS
show host clear host all * ! debug ip dns view debug ip domain debug ccsip info
debug ccsip error
Prueba de DNS 3.15S y por debajo
### 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 14.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: 14.50.244.2
Prueba de DNS 3.16S y superiores
### 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 14.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=1.1.128.7.47.0 on callID 6 GUID=37B668DF044111E7A950D832C82B325C
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 IOS 11.3(1)T y está presente en todas las versiones de IOS-XE mientras que max-bandwidth se agregó en 15.2(2)T e IOS-XE 3.7S
Ejemplo de configuración:
A continuación, le indicamos al gateway que limite las llamadas del par de marcado 1 a 30 mediante "max-conn 30".
El par de marcado 2 está limitando el ancho de banda para ese par de marcado para que no superemos 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 supera el umbral de conn máximo
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=1.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 14.50.244.62:5060;branch=z9hG4bKb78c35aa21b0 From: <sip:9001@14.50.244.62>;tag=72531~2e8ca155-3f0b-4f07-a1b2-b14ef77ceb7f-26250846 To: <sip:1234@14.50.245.70>;tag=3E19564D-1684 Date: Thu, 05 Oct 2017 19:01:02 GMT Call-ID: 86b07080-9d61816e-b762-3ef4320e@14.50.244.62 CSeq: 101 INVITE Allow-Events: telephone-event Warning: 399 14.50.245.70 "Maximum Number of Connections reached for dial-peer 1" Server: Cisco-SIPGateway/IOS-15.4.3.S4 Content-Length: 0
Con la marcación entrante directa activada en los pares de marcado POTS, la mensajería entrante debe contener todos los dígitos necesarios para enrutar la llamada. La puerta de enlace de Cisco no debe realizar la recogida de dígitos posterior. Cuando el router o la puerta de enlace busca un par de marcado saliente, el dispositivo utiliza toda la cadena de marcado entrante. Esta coincidencia es de longitud variable de forma predeterminada. Esta coincidencia no se realiza dígito por dígito porque, por definición de DID, se han recibido todos los dígitos. Esta es la configuración predeterminada para los pares de marcado POTS.
Documentación completa: http://www.cisco.com/c/en/us/support/docs/voice/digital-ccs/14072-direct-inward-dial.html
Ejemplo de configuración:
! dial-peer voice 1 pots incoming called-number 8675309 voice-port 0/0/0 direct-inward-dial !
Si el dial-peer POTS entrante se configura con no direct-inward-dial, el router o la gateway ingresa al modo de recopilación de dígitos (los dígitos se recopilan dentro de la banda). La coincidencia de par de marcado saliente se realiza dígito por dígito. El router o la gateway verifica si hay coincidencias de par de marcado después de que el dispositivo haya recibido cada dígito y luego rutea 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
!
Cada protocolo maneja el bloqueo de llamadas un poco diferente. La mayoría de los protocolos pueden hacer uso del patrón de rechazo de regla de traducción que bloquea en base a una cadena de dígitos. Si un administrador desea aplicar un perfil de traducción entrante para la manipulación normal de dígitos pero no bloquear ningún número dentro, 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 la función de recopilación de llamadas. Esto se observa y se emplea principalmente en implementaciones en Brasil, pero se puede configurar a través de cualquier grupo personalizado.
Las dos opciones son:
Mensaje de bloqueo 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 Respuesta Doble
! 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 respuesta doble (debug vpm signal)
### 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
Hay implicaciones para la coincidencia de dial-peer entrante cuando el comando isdn superposición-recepción se configura en las interfaces ISDN. Después de recibir cada dígito en la capa ISDN, se comprueban 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 por dígito y obligar al router o la gateway a esperar hasta que se reciban todos los dígitos. La 'T' se refiere al temporizador entre dígitos en el nivel ISDN, configurable en la interfaz serial que se relaciona con la interfaz ISDN. La RDSI también proporciona otros mecanismos para indicar el final de los dígitos, como la configuración del Elemento de información completa de envío (IE) en los mensajes de información Q.931.
El mensaje de advertencia que se muestra a continuación se muestra cuando el par de marcado se configura con el número de llamada entrante T
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 comparado con un puerto de voz y/o en algunos casos dirección de respuesta. Por lo tanto, una coincidencia basada en un número llamado "null" SOLAMENTE puede ocurrir si no hay coincidencia basada en dirección de respuesta o número de puerto.
En el caso de la marcación superpuesta, un número llamado "nulo" no coincide con el "número llamado entrante T" porque no se ha agotado el tiempo de espera.
Un número llamado "nulo" puede coincidir con el "número llamado entrante T" sólo en el caso de ENBLOCK y no hay coincidencia tampoco debido a la dirección de respuesta y al número de puerto. La advertencia mostrada se refiere a este caso específico cuando un administrador configura el "número de llamada entrante T".
La clase de restricción es una forma de limitar las llamadas en una puerta de enlace de Cisco. El COR se describe a menudo como un mecanismo de bloqueo y clave. 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 las listas COR, los pares de marcado salientes disponibles son aquellos que la clave puede desbloquear. Este filtrado ocurre antes de que se verifique el resto de los métodos de coincidencia de par de marcado saliente.
Dos reglas importantes con clase de restricción:
La configuración de 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 los siguientes documentos para su posterior lectura.
CME crea pares de marcado del sistema para ephones y grupos de registro de voz. No se pueden ver en la configuración en ejecución. Para realizar cambios en los pares de marcado CME, es necesario realizar los cambios en el grupo de registros de voz o teléfono real. Al ver las salidas show dial-peer voice summary, el dial-peer que comienza con 2000 son ephones SCCP y pares de marcado que comienzan con 4000 son grupos de registro de voz SIP. Este dial-peer aparece como el dial-peer entrante para las llamadas de los teléfonos registrados CME y el dial-peer saliente en las depuraciones para llamadas a los teléfonos registrados CME.
Ejemplo de Salida para show dial-peer voice summary con 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 con 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 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 es manejado por el proceso STCAPP y MGCPAPP. Cuando examinamos la configuración de estos pares de marcado, tienen el comando "service mgcpapp" o "service stcapp". Éstos habilitan el dial-peer para la aplicación elegida, así como le indican a la aplicación qué dial-peer debe manejar.
Al depurar estos protocolos, el resultado nunca muestra una coincidencia de dial-peer entrante. Esto siempre debe aparecer como dial-peer 0. Porque no existe. El agente de llamadas que gestiona la aplicación ya ha elegido a qué puerto enviar la llamada y a qué 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 dial-peer saliente. Esto es solo para mostrar, ya que en última instancia el agente de llamadas que gestiona el proceso también tiene control sobre ese lado de la llamada.
Recuerde que el par de marcado sólo indica a la aplicación de elección qué puerto de voz físico controlar. Puesto que la mayor parte de esto está controlado por un agente de llamadas externo y el gateway sólo hace lo que se le dice, vamos a omitir el "cómo" subyacente en esta sección y proporcionar algunas configuraciones para comenzar.
Ejemplo de configuración 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 MGCP completa: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cminterop/configuration/15-mt/dia-15-mt-book/vc-ucm-mgcp-gw.html
Ejemplo de configuración SCCP/STCAPP [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
!
Documentación de SCCP completa: http://www.cisco.com/c/en/us/td/docs/routers/access/vg202\_vg204/software/vg2\_vg4\_scg/vg2\_vg4\_voip.html
* Si un administrador no desea que CUCM configure el gateway, simplemente elimine los comandos "ccm-manager". Hemos incluido la configuración de dial-peer para llevar a casa el punto sobre cómo funciona el concepto. Con las configuraciones de ccm-manager presentes, CUCM crea estos pares de marcado basándose en la configuración del puerto en CUCM, por lo que no es necesario definir realmente el par de marcado. Los pares de marcado creados por CUCM normalmente comienzan con 999 y luego son tres dígitos más.
SIP DSAPP se agregó en IOS-XE 16.12.1+ y CUCM 12.5.1SU+
Con esta función, CUCM puede registrar y administrar 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 siguen coincidiendo normalmente. Es decir, el gateway recopilará dígitos del puerto FXS y realizará una búsqueda de dial-peer en los pares de marcado VOIP. Después de encontrar una coincidencia, se envía INVITE al bloque CUCM para que CUCM realice un análisis de dígitos adicionales.
Ejemplo de configuración de SIP DSAPP [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: https://www.cisco.com/c/en/us/td/docs/routers/access/vg450/software/configuration/guide/vg450-scg/vg450-scg_chapter_010.html#wp3621733520
Esta sección se ha eliminado en 2022. Consulte el nuevo documento para obtener información más detallada
Revisión | Fecha de publicación | Comentarios |
---|---|---|
3.0 |
27-Apr-2022 |
republicación tras cambios menores. |
1.0 |
30-May-2017 |
Versión inicial |
Nota: * La excepción a esta regla es con los puertos de voz MGCP y SCCP. Estos protocolos de señalización no siguen el mecanismo normal de coincidencia de par de marcado durante el ruteo de llamadas. Consulte la sección SCCP y MGCP para obtener más detalles.