DID (Direct-Inward-Dial) an IOS-Sprachschnittstellen (T1/E1)

Einleitung

In diesem Dokument werden sprachfähige Cisco IOS® Router/Gateways mit digitalen Schnittstellen (T1/E1) beschrieben. Weitere Informationen zu Cisco Analog Direct Inward Dialing (DID) finden Sie unter: Analoge DID für Cisco Router der Serien 2600 und 3600

Hinweis: Auf den meisten Plattformen ist DID auf CAS-Schnittstellen (Immediate, Wink, Delay) standardmäßig aktiviert. Konfigurieren Sie daher nicht den Befehl direct-inward-dial (Direktwahl bei eingehenden Anrufen). Auf Cisco AS5300-Plattformen wird DID nicht auf Schnittstellen unterstützt, die für die sofortige E/M-Signalisierung konfiguriert sind.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen. Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

Hintergrundinformationen

DID ist ein von Telefongesellschaften angebotener Dienst, mit dem Anrufer ohne Unterstützung eines Betreibers oder einer automatischen Anrufvermittlung direkt eine Durchwahl in einer Nebenstellenanlage oder einem Paket-Sprachsystem anrufen können. Dieser Service nutzt DID-Trunks, die nur die letzten drei bis fünf Ziffern einer Telefonnummer an das PBX-System oder den Router/das Gateway weiterleiten. Wenn ein Unternehmen beispielsweise über die Durchwahlen 555-1000 bis 555-1999 verfügt und ein Anrufer die 555-1234 wählt, leitet die lokale Zentrale 234 an die Telefonanlage oder das Paket-Sprachsystem weiter. Das PBX- oder Paket-Sprachsystem (Cisco CallManager und IOS-Router/-Gateway) klingelt dann bei Durchwahl 234. Dieser gesamte Prozess ist für den Anrufer transparent.

In diesem Dokument werden zwei Arten von DFÜ-Peers erläutert:

• Plain old telephone service (POTS) (Nur alter Telefondienst): Dies ist ein herkömmlicher Sprachanruf, der über das öffentliche Telefonnetz (PSTN) geführt wird, wo Sie während der Dauer des Anrufs einen dedizierten 64K-Leitung erhalten. POTS-Dial-Peers verweisen immer auf einen Sprach-Port am Router

• Sprachnetzwerk: Ein Sprachanruf über das Datennetzwerk besteht aus mehreren Anrufabschnitten. Jede Anrufstrecke verläuft entweder zwischen Datengeräten (Routern/Gateways) oder zwischen Daten- und Telefoniegeräten (z. B. einem Router zu einer Telefonanlage). Sprachnetzwerk-DFÜ-Peers verweisen je nach verwendeter Netzwerktechnologie auf verschiedene Ziele. Zu den DFÜ-Peers im Sprachnetzwerk gehören die folgenden:

  • Voice over IP (VoIP)

  • Voice over Frame Relay (VoFR)

  • Voice over ATM (VoATM)

  • Multimedia-Mail-over-IP (MoIP)

Wenn ein Sprachanruf beim Cisco IOS-Router/-Gateway eingeht, wird der Sprach-Port des Routers eingehend von einem PBX- oder CO-Switch erfasst. Der Router bzw. das Gateway übermittelt dem Anrufer dann einen Wählton und sammelt Nummern, bis er einen ausgehenden DFÜ-Peer identifizieren kann. Unabhängig davon, ob die Ziffern von Menschen in unregelmäßigen Abständen gewählt werden oder ob die Telefonanlagen die vorab gesammelten Ziffern regelmäßig senden, wird der Dial-Peer-Abgleich stellig durchgeführt. Das bedeutet, dass der Router/das Gateway nach dem Empfang jeder Ziffer versucht, eine Übereinstimmung mit einem DFÜ-Peer herzustellen. Dieser Vorgang wird als zweistufiges Wählen bezeichnet.

