Direct-Inward-Dial (DID) auf digitalen IOS-Voice-Schnittstellen (T1/E1)

Einführung

Dieser technische Hinweis gilt für Cisco IOS-sprachfähige Router/Gateways mit digitalen Schnittstellen (T1/E1). Weitere Informationen zu Cisco Digital 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 (Sofort-, Wink-, Delay-Schnittstellen) standardmäßig aktiviert. Konfigurieren Sie daher nicht den Direktwahlbefehl für eingehende Anrufe. Auf den Cisco AS5300-Plattformen wird DID auf Schnittstellen, die für die direkte E- und M-Signalisierung konfiguriert sind, nicht unterstützt.

Voraussetzungen

Anforderungen

Für dieses Dokument bestehen keine speziellen Anforderungen.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie in den Cisco Technical Tips Conventions.

Hintergrundinformationen

DID ist ein von Telefongesellschaften angebotener Dienst, der es Anrufern ermöglicht, sich ohne Unterstützung eines Telefonanbieters oder einer automatischen Anrufvermittlung direkt an eine Durchwahl einer Telefonanlage (PBX) oder eines Telefonanlage anzuwählen. Bei diesem Service werden DID-Trunks verwendet, bei denen nur die letzten drei bis fünf Ziffern einer Telefonnummer an das PBX-System oder den Router bzw. das Gateway weitergeleitet werden. Wenn ein Unternehmen beispielsweise über die Telefondurchwahlen 555-1000 bis 555-1999 verfügt und ein Anrufer 555-1234 wählt, leitet die lokale Zentrale (CO) 234 an das PBX- oder Paket-Sprachsystem weiter. Das PBX- oder Paket-Sprachsystem (Cisco CallManager und IOS-Router/Gateway) klingelt dann die Durchwahl 234. Dieser gesamte Prozess ist für den Anrufer transparent.

In diesem Dokument werden zwei Arten von DFÜ-Peers wie folgt behandelt:

• Plain Old Telefone Service (POTS) - Dies ist ein herkömmlicher Telefonanruf, der über das öffentliche Telefonnetz (Public Switched Telefone Network, PSTN) getätigt wird und über den während des Anrufs eine dedizierte 64K-Leitung End-to-End-Anrufverbindung erhält. POTS-DFÜ-Peers verweisen immer auf einen Sprach-Port am Router

• Voice-Network - Ein Sprachanruf über das Datennetzwerk besteht aus mehreren Anrufabschnitten. Jeder Anrufabschnitt verläuft entweder zwischen Datengeräten (Routern/Gateways) oder zwischen Daten- und Telefoniegeräten (z. B. einem Router zu einem PBX). Voice-Network-Dial-Peers weisen je nach verwendeter Netzwerktechnologie auf unterschiedliche Ziele hin. Zu den Voice-Network-DFÜ-Peers gehören:

  • Voice over IP (VoIP)

  • Voice over Frame Relay (VoFR)

  • Voice over ATM (VoATM)

  • Multimedia Mail over IP (MMoIP)

Wenn ein Sprachanruf beim Cisco IOS-Router/Gateway eingeht, wird der Sprach-Port des Routers eingehend von einem PBX- oder CO-Switch belegt. Der Router/Gateway gibt dem Anrufer dann einen Wählton aus und erfasst Ziffern, bis er einen ausgehenden DFÜ-Peer identifizieren kann. Egal, ob die Ziffern in unregelmäßigen Abständen von Menschen oder in regelmäßigen Abständen von Telefoniegeräten gewählt werden, die die vorab gesammelten Ziffern senden, die DFÜ-Peer-Zuordnung erfolgt für jede Ziffer. Dies bedeutet, dass der Router/Gateway versucht, einen DFÜ-Peer nach Erhalt jeder Ziffer zuzuordnen. Dieser Vorgang wird als Zweistufiges Wählen bezeichnet.

Wenn der PBX- oder CO-Switch jedoch eine Einrichtungsmeldung sendet, die "alle" Ziffern enthält, die für die vollständige Weiterleitung des Anrufs erforderlich sind, können diese Ziffern direkt einem ausgehenden Voice-Netzwerk-Dial-Peer zugeordnet werden. Bei DID gibt der Router/Gateway dem Anrufer keinen Wählton aus und sammelt keine Ziffern. Der Anruf wird direkt an das konfigurierte Ziel weitergeleitet. Dies wird als Einstufen-Wählen bezeichnet.

Die Ziffern, die für die Weiterleitung der Anrufe, die wir in den obigen Absätzen erörtert haben, erforderlich sind, sind in zwei Kategorien unterteilt:

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

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

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

Wenn ein eingehender Anruf von einer POTS-Schnittstelle (Plain Old Telefone Service) empfangen wird, ermöglicht die DID-Funktion in DFÜ-Peers dem Router/Gateway, die angerufene Nummer (DNIS) zu verwenden, um direkt mit einem DFÜ-Peer für ausgehende Anrufe zu übereinstimmen. Wenn die DID auf dem eingehenden POTS-DFÜ-Peer konfiguriert wird, wird die angerufene Nummer automatisch verwendet, um dem Zielmuster für den ausgehenden Anrufabschnitt zu entsprechen.

Um einen POTS-DFÜ-Peer für die 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 Eingangs-POTS-DFÜ-Peers für DID

