Entender Direct-Inward-Dial (DID) em Interfaces (T1/E1) Digitais de Voz do IOS

Introdução

Este documento descreve os roteadores/gateways habilitados para voz Cisco IOS® com interfaces digitais (T1/E1). Para obter mais informações sobre a discagem interna direta analógica (DID, Direct Inward Dialing) da Cisco, consulte: DID analógico para roteadores das séries Cisco 2600 e Cisco 3600

Observação: na maioria das plataformas, o DID é habilitado por padrão nas interfaces CAS (immediate, wink, delay). Portanto, não configure o comando direct-inward-dial para chamadas recebidas. Nas plataformas Cisco AS5300, o DID não é suportado nas interfaces configuradas para a sinalização imediata E&M.

Pré-requisitos

Requisitos

Não existem requisitos específicos para este documento.

Componentes Utilizados

As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a rede estiver ativa, certifique-se de que você entenda o impacto potencial de qualquer comando. Este documento não se restringe a versões de software e hardware específicas.

Conventions

Para obter mais informações sobre convenções de documento, consulte as Convenções de dicas técnicas Cisco.

Informações de Apoio

DID é um serviço oferecido por companhias telefônicas que permite que os chamadores disquem diretamente para uma extensão em um PBX (Central Telefônica Privada) ou sistema de pacotes de voz sem auxílio de um operador ou de um atendimento automatizado de chamadas. Esse serviço utiliza troncos de DID, que encaminham somente os últimos três a cinco dígitos de um número de telefone para o PBX ou roteador/gateway. Se, por exemplo, uma empresa tiver ramais do 555-1000 ao 555-1999, e uma pessoa discar 555-1234, o escritório central (CO, Central Office) local encaminhará o 234 ao PBX ou ao sistema de voz de pacote. O PBX ou o sistema de voz de pacote (Cisco CallManager e roteador/gateway IOS) tocaria no ramal 234. Todo esse processo é transparente para o chamador.

Neste documento, discutimos os dois tipos de peers de discagem a seguir:

• Serviço de telefonia tradicional (POTS - Plain Old Telephone Service)—Esta é uma chamada de voz tradicional feita através da Rede de Telefonia Pública Comutada (PSTN - Public Switched Telephone Network) onde você obtém um trecho de chamada de ponta a ponta do circuito de 64K durante a duração da chamada. Os peers de discagem POTS sempre apontarão para uma porta de voz no roteador.

• Rede de voz — uma chamada de voz sobre a rede de dados é composta de diversos trechos de chamada. Cada trecho de chamada percorre um caminho entre os dispositivos de dados (roteadores/gateways) ou entre os dispositivos de dados e de telefonia (como um roteador para um PBX). Os peers de discagem da rede de voz apontam para destinos diferentes, dependendo da tecnologia de rede utilizada. Os dial peers da rede de voz incluem:

  • Voz sobre IP (VoIP, Voice over IP)

  • Voz sobre Frame Relay (VoFR, Voice over Frame Relay)

  • Voz sobre ATM (VoATM)

  • Email multimídia sobre IP (MMoIP, Multimedia Mail over IP)

Quando uma chamada de voz entrar no roteador/gateway do IOS Cisco, a porta de voz do roteador é apreendida internamente por um PBX ou switch do CO. O roteador/gateway apresenta um tom de discagem ao chamador e coleta dígitos até identificar um peer de discagem de saída. Se os dígitos forem discados com intervalos irregulares por humanos ou de uma forma regular por um equipamento telefônico enviando os dígitos pré-coletados, a correspondência do correspondente por discagem é feita dígito por dígito. Isso significa que o roteador/gateway tenta combinar um dial peer depois que cada dígito é recebido. Este processo chama-se discagem em dois estágios.

Porém, se o PBX ou o switch do CO enviar uma mensagem de configuração contendo “todos” os dígitos necessários para rotear por completo a chamada, esses dígitos poderão ser mapeados em um dial-peer da rede de voz externa diretamente. Com a DID, o roteador/gateway não apresenta um tom de discagem para o chamador e não coleta dígitos. Encaminha a chamada diretamente para o destino configurado. Isso é chamado de discagem de um estágio.

Os dígitos necessários para rotear as chamadas que foram abordadas nos parágrafos acima são dos seguintes dois tipos:

• O serviço de identificação de número digital (DNIS, Digital Number Identification Service) é um serviço digital fornecido pela telco que fornece o número chamado (o número que é discado).

• A Identificação automática de número (ANI) é um serviço digital oferecido pela empresa de telecomunicações que fornece o número chamador (o número do originador da chamada). ANI também é conhecido como CLID (Identificação de Linha de Chamada).

Configuração DID para correspondentes de discagem POTS

Durante o recebimento de uma chamada de entrada de uma interface de Serviço de Telefonia Tradicional (POTS), o recurso DID em peers de discagem habilita o roteador/gateway a usar o número chamado (DNIS) para combinar diretamente um peer de discagem de saída. Quando o DID é configurado no peer de discagem POTS de entrada, o número chamado é automaticamente usado para corresponder ao padrão de destino do trecho de chamada de saída.

