De betekenis van Direct-Inward-Dial (DID) op IOS Voice Digital (T1/E1) interfaces

Dit document is gemigreerd naar de Self-Publishing Workflow. Het werd oorspronkelijk gepubliceerd op https://www.cisco.com/c/en/us/support/docs/voice/digital-ccs/14072-direct-inward-dial.html.
Dit document moet worden bijgewerkt om aan de huidige richtsnoeren te voldoen en deze noot moet worden verwijderd voordat het wordt gepubliceerd. Wanneer u dit document publiceert in een voorbeeld, moet u ervoor zorgen dat de Document-id is 14072 en de URL overeenkomt met de oorspronkelijke URL die zich in deze alinea bevindt. Als de Document-id of URL niet overeenkomt, neemt u contact op met tz-writers@cisco.com.

Inleiding

Dit document beschrijft Cisco IOS® routers/gateways met spraakmogelijkheid met digitale interfaces (T1/E1). Voor meer informatie over Cisco analoge Direct Inward Dialing (DID) raadpleegt u: Analog DID voor Cisco 2600 en Cisco 3600 Series routers

Opmerking: Op de meeste platforms is DID standaard ingeschakeld op CAS-interfaces (direct, knipperen, vertraging). 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 signalering van E&M.

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 service die wordt aangeboden door telefoonbedrijven die bellers in staat stelt om direct te bellen naar een extensie op een Private Branch Exchange (PBX) of pakketspraaksysteem zonder de hulp van een operator of een geautomatiseerde telefoonmedewerker. Deze dienst 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 telefoons extensies 555-1000 tot 555-1999 heeft en een beller kiesnummers 555-1234, zou het lokale centrale kantoor (CO) 234 doorsturen naar het PBX of pakketspraaksysteem. Het PBX-systeem of Packet Voice System (Cisco CallManager en IOS-router/gateway) zou vervolgens extensie 234 bellen. Dit hele proces is transparant voor de beller.

In dit document bespreken we als volgt twee typen dial-peers:

• Platte oude telefoonservice (POTS) - Dit is een traditionele spraakoproep die over het openbare telefoonnetwerk (PSTN) wordt geplaatst, waar u tijdens de duur van de oproep een speciale 64K-circuit van end-to-end telefoonpoot krijgt. POTS-kiespeers wijzen altijd naar een spraakpoort op de router

• Spraak-netwerk—Een spraakoproep via het gegevensnetwerk bestaat uit meerdere aanroepbenen. Elke call-leg reist tussen data-apparaten (routers/gateways) of tussen data- en telefonieapparaten (zoals een router naar een PBX). Spraak-netwerk dial-peers wijzen naar verschillende bestemmingen afhankelijk van de gebruikte netwerktechnologie. De spraak-netwerk 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 in de Cisco IOS-router/gateway komt, wordt de spraakpoort op de router inbound door een PBX- of CO-switch ingenomen. De router/gateway stelt dan een kiestoon aan de bezoeker voor en verzamelt cijfers tot het een uitgaande kiestoon kan identificeren. Of de cijfers met onregelmatige intervallen door mensen of op een regelmatige manier door telefonieapparatuur worden gedraaid verzendend de pre-verzamelde cijfers, wijzerplaat-peer aanpassing wordt gedaan cijfer door cijfer. Dit betekent dat de router/gateway probeert een dial-peer aan te passen nadat elk cijfer is ontvangen. Dit proces wordt tweefasen-draaien genoemd.

Als de PBX- of CO-switch echter een setup-bericht verstuurt met 'alle' cijfers die nodig zijn om de oproep volledig te routeren, kunnen die cijfers rechtstreeks aan een uitgaande spraak-netwerk-dial-peer worden toegewezen. Met DID, de router/gateway geeft geen kiestoon aan de beller en verzamelt geen cijfers. Het door:sturen direct de vraag aan de gevormde bestemming. Dit heet éénstaps-bellen.

De cijfers die nodig zijn om de oproepen te leiden die we in de bovenstaande paragrafen hebben besproken, zijn van de volgende twee types:

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

• Automatic Number Identification (ANI) is een digitale dienst die via telco wordt geleverd en het oproepnummer (het nummer van de oproepmaker) aflevert. ANI wordt ook aangeduid als CLID (Calling Line Identification).

DID-configuratie voor POTS-kiespeers

Wanneer het ontvangen van een inkomende vraag van een duidelijke oude interface van de telefoondienst (POTS), laat de DID eigenschap in wijzerplaatpeers de router/gateway toe om het geroepen aantal (DNIS) te gebruiken om een uitgaande wijzerplaatpeer direct aan te passen. Wanneer DID wordt geconfigureerd op de inkomende POTS-dial peer, wordt het aangeroepen nummer automatisch gebruikt om het bestemmingspatroon voor de uitgaande call leg aan te passen.

Om een POTS dial-peer te configureren voor DID, voert u de volgende Cisco IOS-opdrachten in die beginnen in de globale configuratiemodus:

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

Overeenkomend met de juiste inkomende POTS-dial-peers voor DID

