Comprensión de Direct-Inward-Dial (DID) en interfaces IOS Voice Digital (T1/E1)

Introducción

Este documento describe los routers/gateways habilitados para voz Cisco IOS® con interfaces digitales (T1/E1). Para obtener más información sobre el Direct Inward Dialing (DID - Marcado de Entrada Directo) analógico de Cisco, refiérase a: DID Analógico para Cisco 2600 Series Routers y Cisco 3600 Series Router

Nota: En la mayoría de las plataformas, DID está habilitado de forma predeterminada en las interfaces CAS (inmediato, wink, delay). Por tanto, para las llamadas entrantes no configure el comando direct-inward-dial. En las plataformas Cisco AS5300 no se soporta DID en interfaces configuradas para la señalización inmediata E & M.

Prerequisites

Requirements

No hay requisitos específicos para este documento.

Componentes Utilizados

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando. Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

Para obtener más información sobre las convenciones del documento, consulte Convenciones de Consejos Técnicos de Cisco.

Antecedentes

DID es un servicio ofrecido por compañías telefónicas que permite a las personas que llaman marcar directamente a una extensión en un sistema de paquete de voz o Central telefónica privada (PBX) sin la asistencia de un operador o un operador automático de llamadas. Este servicio utiliza troncos DID, que reenvían sólo los últimos tres a cinco dígitos de un número telefónico al PBX o router/gateway. Si, por ejemplo, una compañía tiene las extensiones de teléfono 555-1000 a 555-1999 y alguien marca 555-1234, la oficina central (CO) local reenvía 234 al PBX o al sistema de voz por paquetes. El PBX o el sistema de voz por paquetes (Cisco CallManager y router/gateway IOS) entonces llamaría a la extensión 234. Todo este proceso es transparente para la persona que llama.

En este documento, se tratan dos tipos de pares de marcado de la siguiente manera:

• Servicio telefónico convencional (POTS): llamada de voz tradicional a través de la Red Telefónica Pública Conmutada (PSTN) en la que se obtiene un tramo de llamada de extremo a extremo del circuito de 64K dedicado para toda la duración de la llamada. Los pares de marcado de POTS siempre apuntan a un puerto de voz en el router

• Red de voz: una llamada de voz a través de la red de datos se compone de varios tramos de llamada. Cada tramo de la llamada pasa por dispositivos de datos (routers/gateways) o desde dispositivos de datos a dispositivos de telefonía (por ejemplo, desde un router hacia una PBX). Los pares de marcado de red de voz indican distintos destinos teniendo en cuenta la tecnología de red que se utiliza. Los dial peers de la red de voz incluyen:

  • Voz over IP (VoIP)

  • Voz over Frame Relay (VoFR)

  • Voz over ATM (VoATM)

  • Correo multimedia sobre IP (MMoIP)

Cuando ingresa una llamada de voz al router/gateway de Cisco IOS, el puerto de voz en el router es detectado por un switch PBX o CO. El router/gateway luego le presenta un tono de marcado a quien realiza la llamada y recolecta dígitos hasta que puede identificar un par de marcado saliente. Independientemente de que los dígitos sean marcados con intervalos regulares por personas o de forma regular por equipos de telefonía que envían los dígitos recopilados previamente, la concordancia de pares de marcado se realiza dígito por dígito. Esto significa que el router/gateway intenta buscar una coincidencia con un dial peer tras recibir cada dígito. A este proceso se lo denomina marcado en dos etapas.

Sin embargo, si el switch PBX o CO envía un mensaje de configuración que contiene “todos” los dígitos necesarios para rutear completamente la llamada, esos dígitos pueden ser correlacionados directamente con un par de marcado de red de voz saliente. Con DID, el router/gateway no presenta un tono de marcado al que llama y no recopila dígitos. Reenvía la llamada directamente al destino configurado. Esto se denomina marcado en una etapa.

Los dígitos necesarios para rutear las llamadas sobre las que se trató en los párrafos anteriores son de los dos siguientes tipos:

• El Digital Number Identification Service (DNIS) es un servicio digital proporcionado por la compañía telefónica que suministra el número llamado (el número que se marca).

• La identificación automática del número (ANI) es un servicio digital provisto por la compañía telefónica que entrega el número que llama (el número del originador de llamada). ANI también se denomina identificación de línea de llamada (CLID).

Configuración de DID para interlocutores de conexión de POTS