Wenn das PBX-System oder der CO-Switch jedoch eine Einrichtungsnachricht senden, die "alle" Ziffern enthält, die für die vollständige Weiterleitung des Anrufs erforderlich sind, können diese Ziffern direkt einem ausgehenden DFÜ-Peer des Sprachnetzwerks zugeordnet werden. Bei DID gibt der Router/das Gateway dem Anrufer keinen Wählton vor und sammelt keine Ziffern. Er leitet den Anruf direkt an das konfigurierte Ziel weiter. Dies wird als einstufiges Wählen bezeichnet.

Die Ziffern, die zur Weiterleitung der oben beschriebenen Anrufe erforderlich sind, gehören zu den beiden folgenden Typen:

• Der Digital Number Identification Service (DNIS) ist ein digitaler Telco-Service, der die angerufene Nummer (die gewählte Nummer) bereitstellt.

• Automatic Number Identification (ANI) ist ein digitaler Telco-Dienst, der die Anrufernummer (die Nummer des Anruferstellers) bereitstellt. ANI wird auch als Calling Line Identification (CLID) bezeichnet.

DID-Konfiguration für POTS-DFÜ-Peers

Wenn ein eingehender Anruf von einer Schnittstelle mit herkömmlichem Telefondienst (POTS) empfangen wird, ermöglicht die DID-Funktion in DFÜ-Peers dem Router/Gateway, die angerufene Nummer (DNIS) zu verwenden, um einen ausgehenden DFÜ-Peer direkt abzugleichen. Wenn DID für den eingehenden POTS-DFÜ-Peer konfiguriert ist, wird die angerufene Nummer automatisch verwendet, um das Zielmuster für den ausgehenden Anrufabschnitt abzugleichen.

Um einen POTS-DFÜ-Peer für DID zu konfigurieren, geben Sie die folgenden Cisco IOS-Befehle ein, die im globalen Konfigurationsmodus beginnen:

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

Zuordnen des richtigen DFÜ-Peers für eingehende POTS für DID

Damit DID richtig funktioniert, stellen Sie sicher, dass der eingehende Anruf mit dem richtigen POTS-DFÜ-Peer übereinstimmt, für den der Befehl direct-inward-dial konfiguriert ist. Um den richtigen eingehenden DFÜ-Peer zu ermitteln, empfehlen wir die Verwendung des Befehls dial peer, incoming called-number dnis_string unter dem DID POTS-DFÜ-Peer.

Weitere Befehle zum Abgleichen von DFÜ-Peers: answer-address ani_string , destination-pattern string oder port voice-port . Der Vorteil der Verwendung des eingehenden Befehls called-number besteht darin, dass jedem Anruf DNIS-Informationen (called-number) zugeordnet sind und er gegenüber den vorherigen Befehlen Priorität hat.

Wenn Sie den Befehl "incoming called-number" nicht verwenden, um eine Übereinstimmung mit dem Peer für eingehende Anrufe herzustellen, berücksichtigen Sie Folgendes:

• Wenn die ANI-Informationen mit dem DID-POTS-Dial-Peer übereinstimmen, stellen Sie sicher, dass der Befehl answer-address richtig konfiguriert ist und der Telco-Switch ANI-Informationen bereitstellt. Einige ISDN-Anbieter und die meisten T1 Channel Associated Signaling (CAS), mit Ausnahme von Feature Group D (fgd), stellen keine ANI-Informationen bereit.

• Wenn die Antwortadresse NICHT mit der ANI abgeglichen wird, stimmt die ANI möglicherweise mit dem Zielmuster überein, das unter einem anderen POTS-Dial-Peer (für ausgehende Anrufe) konfiguriert wurde. Wenn das Zielmuster mit der ANI abgeglichen wird, stellen Sie sicher, dass der Befehl direct-inward-dial unter diesem Dial-Peer konfiguriert ist.

• Wenn der eingehende DID-Anruf nicht mit einem eingehenden POTS-Dial-Peer auf Basis der eingehenden angerufenen Nummer oder Antwortadresse oder Zielmuster oder Port übereinstimmt, wird der Standard-Dial-Peer 0 verwendet. DID ist auf Dial-Peer 0 standardmäßig deaktiviert.

Anwenderbericht

