Direct-Inward-Dial (DID) begrijpen op digitale spraakinterfaces van iOS (T1/E1)

Inleiding

In dit document worden Cisco IOS®-routers/gateways met spraakfunctionaliteit en digitale interfaces (T1/E1) beschreven. Voor meer informatie over Cisco analoge Direct Inward Dialing (DID) raadpleegt u: Analoge DID voor Cisco 2600- en Cisco 3600-routers

Opmerking: Op de meeste platforms is DID standaard ingeschakeld op CAS-interfaces (immediate, wink, delay). Configureer daarom de opdracht direct-inward-dial niet voor inkomende oproepen. Op Cisco AS5300-platforms wordt DID niet ondersteund op interfaces die zijn geconfigureerd voor onmiddellijke E & M-signalering.

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt. Dit document is niet beperkt tot specifieke software- en hardware-versies.

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Achtergrondinformatie

DID is een dienst die wordt aangeboden door telefoonbedrijven waarmee bellers rechtstreeks naar een extensie kunnen bellen op een Private Branch Exchange (PBX) of pakketspraaksysteem zonder de hulp van een operator of geautomatiseerde oproepbediende. Deze service maakt gebruik van DID-trunks, die alleen de laatste drie tot vijf cijfers van een telefoonnummer doorsturen naar de PBX of router / gateway. Als een bedrijf bijvoorbeeld telefoonextensies 555-1000 tot 555-1999 heeft en een beller 555-1234 belt, zou het lokale centrale kantoor (CO) 234 doorsturen naar het PBX- of pakketspraaksysteem. Het PBX of packet voice systeem (Cisco CallManager en IOS router/gateway) zou dan de extensie 234 bellen. Dit hele proces is transparant voor de beller.

In dit document bespreken we twee soorten kiescollega's als volgt:

• Plain old phone service (POTS) - Dit is een traditioneel spraakoproep geplaatst via het Public Switched Telephone Network (PSTN), waar u tijdens het gesprek een speciaal 64K-circuit end-to-end-oproeptraject krijgt. POTS-kiespeers wijzen altijd naar een spraakpoort op de router

• Voice-Network—Een spraakoproep via het datanetwerk bestaat uit verschillende call-legs. Elke call-leg reist tussen data-apparaten (routers/gateways) of tussen data- en telefonie-apparaten (zoals een router naar een PBX). Voice-Network-kiespeers wijzen naar verschillende bestemmingen, afhankelijk van de gebruikte netwerktechnologie. Voice-Network kiespeers omvatten het volgende:

  • Voice over IP (VoIP)

  • Voice over Frame Relay (VoFR)

  • Voice over ATM (VoATM)

  • Multimedia Mail over IP (MOIP)

Wanneer een spraakoproep binnenkomt in de Cisco IOS-router/gateway, wordt de spraakpoort op de router inbound in beslag genomen door een PBX- of CO-switch. De router / gateway presenteert vervolgens een kiestoon aan de beller en verzamelt cijfers totdat deze een uitgaande kiestoon kan identificeren. Of de cijfers nu met onregelmatige tussenpozen door mensen worden gekozen of op een regelmatige manier door telefonieapparatuur die de vooraf verzamelde cijfers verzendt, dial-peer-matching gebeurt cijfer voor cijfer. Dit betekent dat de router / gateway probeert een dial peer te matchen nadat elk cijfer is ontvangen. Dit proces wordt tweetrapskiezen genoemd.

Als de PBX- of CO-switch echter een installatiebericht verzendt met "alle" cijfers die nodig zijn om het gesprek volledig te routeren, kunnen die cijfers rechtstreeks worden toegewezen aan een uitgaande Voice-Network-inbelverbinding. Met DID toont de router/gateway geen kiestoon aan de beller en verzamelt deze geen cijfers. Het stuurt de oproep rechtstreeks door naar de geconfigureerde bestemming. Dit wordt one-stage dialing genoemd.

De cijfers die nodig zijn om de oproepen te routeren die we in de bovenstaande alinea's hebben besproken, zijn van de volgende twee typen:

• Digital Number Identification Service (DNIS) is een digitale dienst die via telco wordt aangeboden en die het opgeroepen nummer (het nummer dat wordt gebeld) levert.

• Automatic Number Identification (ANI) is een digitale dienst die via telco's wordt aangeboden en die het oproepnummer (het nummer van de oproepinitiator) levert. ANI wordt ook wel Calling Line Identification (CLID) genoemd.

DID-configuratie voor POTS Dial Peers

Wanneer u een inkomende oproep ontvangt van een POTS-interface (plain old phone service), stelt de DID-functie in dial-peers de router / gateway in staat om het opgeroepen nummer (DNIS) te gebruiken om rechtstreeks overeen te komen met een uitgaande dial-peer. Wanneer DID is geconfigureerd op de inkomende POTS-kiespeer, wordt het opgeroepen nummer automatisch gebruikt om overeen te komen met het bestemmingspatroon voor de uitgaande oproeppoot.

Voer de volgende Cisco IOS-opdrachten in om een POTS-peer voor DID te configureren, te beginnen in de globale configuratiemodus:

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

Overeenkomen van de juiste inkomende POTS-kiezer voor DID

Om DID correct te laten werken, moet u ervoor zorgen dat de inkomende oproep overeenkomt met de juiste POTS-kiezer waar de opdracht direct-naar-binnen-kiezer is geconfigureerd. Om de juiste inkomende kiespeer te matchen, raden we aan om de kiespeer-opdracht inkomend nummer genaamd dnis_string onder de DID POTS-kiespeer te gebruiken.