Para configurar um peer discado de telefone comum para o DID, insira os seguintes comandos do Cisco IOS, iniciando no modo de configuração global.

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

Correspondendo o correspondente de discagem POTS de entrada correto por DID

Para que o DID funcione corretamente, certifique-se de que a chamada recebida corresponde ao dial-peer POTS correto em que o comando direct-inward-dial está configurado. Para corresponder o peer correto de discagem de entrada, recomendamos usar o comando de peer de discagem incoming called-number dnis_string no peer de discagem DID POTS.

Outros comandos utilizados para estabelecer correspondência com os peers de discagem incluem: answer-address ani_string , destination-pattern string ou port voice-port . A vantagem de usar o comando incoming called-number é que cada chamada possui informações DNIS associadas (called-number) e tem uma prioridade sobre os comandos anteriores.

Se você não utilizar o comando incoming called-number para corresponder ao dial peer interno, considere:

• Se utilizar as informações ANI para corresponder ao dial-peer POTS DID, certifique-se de que o comando esteja configurado corretamente e que o switch da telco esteja fornecendo as informações ANI. Alguns provedores de ISDN e a maior parte do CAS (sinalização associada de canal) T1, exceto o Grupo de Recursos D (fgd), não fornecem NENHUMA informação.

• Se o endereço de resposta NÃO coincidir com o ANI, pode ser que o ANI corresponda ao padrão de destino configurado (para discagem de saída) em outro peer de discagem POTS. Se o padrão de destino for configurado em comparação a um ANI, verifique se o comando direct-inward-dial está configurado nesse peer de discagem.

• Se a chamada DID recebida não coincidir com o peer de discagem POTS de entrada com base em incoming called-number, answer-address, destination-pattern ou port, o peer de discagem padrão 0 será usado. Por padrão, O DID é desabilitado no peer de discagem 0.

Casos Práticos

O exemplo a seguir ilustra os pontos discutidos acima. A empresa ACME tem linhas PRI T1 com 40 troncos DID no intervalo entre 555-3100 e 555-3139. O objetivo é atribuir as primeiras 20 linhas aos telefones IP da Cisco. As últimas 20 linhas estão disponíveis para teste, expansão futura e, por agora, o roteador fornece somente o tom de discagem. Supondo que switch do CO esteja enviando somente os últimos cinco dígitos na mensagem de configuração ISDN, podemos resumir as informações acima na tabela a seguir.

Configuração

Observação: parte da saída neste exemplo é omitida.

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 comuns

Observação: os códigos de causa da desconexão têm formatos diferentes na saída do comando debug isdn q931 em oposição ao comando debug voip ccapi inout.

• Para interpretar os códigos de causa da desconexão da chamada Q.931 do comando debug voip ccapi inout consulte: Identificação e solução de problemas e depuração das chamadas VoIP - Conceitos básicos

• Para interpretar os códigos de causa da desconexão da chamada Q.931 do comando debug isdn q931 consulte: Entendendo códigos de causa de desconexão debug isdn q931

Para ver os códigos de causa de evento Q.931 no formato decimal consulte: Códigos de causa de evento ISDN

A seguir estão alguns exemplos de sintomas e os problemas que podem causá-los:

• Sintoma: O roteador/gateway fornece o tom de discagem e espera até que o temporizador interdígitos expire. Em seguida, ele se desconecta com o código de causa debug voip ccapi inout = 0x1C (formato de número inválido) ou com o código de causa da desconexão debug isdn q931 (para interfaces ISDN) = 0x809C (formato de número inválido).

  • Problema: DID é configurado no switch da telco, mas não no roteador/gateway do IOS Cisco.

• Sintoma: O roteador/gateway é desconectado com o código de causa de debug voip ccapi inout = 0x1 (número não atribuído/não permitido) ou o código de causa de desconexão de debug isdn q931 (para interfaces ISDN) = 0x8081 (número não atribuído/não permitido).

  • Problema: O DID é configurado é o dial-peer POTS interno correto é combinado no roteador/gateway do IOS Cisco, mas a mensagem de configuração não inclui o número chamado (DNIS). Nesse caso, verifique com a empresa de telecomunicações se o tronco é fornecido para DID.

• Sintoma: O roteador/gateway se desconecta com o código de causa de debug voip ccapi inout = 0x1 (número não alocado/não atribuído) ou debug isdn q931 (para interfaces ISDN) código de causa de desconexão = 0x8081 (número não alocado/não atribuído).

  • Problema: O DID está configurado e correspondido no roteador/gateway Cisco IOS, mas não existe combinação de correspondente de discagem no roteador/gateway.

  • Problema: Certifique-se que a chamada recebida corresponde ao dial-peer correto POTS, em que o comando direct-inward-dial está configurado. Para obter mais informações, consulte a seção Correspondendo o peer de discagem POTS de entrada correto por DID deste documento

Exemplo de saída dos comandos show e debug

Observação: algumas das seguintes linhas de saída de depuração são divididas em várias linhas para fins de impressão.

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