Verwenden Sie das folgende Beispiel, um die oben genannten Punkte zu veranschaulichen. Die ACME Company verfügt über T1 PRI-Leitungen mit 40 DID-Hauptleitungen im Bereich von 555-3100 bis 555-3139. Ziel ist es, die ersten 20 Leitungen zu Cisco IP-Telefonen zuzuweisen. Die letzten 20 Leitungen stehen zum Testen und für zukünftige Erweiterungen zur Verfügung. Derzeit bietet der Router nur Wähltöne an. Wenn der CO-Switch nur die letzten fünf Ziffern der ISDN-Einrichtungsnachricht sendet, können wir die obigen Informationen in der folgenden Tabelle zusammenfassen.

Konfiguration

Hinweis: Ein Teil der Ausgabe in diesem Beispiel wird weggelassen.

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 

Häufige Probleme

Hinweis: Trennungsursachencodes haben unterschiedliche Formate in der Ausgabe des debug isdn q931 im Gegensatz zum Befehl debug voip ccapi inout.

• Um die Q.931-Anrufabtrennungsursachencodes vom debug voip ccapi inout zu interpretieren, lesen Sie: Fehlerbehebung und Fehlerbehebung bei VoIP-Anrufen - Grundlagen

• Informationen zur Interpretation der Q.931-Anrufabtrennungsursachencodes von debug isdn q931 finden Sie unter: Grundlegendes zu debug isdn q931 Ursachencodes trennen

Informationen zu den Q.931-Ereignisursachencodes im Dezimalformat finden Sie unter: ISDN-Ereignisursachencodes

Im Folgenden finden Sie einige Beispiele für Symptome und die Probleme, die diese verursachen können:

• Symptom: Router/Gateway stellt Wählton bereit und wartet, bis der Interdigit-Timer eine Zeitüberschreitung aufweist. Dann wird die Verbindung mit dem debug voip ccapi inout-Ursachencode = 0x1C (ungültiges Zahlenformat) oder debug isdn q931 (für ISDN-Schnittstellen) disconnect-Ursachencode = 0x809C (ungültiges Zahlenformat) getrennt.

  • Problem: DID wird auf dem Telekommunikations-Switch konfiguriert, jedoch nicht auf dem Cisco IOS-Router/-Gateway.

• Symptom: Router/Gateway trennt die Verbindung zum debug voip ccapi inout-Ursachencode = 0x1 (nicht zugewiesene/nicht zugewiesene Nummer) oder debug isdn q931 (für ISDN-Schnittstellen) disconnect-Ursachencode = 0x8081 (nicht zugewiesene/nicht zugewiesene Nummer).

  • Problem: DID ist konfiguriert, und der richtige eingehende POTS-DFÜ-Peer wird auf dem Cisco IOS-Router/-Gateway abgeglichen, die Setup-Nachricht enthält jedoch keine angerufene Nummer (DNIS). In diesem Fall sollten Sie sich beim Telekommunikationsanbieter vergewissern, dass der Trunk für DID bereitgestellt ist.

• Symptom: Router/Gateway trennt die Verbindung mit dem debug voip ccapi inout Cause-Code = 0x1 (nicht zugewiesene/nicht zugewiesene Nummer) oder debug isdn q931 (für ISDN-Schnittstellen) disconnect Cause-Code = 0x8081 (nicht zugewiesene/nicht zugewiesene Nummer).

  • Problem: DID wird auf dem Cisco IOS-Router/-Gateway konfiguriert und abgeglichen, es gibt jedoch keine Übereinstimmung für ausgehende Dial-Peers auf dem Router/Gateway.

  • Problem: Stellen Sie sicher, dass der eingehende Anruf mit dem richtigen POTS-Dial-Peer übereinstimmt, für den der Befehl direct-inward-dial konfiguriert ist. Weitere Informationen finden Sie im Abschnitt Matching the Correct Inbound POTS Dial Peer for DID (Zuordnen des richtigen eingehenden POTS-DFÜ-Peers für DID) in diesem Dokument.

Beispielausgabe für Anzeigen und Debuggen

Hinweis: Einige der folgenden Debug-Ausgabelinien werden zu Druckzwecken in mehrere Zeilen unterteilt.

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