Cuando se recibe una llamada entrante desde una interfaz de Servicio telefónico analógico convencional (POTS), la función DID en los pares del marcado habilita al router/gateway a utilizar el número llamado (DNIS) para que coincida directamente con un par del marcado saliente. Cuando DID está configurado en el par de marcado POTS entrante, el número marcado se utiliza automáticamente para corresponder el patrón de destino para el tramo de llamada saliente.

Para configurar el interlocutor de conexión de POTS para DID, ingrese los siguientes comandos de Cisco IOS comenzando en el modo de configuración global:

Router(config)#dial-peer voice number pots		
Router(config-dial-peer)#direct-inward-dial

Concordancia de interlocutor de conexión de POTS entrante adecuado para DID

Para que DID funcione correctamente, asegúrese de que la llamada de entrada coincide con el dial-peer de POTS correcto en el que está configurado el comando direct-inward-dial. Para coincidir con el par de marcado entrante correcto, recomendamos usar el comando del par de marcado incoming called-number dnis_string bajo el par de marcado DID POTS.

Los otros comandos que se usan para hacer coincidir los pares de marcado son: answer-address ani_string , destination-pattern string o port voice-port . La ventaja de utilizar el comando incoming called-number es que cada llamada posee información DNIS asociada (número llamando) y este comando tiene prioridad sobre los anteriores.

Si no utiliza el comando incoming called-number para buscar una coincidencia con el dial peer entrante, considere lo siguiente:

• Si utiliza información de ANI para buscar una coincidencia con el dial-peer de DID POTS, asegúrese de que el comando answer-address está configurado correctamente y el switch de la compañía telefónica proporciona información de ANI. Algunos proveedores ISDN y la mayoría de la señalización asociada al canal T1, a excepción del Grupo de funciones D (fgd), no brindan información de ANI.

• Si el comando answer-address NO coincide con ANI, es posible que ANI coincida con el comando destination-pattern configurado (para marcación saliente) en otro interlocutor de conexión de POTS. Si el comando del diagrama de destinos se compara con ANI, asegúrese de que el comando de marcado directo entrante (DID) está configurado en el comando de par de marcado.

• Si la llamada DID entrante no coincide con un par de marcado POTS entrante según incoming called-number o answer-address o destination-pattern o port, entonces se utilizará el par de marcado predeterminado 0. DID se encuentra inhabilitado en forma predeterminada en el par de marcado 0.

Caso Práctico

Utilice el siguiente ejemplo para ilustrar los puntos anteriores. La compañía ACME tiene líneas T1 PRI con 40 trunks DID en el rango 555-3100 a 555-3139. El objetivo es asignar las primeras 20 líneas a Cisco IP Phones. Las últimas 20 líneas están disponibles para pruebas o expansión futura y, por ahora, el router solamente da el tono de marcado. Asumiendo que el switch CO está enviando sólo los últimos cinco dígitos del mensaje de configuración ISDN, podemos resumir la información mencionada anteriormente en la siguiente tabla.

Configuración

Nota: Se omite parte de la salida de este ejemplo.

dial-peer voice 2 pots 
        destination-pattern 9T 
        port 1/0:23

 !--- This dial-peer is used mainly for outbound dialing with the !--- destination-pattern 9T mapped to port 1/0:23. Note that 9 is an !--- explicit match and will be stripped. Say a call comes from the CallManager !--- with a DNIS 914085551126, the router will send only 14085551126. If you add !--- the dial-peer command prefix 9 or the command forward-digit all then !--- the string 914085551126 is sent. Notice that dial-peer voice 2 pots is also !--- matched to give dial tone to incoming users dialing this range: !--- (53120 - 53139).

     dial-peer voice 3 pots 

 !--This dial-peer can be matched inbound only

      incoming called-number 5310.  

 !--DNIS range 53100-53109 

      direct-inward-dial  

 !--If this dial-peer is matched inbound, the router is put in DID mode

     !
     dial-peer voice 4 pots 

 !--This dial-peer can be matched inbound only

      incoming called-number 5311.   

 !--This takes care of the range 53110-53119

      direct-inward-dial 

 !--If this dial-peer is matched inbound router is put in DID mode

     !
     dial-peer voice 5 voip  

 !--For our case, this dial-peer is matched outbound only 

      destination-pattern 53... 

 !--When calls terminate on this router, dial-peer 5 can be matched inbound, too.

      session target ipv4:172.22.1.1 

 !--IP address of CallManager

      codec g711ulaw 

Problemas comunes