Andere commando's die gebruikt worden om de dial-peers te matchen zijn: answer-address ani_string , destination-pattern string of port voice-port . Het voordeel van het gebruik van de opdracht inkomend aangeroepen nummer is dat elke oproep DNIS-informatie (aangeroepen-nummer) heeft en voorrang heeft op de vorige opdrachten.

Als u de opdracht voor het binnenkomende opgeroepen nummer niet gebruikt om de inkomende kiezelpeer te matchen, overweeg dan het volgende:

• Als u ANI-informatie gebruikt om overeen te komen met de DID POTS-kiezer, moet u ervoor zorgen dat het antwoordadres van de opdracht correct is geconfigureerd en dat de telco-switch ANI-informatie verstrekt. Sommige ISDN-providers en de meeste T1-kanaalgerelateerde signalering (CAS), met uitzondering van Feature Group D (fgd), verstrekken geen ANI-informatie.

• Als het antwoordadres NIET overeenkomt met het ANI, kan het ANI overeenkomen met het bestemmingspatroon dat is geconfigureerd (voor uitgaande kiezen) onder een andere POTS-kiezer. Als het bestemmingspatroon overeenkomt met ANI, moet u ervoor zorgen dat de opdracht direct-naar-binnen-inbellen onder die inbelverbinding is geconfigureerd.

• Als de inkomende DID-oproep niet is gekoppeld aan een inkomende POTS-dial-peer op basis van een inkomend opgeroepen nummer of antwoordadres of bestemmingspatroon of poort, wordt standaard dial-peer 0 gebruikt. DID is standaard uitgeschakeld op dial-peer 0.

casestudy

Gebruik het volgende voorbeeld om bovenstaande punten te illustreren. ACME Company heeft T1 PRI-lijnen met 40 DID-stammen in het bereik van 555-3100 tot 555-3139. Het doel is om de eerste 20 lijnen toe te wijzen aan Cisco IP-telefoons. De laatste 20 lijnen zijn beschikbaar voor testen, toekomstige uitbreiding en voor nu geeft de router alleen de kiestoon. Ervan uitgaande dat de CO-switch alleen de laatste vijf cijfers in het ISDN-configuratiebericht verzendt, kunnen we de bovenstaande informatie in de volgende tabel samenvatten.

Configuratie

Opmerking: Een deel van de uitvoer in dit voorbeeld is weggelaten.

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 

Veelvoorkomende problemen

Opmerking: Verbinding verbreken oorzaakcodes hebben verschillende formaten in de uitvoer van de debug isdn q931 in tegenstelling tot de debug voip ccapi inout opdracht.

• Om de Q.931 call disconnect cause codes van debug voip capi inout te interpreteren verwijzen we naar: Problemen oplossen & Debug VoIP Calls - de basis

• Om de Q.931 call disconnect cause codes van debug isdn q931 te interpreteren verwijzen naar: Inzicht in debug isdn q931 Disconnect Cause Codes

Om de Q.931-gebeurtenisoordencodes in decimale notatie te zien, verwijzen we naar: ISDN-gebeurtenisoordencodes

Hieronder volgen enkele voorbeelden van symptomen en de problemen die ze kunnen veroorzaken:

• Symptoom: Router / gateway biedt een kiestoon en wacht tot de interdigit-timer uitvalt. Vervolgens verbreekt de verbinding met de foutopsporingscode voip ccapi inout cause code = 0x1C (ongeldig nummerformaat) of foutopsporingscode isdn q931 (voor ISDN-interfaces) verbreekt de verbinding cause code = 0x809C (ongeldig nummerformaat).

  • Probleem: DID is geconfigureerd op de telco-switch, maar niet op de Cisco IOS-router/gateway.

• Symptoom: Router/gateway verbreekt de verbinding met de debug voip ccapi inout cause code = 0x1 (niet-toegewezen / niet-toegewezen nummer) of debug isdn q931 (voor ISDN-interfaces) disconnect cause code = 0x8081 (niet-toegewezen / niet-toegewezen nummer).

  • Probleem: DID is geconfigureerd en de juiste inkomende POTS-kiespeer is gekoppeld aan de Cisco IOS-router / -gateway, maar het installatiebericht bevat geen aangeroepen nummer (DNIS). Controleer in dit geval bij de telco of de kofferbak is voorzien voor DID.

• Symptoom: Router/gateway verbreekt de verbinding met de debug voip ccapi inout cause code = 0x1 (niet-toegewezen/niet-toegewezen nummer) of debug isdn q931 (voor ISDN-interfaces) disconnect cause code = 0x8081 (niet-toegewezen/niet-toegewezen nummer).

  • Probleem: DID is geconfigureerd en gekoppeld op de Cisco IOS-router/gateway, maar er is geen uitgaande dial-peer-overeenkomst op de router/gateway.

  • Probleem: Zorg ervoor dat de inkomende oproep overeenkomt met de juiste POTS-dial-peer waar de opdracht direct-naar-binnen-dial is geconfigureerd. Raadpleeg voor meer informatie de sectie Matching the Correct Inbound POTS Dial Peer for DID van dit document

Voorbeeldweergave en foutopsporingsuitvoer

Opmerking: Sommige van de volgende debug-uitvoerlijnen zijn onderverdeeld in meerdere lijnen voor afdrukdoeleinden.

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