Voor DID om correct te werken, zorg ervoor dat de inkomende oproep overeenkomt met de juiste POTS-dial-peer waar het commando direct-inward-dial is geconfigureerd. Om de juiste inkomende wijzerplaat peer aan te passen, raden we aan om de wijzerplaat peer commando inkomende aangeroepen nummer dnis_string onder de DID POTS wijzerplaat peer.

Andere opdrachten die gebruikt worden om dial-peers aan te passen zijn: antwoord-adres ani_string, bestemming-patroon string of poort spraak-poort . Het voordeel van het gebruik van de inkomende call-number-opdracht is dat elke oproep DNIS-informatie (aangeroepen nummer) heeft gekoppeld en prioriteit heeft ten opzichte van de vorige opdrachten.

Als u niet de inkomende call-number-opdracht gebruikt om de inkomende dial-peer aan te passen, overweeg dan het volgende:

• Als het gebruiken van ANI informatie om de DID POTS wijzerplaat-peer aan te passen, zorg ervoor dat het bevel antwoord-adres correct wordt gevormd en de telco-switch ANI informatie verstrekt. Sommige ISDN-providers en de meeste T1-kanaalgekoppelde signalering (CAS), behalve functiegroep D (fgd), bieden geen ANI-informatie.

• Als het antwoord-adres NIET tegen ANI wordt aangepast, dan kan ANI het bestemming-patroon aanpassen dat (voor uitgaand draaien) onder een andere POTS wijzerplaat-peer wordt gevormd. Als het bestemmingspatroon tegen ANI wordt aangepast, zorg ervoor dat het bevel direct-binnenwaarts-wijzerplaat onder die wijzerplaat-peer wordt gevormd.

• Als de inkomende DID-oproep niet is gekoppeld aan een inkomende POTS-dial-peer op basis van inkomende aangeroepen nummers of antwoordadressen of bestemmingspatronen of poorten, wordt de standaard-dial-peer 0 gebruikt. DID is standaard uitgeschakeld op dial-peer 0.

Casestudy

Gebruik het volgende voorbeeld om de bovenstaande punten te illustreren. ACME Company heeft T1 PRI-lijnen met 40 DID-trunks 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 het testen, toekomstige uitbreiding en voor nu geeft de router alleen kiestoon. Als we ervan uitgaan dat de CO-switch alleen de laatste vijf cijfers in het ISDN-instelbericht verstuurt, kunnen we de bovenstaande informatie in de volgende tabel samenvatten.

PSTN-gebruikers bellen	Cijfers die per Switch naar spraakrouter/gateway worden gestuurd	Gebruik	# trunks
555-3100 tot 555-3119	53100 - 53119	DID-lijnen voor IP-telefoons	20
555-3120 tot en met 555-3139	53120 - 53139	Testen en toekomstige uitbreiding	20

Configuratie

N.B.: Een deel van de uitvoer in dit voorbeeld wordt 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: losmaken oorzaakcodes hebben verschillende formaten in de uitvoer van de debug ISDN q931 in tegenstelling tot de debug voip capi inout opdracht.

• Om de Q.931-oproep te interpreteren loskoppelen oorzaakcodes van debug voip capi inout verwijzen naar: Probleemoplossing en debug VoIP-oproepen - de Basics

• Om de Q.931-oproep te interpreteren loskoppelt oorzaakcodes van debug ISDN q931 verwijzen naar: Begrijpen debug ISDN q931 losmaken oorzaakcodes

Raadpleeg de oorzaakcodes voor de Q.931-gebeurtenis in decimale indeling: ISDN-oorzaakcodes

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

• Symptoom: de router/gateway biedt kiestoon en wacht tot de timer met interdigits is uitgeschakeld. Vervolgens wordt de verbinding verbroken met de debug voip capi inout cause code = 0x1C (ongeldig nummerformaat) of debug ISDN q931 (voor ISDN interfaces) loskoppelen oorzaak code = 0x809C (ongeldig nummerformaat).

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

• Symptoom: De router/gateway maakt met debug de code van de voip capi inout oorzaak = 0x1 (niet toegewezen/niet toegewezen aantal) los of debug ISDN q931 (voor ISDN interfaces) losmaakt oorzaakcode = 0x8081 (niet toegewezen/niet toegewezen aantal).

  • Probleem: DID is ingesteld en de juiste inkomende POTS-dial-peer wordt afgestemd op de Cisco IOS-router/gateway, maar het installatiebericht bevat geen aangeroepen nummer (DNIS). In dit geval, controleer met de telco dat de boomstam voor DID provisioned is.

• Symptoom: De router/gateway maakt met debug de code van de vip capiinout = 0x1 (niet toegewezen/niet toegewezen aantal) los of debug ISDN q931 (voor ISDN interfaces) losmaakt oorzaakcode = 0x8081 (niet toegewezen/niet toegewezen aantal).

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

  • Probleem: Zorg ervoor dat de inkomende oproep overeenkomt met de juiste POTS-dial-peer waar de opdracht direct-inward-dial is geconfigureerd. Voor meer informatie raadpleegt u de sectie Correcte inkomende POTS-dial-peers voor DID-sectie van dit document

Voorbeeld tonen en debug uitvoer

N.B.: Enkele van de volgende debug-uitvoerlijnen zijn voor afdrukdoeleinden in meerdere regels verdeeld.

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