Nota: Los códigos de causa de desconexión tienen diferentes formatos en la salida de debug isdn q931 en comparación con el comando debug voip ccapi inout.

• Para interpretar los códigos de causa de la desconexión de llamada Q.931 del comando debug voip ccapi inout, refiérase a: Troubleshoot y Debug de Llamadas VoIP – Conceptos Básicos

• Para interpretar los códigos de causa de desconexión de llamada Q.931 del comando debug isdn q931, refiérase a: Introducción de los códigos de desconexión del comando debug isdn q931

Para ver los códigos de causa de evento Q.931 en formato decimal, refiérase a: Códigos de causa de eventos ISDN

A continuación se muestran algunos ejemplos de síntomas y los problemas que pueden causarlos:

• Síntoma: El router/gateway proporciona tono de marcado y espera hasta que se agote el tiempo de espera del temporizador entre dígitos. Después se desconecta con debug voip ccapi inout cause code = 0x1C (formato de número no válido) o debug isdn q931 (para interfaces ISDN) disconnect cause code = 0x809C (formato de número no válido).

  • Problema: DID está configurado en el switch de la compañía telefónica pero no en el router/gateway de Cisco IOS.

• Síntoma: el gateway/router se desconecta con debug voip ccapi inout cause code = 0x1 (número no asignado/no atribuido) o debug isdn q931 (para interfaces ISDN) disconnect cause code = 0x8081 (número no asignado/no atribuido).

  • Problema: Se configura el DID y se buscan coincidencias del dial peer POTS entrante correcto en el router/gateway de Cisco IOS, pero el mensaje de configuración no incluye el número llamado (DNIS). En este caso, consulte a la compañía telefónica si se proporciona troncal para DID.

• Síntoma: El router/gateway se desconecta con el código de causa de debug voip ccapi inout = 0x1 (número no asignado/no asignado) o debug isdn q931 (para interfaces ISDN) disconnect cause code = 0x8081 (número no asignado/no asignado).

  • Problema: El DID configuró y se hizo coincidir en el router o la gateway del IOS de Cisco, pero no hay coincidencia de par de marcado de salida en el router o la gateway.

  • Problema: Asegúrese de que la llamada de entrada corresponde al dial-peer POTS correcto en el que está configurado el comando direct-inward-dial. Para mayor información, consulte en este documento la sección Coincidencia del par de marcado de POTS entrante correcto para DID.

Resultado de ejemplo de show y debug

Nota: Algunas de las siguientes líneas de salida de depuración se dividen en varias líneas para fines de impresión.

2600#debug isdn q931
ISDN Q931 packets debugging is on
2600#debug voip ccapi inout
voip ccAPI function enter/exit debugging is on

2600#show debug
ISDN:
  ISDN Q931 packets debugging is on
  ISDN Q931 packets debug DSLs. (On/Off/No DSL:1/0/-)
  DSL  0 --> 31
  1 - - - - - - -  - - - - - - - -  - - - - - - - -  - - - - - - - -  
voip:
  voip ccAPI function enter/exit debugging is on


!--- Action: Cisco IOS router/gateway receives a call from the PSTN to !--- extension "53103"

*Mar  1 04:51:11.856: ISDN Se1/0:23: RX <-  SETUP pd = 8  callref = 0x0001
*Mar  1 04:51:11.860:         Bearer Capability i = 0x9090A2
*Mar  1 04:51:11.860:         Channel ID i = 0xA98381
*Mar  1 04:51:11.864:         Calling Party Number i = 0x0083, '408', Plan:Unknown,
      Type:Unknown
*Mar  1 04:51:11.868:         Called Party Number i = 0x80, '53103', Plan:Unknown,
      Type:Unknown

!--- ISDN Q.931 and Voip ccapi inout debugs collectively show a DNIS of 53103 and !--- an ANI (Automatic Number Identification) of 408 sent in unknown plan and type.


*Mar  1 04:51:11.880: cc_api_call_setup_ind (vdbPtr=0x831721D8, callInfo=
        {called=53103,called_oct3=0x80,calling=408,calling_oct3=0x0,
        calling_oct3a=0x83, calling_xlated=false,subscriber_type_str=RegularLine,
        fdest=1,peer_tag=3, prog_ind=0},callID=0x83349DF8)
*Mar  1 04:51:11.884: cc_API_call_setup_ind type 13 , prot 0
*Mar  1 04:51:11.888: cc_process_call_setup_ind (event=0x83149130)
*Mar  1 04:51:11.888: >>>>CCAPI handed cid 41 with tag 3 to app "DEFAULT"