Damit die DID ordnungsgemäß funktioniert, müssen Sie sicherstellen, dass der eingehende Anruf mit dem richtigen POTS-DFÜ-Peer übereinstimmt, für den der Befehl Direct-Inward-Dial konfiguriert ist. Um dem richtigen DFÜ-Peer für eingehende Anrufe zu entsprechen, empfehlen wir die Verwendung des eingehenden DFÜ-Peer-Befehls "incoming called-number dnis_string" unter dem DID-POTS-DFÜ-Peer.

Weitere Befehle zum Abgleichen von DFÜ-Peers sind: response-address ani_string, destination-pattern string oder port voice-port . Der Vorteil des Befehls für eingehende angerufene Anrufe besteht darin, dass jeder Anruf mit DNIS-Informationen (angerufene Nummer) verknüpft ist und über die Priorität der vorherigen Befehle verfügt.

Wenn Sie den Befehl incoming called-number (eingehende angerufene Nummer) nicht verwenden, um dem eingehenden DFÜ-Peer zu entsprechen, sollten Sie Folgendes berücksichtigen:

• Wenn Sie die ANI-Informationen zur Übereinstimmung mit dem DID POTS-DFÜ-Peer verwenden, stellen Sie sicher, dass die Antwort-Adresse des Befehls korrekt konfiguriert ist und der Telco-Switch die ANI-Informationen bereitstellt. Einige ISDN-Anbieter und die meisten T1-Channel Associated Signaling (CAS), mit Ausnahme der Funktionsgruppe 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-DFÜ-Peer konfiguriert wurde (für ausgehende Anrufe). 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 einem eingehenden POTS-Dial-Peer zugeordnet wird, der auf eingehender angerufener Nummer oder Antwortadresse oder Zielmuster oder Port basiert, wird der standardmäßige 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. ACME Company verfügt über T1-PRI-Leitungen mit 40 DID-Trunks im Bereich von 555-3100 bis 555-3139. Ziel ist es, die ersten 20 Leitungen Cisco IP-Telefonen zuzuweisen. Die letzten 20 Leitungen stehen für Tests und zukünftige Erweiterungen zur Verfügung. Derzeit gibt der Router nur Wähltöne aus. Wenn der CO-Switch nur die letzten fünf Stellen in der ISDN-Einrichtungsnachricht sendet, können die oben genannten Informationen in der folgenden Tabelle zusammengefasst werden.

PSTN-Benutzer wählen	Vom Switch an Voice Router/Gateway gesendete Ziffern	Verwenden	Anzahl Trunks
555-3100 bis 555-3119	53100-53119	DID-Leitungen für IP-Telefone	20
555-3120 bis 555-3139	53120-53139	Tests und zukünftige Erweiterung	20

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 in der Ausgabe des Debug-Befehls isdn q931 unterschiedliche Formate als der Inout-Befehl debug voip ccapi.

• Informationen zur Interpretation der Q.931-Anruftrennungs-Ursachencodes vom Debuggen von voip ccapi finden Sie unter: Fehlerbehebung und Debuggen von VoIP-Anrufen - Grundlagen

• Informationen zur Interpretation der Q.931-Anruftrennungs-Ursachencodes von debug isdn q931 finden Sie unter: Verständnis der Debug-ISDN q931-Trennungsursachencodes

Die Q.931-Ereignisursachencodes im Dezimalformat finden Sie unter: ISDN-Ereignisursachencodes

Im Folgenden sind einige Beispiele für Symptome aufgeführt, die zu Problemen führen können:

• Symptom: Router/Gateway bietet Wählton und wartet, bis der Interdigit-Timer das Zeitlimit überschreitet. Anschließend wird die Verbindung mit dem debug voip ccapi Inout-Ursachencode = 0x1C (ungültiges Zahlenformat) oder debug isdn q931 (für ISDN-Schnittstellen) getrennt Ursachencode = 0x809C (ungültiges Zahlenformat).

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

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

  • Problem: DID ist konfiguriert, und der richtige eingehende POTS-DFÜ-Peer wird auf dem Cisco IOS-Router/Gateway zugeordnet. Die Setup-Nachricht enthält jedoch keine Anrufnummer (DNIS). Überprüfen Sie in diesem Fall mit der telco, ob der Trunk für DID bereitgestellt wird.

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

  • Problem: Die DID wird auf dem Cisco IOS-Router/Gateway konfiguriert und zugeordnet. Es gibt jedoch keine Übereinstimmung für ausgehenden DFÜ-Peer auf dem Router/Gateway.

  • Problem: Vergewissern Sie sich, dass der eingehende Anruf mit dem richtigen POTS-DFÜ-Peer übereinstimmt, für den der Befehl Direct-Inward-Dial konfiguriert ist. Weitere Informationen finden Sie im Abschnitt Matching the Matching the Correct Inbound POTS Dial Peer for DID (Richtige eingehende POTS-DFÜ-Peer für DID) in diesem Dokument.

Beispielausgabe und Debugausgabe

Hinweis: Einige der folgenden Zeilen in der Debugausgabe 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

Zugehörige Informationen

• Informationen zu DFÜ-Peers und Anruflisten auf Cisco IOS-Plattformen
• Eingehende und ausgehende DFÜ-Peers auf Cisco IOS-Plattformen
• ISDN-Switch-Typen, -Codes und -Werte
• Konfigurieren von Wählplänen, DFÜ-Peers und Nummernänderung
• Konfigurieren von Voice over IP für die Cisco Serie 3600
• 2-Port Direct Inward Dial (2 DID) Voice Interface Cards
• Technischer Support - Cisco Systems