Informazioni su Direct-Inward-Dial (DID) sulle interfacce IOS Voice Digital (T1/E1)

Il documento è stato migrato nel flusso di lavoro di pubblicazione automatica. È stato originariamente pubblicato su https://www.cisco.com/c/en/us/support/docs/voice/digital-ccs/14072-direct-inward-dial.html.
È necessario aggiornare il documento in base alle linee guida correnti e rimuovere la nota prima di pubblicarla. Quando si pubblica il documento per l'anteprima, verificare che l'ID documento sia 14072 e che l'URL corrisponda all'URL originale presente in questo paragrafo. Se l'ID documento o l'URL non corrispondono, contattare tz-writers@cisco.com.

Introduzione

In questo documento vengono descritti i router/gateway abilitati per le chiamate vocali Cisco IOS® con interfacce digitali (T1/E1). Per ulteriori informazioni su Cisco analog Direct Inward Dialing (DID), consultare: Analog DID per router Cisco serie 2600 e 3600

Nota: nella maggior parte delle piattaforme, DID è abilitato per impostazione predefinita sulle interfacce CAS (immediate, sinuose, ritardate). Pertanto, non configurare il comando direct-inward-dial per le chiamate in arrivo. Sulle piattaforme Cisco AS5300, DID non è supportato sulle interfacce configurate per la segnalazione immediata E & M.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi. Il documento può essere consultato per tutte le versioni software o hardware.

Convenzioni

Per ulteriori informazioni sulle convenzioni usate, consultare il documento Cisco sulle convenzioni nei suggerimenti tecnici.

Premesse

DID è un servizio offerto dalle compagnie telefoniche che permette ai chiamanti di chiamare direttamente un interno su un sistema PBX (Private Branch Exchange) o packet voice senza l'assistenza di un operatore o di un operatore automatico di chiamata. Questo servizio utilizza i trunk DID, che inoltrano solo le ultime tre-cinque cifre di un numero di telefono al PBX o al router/gateway. Se, ad esempio, una società dispone di estensioni telefoniche da 555-1000 a 555-1999 e un chiamante chiama 555-1234, l'ufficio centrale locale (CO) inoltra 234 al PBX o al sistema di voce dei pacchetti. Il PBX o il packet voice system (Cisco CallManager e router/gateway IOS) richiama quindi l'estensione 234. L'intero processo è trasparente per il chiamante.

In questo documento vengono illustrati due tipi di peer di composizione:

• POTS (Plain Old Telephone Service): si tratta di una chiamata vocale tradizionale effettuata sulla PSTN (Public Switched Telephone Network), dove si riceve una chiamata end-to-end con circuito da 64 KB dedicata per tutta la durata della chiamata. I peer di composizione POTS punteranno sempre a una porta voce sul router

• Voice-Network: una chiamata vocale sulla rete di dati è costituita da diverse call-leg. Ogni call-leg può essere utilizzato sia per il trasferimento tra dispositivi di dati (router/gateway) sia per il trasferimento tra dispositivi di dati e telefonia (ad esempio, un router a un PBX). I peer della connessione di rete voce puntano a destinazioni diverse a seconda della tecnologia di rete utilizzata. I peer della connessione di rete voce includono:

  • VoIP (Voice over IP)

  • VoFR (Voice over Frame Relay)

  • VoATM (Voice over ATM)

  • MoIP (Multimedia Mail over IP)

Quando una chiamata vocale arriva al router/gateway Cisco IOS, la porta voce sul router viene bloccata in entrata da uno switch PBX o CO. Il router/gateway presenta quindi un segnale di composizione al chiamante e raccoglie le cifre finché non è in grado di identificare un dial peer in uscita. Sia che le cifre vengano chiamate a intervalli irregolari da esseri umani o in modo regolare dalle apparecchiature di telefonia che inviano le cifre pre-raccolte, la corrispondenza dial-peer viene effettuata cifra per cifra. Ciò significa che il router/gateway tenta di trovare una corrispondenza con un dial peer dopo aver ricevuto ciascuna cifra. Questo processo è denominato composizione in due fasi.

Tuttavia, se lo switch PBX o CO invia un messaggio di impostazione contenente "tutte" le cifre necessarie per instradare completamente la chiamata, tali cifre possono essere mappate direttamente a un dial-peer in uscita. Con DID, il router/gateway non presenta un segnale di composizione al chiamante e non raccoglie cifre. La chiamata viene inoltrata direttamente alla destinazione configurata. Questa modalità è denominata connessione a una fase.

Le cifre necessarie per indirizzare le chiamate discusse nei paragrafi precedenti sono dei due tipi seguenti:

• DNIS (Digital Number Identification Service) è un servizio digitale fornito dalla società di telecomunicazioni che fornisce il numero chiamato (il numero composto).

• L'ANI (Automatic Number Identification) è un servizio digitale fornito da Telco che fornisce il numero di chiamata (il numero del mittente della chiamata). L'ANI è anche noto come Calling Line Identification (CLID).

Configurazione DID per POTS Dial Peer

Quando si riceve una chiamata in entrata da un'interfaccia POTS (Plain Old Telephone Service), la funzionalità DID nei peer di composizione consente al router/gateway di utilizzare il numero chiamato (DNIS) per la corrispondenza diretta con un peer di composizione in uscita. Quando DID è configurato sul peer di composizione POTS in entrata, il numero chiamato viene utilizzato automaticamente per corrispondere al modello di destinazione per la coda di chiamata in uscita.