!--- POTS dial-peer 3 was matched inbound


*Mar  1 04:51:11.888: sess_appl: ev(24=CC_EV_CALL_SETUP_IND), cid(41), disp(0)
*Mar  1 04:51:11.888: sess_appl: ev(SSA_EV_CALL_SETUP_IND), cid(41), disp(0)
*Mar  1 04:51:11.888: ssaCallSetupInd 
*Mar  1 04:51:11.892: ccCallSetContext (callID=0x29, context=0x83303C00)

!--- The POTS leg is created and assigned a callid of 0x29


*Mar  1 04:51:11.892: ssaCallSetupInd cid(41), st(SSA_CS_MAPPING),oldst(0), 
      ev(24)ev->e.evCallSetupInd.nCallInfo.finalDestFlag = 1
*Mar  1 04:51:11.892: ssaCallSetupInd finalDest cllng(408), clled(53103)

!--- Due to the direct-inward-dial config under dial-peer 3, the DNIS sent in !--- the setup request is considered sufficient to match an outbound dial-peer. !--- This is clear with flag set to 1. 


*Mar  1 04:51:11.892: ssaCallSetupInd cid(41), st(SSA_CS_CALL_SETTING),oldst(0),
      ev(24)dpMatchPeersMoreArg result= 0
*Mar  1 04:51:11.892: ssaSetupPeer cid(41) peer list:  tag(5) called number (53103) 

!--- Dial-peer table lists only dial-peer 5 as matched outbound against the DNIS.


*Mar  1 04:51:11.892: ssaSetupPeer cid(41), destPat(53103), matched(2), 
      prefix(), peer(83369DB8), peer->encapType (2)

!--- Due to destination-pattern having 2 digits and 3 dots, explicit match is !--- reported as 2.


*Mar  1 04:51:11.896: ccCallProceeding (callID=0x29, prog_ind=0x0)
*Mar  1 04:51:11.896: ccCallSetupRequest (Inbound call = 0x29, outbound peer =5,
      dest=, params=0x831578C0 mode=0, *callID=0x83157C28, prog_ind = 0)
*Mar  1 04:51:11.896: ccCallSetupRequest numbering_type 0x80
*Mar  1 04:51:11.896: dest pattern 53..., called 53103, digit_strip 0
*Mar  1 04:51:11.896: callingNumber=408, calledNumber=53103, redirectNumber=
      display_info= calling_oct3a=83

!--- Just before matching an outbound dial-peer, we remember that we have !--- seen the same ANI and DNIS in the ISDN setup and in the ccapi debug initially. !--- In other words, the router did not collect additional digits after the seizure. !--- Equal value of DNIS at setup request and before matching an outbound !--- dial-peer is the whole purpose of DID


*Mar  1 04:51:11.896: accountNumber=, finalDestFlag=1,
      guid=c66d.980c.17a8.0051.0000.0000.010a.998a
*Mar  1 04:51:11.896: peer_tag=5
*Mar  1 04:51:11.896: ccIFCallSetupRequestPrivate: (vdbPtr=0x824C6344, dest=, 
      callParams={called=53103,called_oct3=0x80, calling=408,calling_oct3=0x0, 
      calling_xlated=false,subscriber_type_str=RegularLine, fdest=1,
      voice_peer_tag=5},mode=0x0) vdbPtr type = 3
*Mar  1 04:51:11.900: ccIFCallSetupRequestPrivate: (vdbPtr=0x824C6344, dest=,
      callParams={called=53103, called_oct3 0x80,  calling=408,calling_oct3 0x0, 
      calling_xlated=false,  fdest=1, voice_peer_tag=5}, mode=0x0, xltrc=-5)
*Mar  1 04:51:11.900: ccSaveDialpeerTag (callID=0x29, dialpeer_tag=
*Mar  1 04:51:11.900: ccCallSetContext (callID=0x2A, context=0x8330408C)
*Mar  1 04:51:11.900: ccCallReportDigits (callID=0x29, enable=0x0)
*Mar  1 04:51:11.904: cc_API_call_report_digits_done (vdbPtr=0x831721D8,
      callID=0x29, disp=0)
*Mar  1 04:51:11.904: sess_appl: ev(52=CC_EV_CALL_REPORT_DIGITS_DONE),
      cid(41), disp(0)
*Mar  1 04:51:11.904: cid(41)st(SSA_CS_CALL_SETTING)ev
      (SSA_EV_CALL_REPORT_DIGITS_DONE)
oldst(SSA_CS_MAPPING)cfid(-1)csize(0)in(1)fDest(1)
.

!--- Output Omitted

.

!--- The following output displays the Call is finished


*Mar  1 04:51:52.442: ISDN Se1/0:23: RX <-  DISCONNECT pd = 8  callref = 0x0001
*Mar  1 04:51:52.442:         Cause i = 0x8290 - Normal call clearing
*Mar  1 04:51:52.458: ISDN Se1/0:23: TX ->  RELEASE pd = 8  callref = 0x8001
*Mar  1 04:51:52.458: cc_API_call_disconnected(vdbPtr=0x831721D8, callID=0x29,
      cause=0x10)
*Mar  1 04:51:52.462: sess_appl: ev(11=CC_EV_CALL_DISCONNECTED), cid(41), disp(0)
*Mar  1 04:51:52.462: cid(41)st(SSA_CS_ACTIVE)ev(SSA_EV_CALL_DISCONNECTED)
      oldst(SSA_CS_ACTIVE)cfid(9)csize(2)in(1)fDest(1)
*Mar  1 04:51:52.462: -cid2(42)st2(SSA_CS_ACTIVE)oldst2(SSA_CS_ALERT_RCVD)
*Mar  1 04:51:52.462: ssa: Disconnected cid(41) state(5) cause(0x10)
*Mar  1 04:51:52.462: ccConferenceDestroy (confID=0x9, tag=0x0)
*Mar  1 04:51:52.462: cc_API_bridge_drop_done (confID=0x9, srcIF=0x824C6344, 
      srcCallID=0x2A, dstCallID=0x29, disposition=0 tag=0x0)
*Mar  1 04:51:52.466: cc_API_bridge_drop_done (confID=0x9, srcIF=0x831721D8, 
      srcCallID=0x29, dstCallID=0x2A, disposition=0 tag=0x0)
*Mar  1 04:51:52.466: sess_appl: ev(30=CC_EV_CONF_DESTROY_DONE), cid(41), disp(0)
*Mar  1 04:51:52.470: cid(41)st(SSA_CS_CONF_DESTROYING)ev(SSA_EV_CONF_DESTROY_DONE)
      oldst(SSA_CS_ACTIVE)cfid(-1)csize(2)in(1)fDest(1)
*Mar  1 04:51:52.470: -cid2(42)st2(SSA_CS_CONF_DESTROYING)oldst2(SSA_CS_ALERT_RCVD)
*Mar  1 04:51:52.470: ssaConfDestroyDone 
*Mar  1 04:51:52.470: ccCallDisconnect (callID=0x29, cause=0x10 tag=0x0)
*Mar  1 04:51:52.470: ccCallDisconnect (callID=0x2A, cause=0x10 tag=0x0)


!--- These two lines are great for finding the source of the disconnect. !--- They tell us that the first call leg with callid 0x29 (POTS call leg) !--- disconnected with cause code 0x10. So either the end POTS user hung up or the !--- telephony equipment disconnected unintentionally. From the router's point of !--- view, both are the same.


*Mar  1 04:51:52.470: ISDN Se1/0:23: RX <-  RELEASE_COMP pd = 8  callref = 0x0001
*Mar  1 04:51:52.499: cc_API_call_disconnect_done(vdbPtr=0x831721D8, callID=0x29,
      disp=0, tag=0x0)


!--- Debug truncated here
 


2600#show call active voice brief 

!--- This show command is good to verify which are the dial-peers matched by the !--- call. In the example below, the output show the POTS call-leg matched !--- dial-peer voice 3 pots (pid:3) the VoIP call-leg matched !--- dial-peer voice 5 voip (pid:5). !--- some output omitted


Total call-legs: 2
3A   : 799622hs.1 +112 pid:3 Answer 408 active
 dur 00:00:07 tx:385/61600 rx:160/23690
 Tele 1/0:23:33: TX:7730/3060/0ms g711ulaw noise:-42 acom:0  i/0:-43/-53 dBm

3A   : 799625hs.1 +106 pid:5 Originate 53103 active
 dur 00:00:07 TX:160/23690 rx:385/61600
 IP 171.68.168.250:25704 rtt:0ms pl:4980/0ms lost:0/0/0 delay:64/64/65ms g711ulaw