Per configurare un peer di connessione POTS per DID, immettere i seguenti comandi Cisco IOS a partire dalla modalità di configurazione globale:

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

Corrispondenza di POTS Dial Peer in entrata corretto per DID

Per il corretto funzionamento di DID, verificare che la chiamata in arrivo corrisponda al dial-peer POTS corretto in cui è configurato il comando direct-inward-dial. Per trovare la corrispondenza con il dial peer in ingresso corretto, si consiglia di utilizzare il comando dial peer incoming call-number dnis_string sotto il dial peer DID POTS.

Altri comandi utilizzati per individuare i peer di chiamata includono: answer-address ani_string , destination-pattern string o port voice-port . Il vantaggio di utilizzare il comando call-number in ingresso è che a ogni chiamata sono associate informazioni DNIS (call-number) e la chiamata ha la priorità sui comandi precedenti.

Se non si utilizza il comando call-number in ingresso per trovare una corrispondenza con il dial peer in ingresso, tenere presente quanto segue:

• Se si utilizzano le informazioni ANI per corrispondere al dial-peer DID POTS, verificare che l'indirizzo-risposta del comando sia configurato correttamente e che lo switch di telefonia stia fornendo le informazioni ANI. Alcuni provider ISDN e la maggior parte dei sistemi di segnalazione associati ai canali T1, ad eccezione del gruppo di funzionalità D (fgd), non forniscono informazioni ANI.

• Se l'indirizzo di risposta NON corrisponde all'ANI, l'ANI potrebbe corrispondere al modello di destinazione configurato (per la composizione in uscita) sotto un altro dial-peer POTS. Se il modello di destinazione viene confrontato con l'ANI, verificare che il comando direct-inward-dial sia configurato in quel dial-peer.

• Se la chiamata DID in ingresso non corrisponde a un dial-peer POTS in entrata basato sul numero chiamato o sull'indirizzo di risposta in entrata o sul modello di destinazione o sulla porta, verrà utilizzato il dial-peer predefinito 0. DID è disabilitato per impostazione predefinita sul dial-peer 0.

Case study

Utilizzare l'esempio seguente per illustrare i punti precedenti. La ACME Company ha linee T1 PRI con 40 DID trunk nella gamma da 555-3100 a 555-3139. L'obiettivo è assegnare le prime 20 linee ai telefoni IP Cisco. Le ultime 20 linee sono disponibili per test, future espansioni e per il momento il router può utilizzare solo la modalità dial-tone. Supponendo che lo switch CO invii solo le ultime cinque cifre del messaggio di configurazione ISDN, è possibile riepilogare le informazioni precedenti nella tabella seguente.

Composizione utenti PSTN	Cifre inviate dallo switch al router/gateway voce	Utilizzo	N. trunk
da 555-3100 a 555-3119	53100 - 53119	Righe DID per telefoni IP	20
da 555-3120 a 555-3139	53120 - 53139	Test ed espansione futura	20

Configurazione

Nota: alcuni output dell'esempio sono omessi.

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 

Problemi comuni

Nota: i codici causa di disconnessione hanno formati diversi nell'output del comando debug isdn q931 rispetto al comando debug voip capi inout.

• Per interpretare i codici causa di disconnessione delle chiamate Q.931 da debug voip capi inout, consultare: Risoluzione dei problemi e debug delle chiamate VoIP - Nozioni di base

• Per interpretare i codici causa di disconnessione della chiamata Q.931 da debug isdn q931, vedere: Informazioni sui codici causa di disconnessione debug isdn q931

Per visualizzare i codici causa evento Q.931 in formato decimale, vedere: Codici causa evento ISDN

Di seguito sono riportati alcuni esempi di sintomi e dei problemi che possono causarli:

• Sintomo: Router/gateway fornisce la composizione del segnale e attende il timeout del timer internumerico. Quindi si disconnette con il debug voip ccapi inout cause code = 0x1C (formato numero non valido) o debug isdn q931 (per interfacce ISDN) disconnect cause code = 0x809C (formato numero non valido).

  • Problema: il protocollo DID è configurato sullo switch telco ma non sul router/gateway Cisco IOS.

• Sintomo: il router/gateway si disconnette con il debug voip ccapi inout cause code = 0x1 (numero non allocato/non assegnato) o debug isdn q931 (per interfacce ISDN) cause code = 0x8081 (numero non allocato/non assegnato).

  • Problema: il protocollo DID è configurato e il dial peer POTS in entrata corretto corrisponde sul router/gateway Cisco IOS, ma il messaggio di installazione non include il numero chiamato (DNIS). In questo caso verificare con il telecomando che il trunk sia predisposto per DID.

• Sintomo: il router/gateway si disconnette con il codice della causa di debug voip capi inout = 0x1 (numero non allocato/non assegnato) o con il codice della causa di disconnessione debug isdn q931 (per interfacce ISDN) = 0x8081 (numero non allocato/non assegnato).

  • Problema: il protocollo DID è configurato e corrisponde sul router/gateway Cisco IOS, ma sul router/gateway non è presente alcuna corrispondenza dial-peer in uscita.

  • Problema: verificare che la chiamata in ingresso corrisponda al dial-peer POTS corretto in cui è configurato il comando direct-inward-dial. Per ulteriori informazioni, fare riferimento alla sezione Correttezza del comando POTS Dial Peer in entrata per DID di questo documento

Output di esempio di Mostra e debug

Nota: alcune delle seguenti righe di output di debug sono suddivise in più righe a scopo di stampa.

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