Présentation du DID (Direct-Inward-Dial) dans les interfaces vocales numériques IOS (T1/E1)

Ce document a été migré vers le workflow d'auto-publication. Il a été initialement publié sur https://www.cisco.com/c/en/us/support/docs/voice/digital-ccs/14072-direct-inward-dial.html.
Ce document doit être mis à jour pour répondre aux directives actuelles et cette note doit être supprimée avant publication. Lorsque vous publiez ce document en aperçu, assurez-vous que l'ID de document est 14072 et que l'URL correspond à l'URL d'origine située dans ce paragraphe. Si l'ID ou l'URL du document ne correspond pas, contactez tz-writers@cisco.com.

Introduction

Ce document décrit les routeurs/passerelles compatibles voix Cisco IOS® avec interfaces numériques (T1/E1). Pour plus d'informations sur la numérotation analogique directe à l'arrivée (DID) de Cisco, consultez : DID analogique pour les routeurs des gammes Cisco 2600 et Cisco 3600

Remarque : sur la plupart des plates-formes, DID est activé par défaut sur les interfaces CAS (immédiates, de clin d'oeil, de délai). Par conséquent, ne configurez pas la commande direct-inward-dial pour les appels entrants. Sur les plates-formes Cisco AS5300, DID n'est pas pris en charge sur les interfaces configurées pour la signalisation immédiate E & M.

Conditions préalables

Exigences

Aucune exigence spécifique n'est associée à ce document.

Composants utilisés

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes. Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

Pour plus d'informations sur les conventions utilisées dans ce document, consultez Conventions relatives aux conseils techniques Cisco.

Informations générales

DID est un service offert par les compagnies de téléphone qui permet aux appelants de composer directement un numéro de poste sur un autocommutateur privé (PBX) ou un système de transmission de paquets vocaux sans l'aide d'un opérateur ou d'un standardiste. Ce service utilise des liaisons DID, qui transfèrent uniquement les trois à cinq derniers chiffres d'un numéro de téléphone au PBX ou au routeur/passerelle. Si, par exemple, une entreprise a des postes téléphoniques 555-1000 à 555-1999 et qu'un appelant compose le 555-1234, le central téléphonique local (CO) transfère le 234 vers le PBX ou le système vocal par paquets. Le PBX ou le système vocal par paquets (Cisco CallManager et routeur/passerelle IOS) sonne alors sur le poste 234. Tout ce processus est transparent pour l'appelant.

Dans ce document, nous abordons deux types de terminaux de numérotation dial-peer :

• Service téléphonique ordinaire (POTS) : il s'agit d'un appel vocal traditionnel passé sur le réseau téléphonique public commuté (RTPC), au cours duquel vous recevez une branche d'appel de bout en bout dédiée à un circuit 64 K pendant la durée de l'appel. Les terminaux de numérotation dial-peer POTS pointent toujours vers un port vocal sur le routeur

• Voice-Network : un appel vocal sur le réseau de données est composé de plusieurs tronçons d'appel. Chaque tronçon d'appel circule entre des périphériques de données (routeurs/passerelles) ou entre des périphériques de données et de téléphonie (tels qu'un routeur vers un PBX). Les terminaux de numérotation dial-peer Voice-Network pointent vers des destinations différentes en fonction de la technologie réseau utilisée. Les terminaux de numérotation dial-peer Voice-Network sont les suivants :

  • Voix sur IP (VoIP)

  • VoFR (Voice over Frame Relay)

  • Voix sur ATM (VoATM)

  • Multimedia Mail over IP (MMoIP)

Lorsqu'un appel vocal arrive sur le routeur/la passerelle Cisco IOS, le port vocal du routeur est saisi en entrée par un commutateur privé ou central téléphonique. Le routeur/modem routeur présente ensuite une tonalité à l'appelant et collecte les chiffres jusqu'à ce qu'il puisse identifier un terminal de numérotation dial-peer sortant. Que les chiffres soient composés à intervalles irréguliers par des êtres humains ou de manière régulière par un équipement de téléphonie envoyant les chiffres précollectés, la correspondance de terminal de numérotation dial-peer est effectuée chiffre par chiffre. Cela signifie que le routeur/la passerelle tente de faire correspondre un terminal de numérotation dial-peer après la réception de chaque chiffre. Ce processus est appelé numérotation en deux étapes.

Toutefois, si le commutateur PBX ou le commutateur CO envoie un message de configuration contenant « tous » les chiffres nécessaires pour acheminer entièrement l'appel, ces chiffres peuvent être mappés directement vers un terminal de numérotation dial-peer de réseau vocal sortant. Avec DID, le routeur/modem routeur ne présente pas de tonalité à l'appelant et ne recueille pas de chiffres. Il transfère l'appel directement vers la destination configurée. C'est ce qu'on appelle la numérotation en une étape.

Les chiffres nécessaires pour acheminer les appels dont nous avons parlé dans les paragraphes ci-dessus sont des deux types suivants :

• Le service d'identification de numéro numérique (DNIS) est un service numérique fourni par une compagnie de téléphone qui fournit le numéro appelé (le numéro composé).

• L'identification automatique de numéro (ANI) est un service numérique fourni par les opérateurs téléphoniques qui fournit le numéro appelant (numéro de l'appelant). ANI est également appelé identification de la ligne appelante (CLID).

Configuration DID pour homologues de numérotation POTS

Lors de la réception d'un appel entrant à partir d'une interface de service téléphonique traditionnel (POTS), la fonctionnalité DID des terminaux de numérotation dial-peer permet au routeur/modem routeur d'utiliser le numéro appelé (DNIS) pour correspondre directement à un terminal de numérotation dial-peer sortant. Lorsque DID est configuré sur le terminal de numérotation dial-peer POTS entrant, le numéro appelé est automatiquement utilisé pour correspondre au modèle de destination pour le tronçon d'appel sortant.

Pour configurer un terminal de numérotation dial-peer POTS pour DID, entrez les commandes Cisco IOS suivantes en commençant par le mode de configuration globale :

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

Mise en correspondance du terminal de numérotation dial-peer POTS entrant approprié pour DID

Pour que DID fonctionne correctement, assurez-vous que l'appel entrant correspond au terminal de numérotation dial-peer POTS correct où la commande direct-inward-dial est configurée. Pour faire correspondre le terminal de numérotation dial-peer entrant correct, nous vous recommandons d'utiliser la commande dial-peer incoming called-number dnis_string sous le terminal de numérotation dial-peer DID POTS.

Les autres commandes utilisées pour faire correspondre les terminaux de numérotation dial-peer sont : answer-address ani_string , destination-pattern string ou port voice-port . L'avantage de l'utilisation de la commande incoming called-number est que chaque appel a des informations DNIS associées (called-number) et qu'il a la priorité sur les commandes précédentes.

Si vous n'utilisez pas la commande incoming called-number pour correspondre au terminal de numérotation dial-peer entrant, considérez ce qui suit :

• Si vous utilisez des informations ANI pour correspondre au terminal de numérotation dial-peer DID POTS, assurez-vous que la commande answer-address est configurée correctement et que le commutateur de l'opérateur téléphonique fournit des informations ANI. Certains fournisseurs RNIS et la plupart des systèmes de signalisation associés aux canaux T1, à l’exception du groupe de fonctions D (fgd), ne fournissent pas d’informations ANI.

• Si answer-address n'est PAS mis en correspondance avec ANI, alors l'ANI peut correspondre au modèle de destination configuré (pour la numérotation sortante) sous un autre terminal de numérotation dial-peer POTS. Si le modèle de destination est mis en correspondance avec ANI, assurez-vous que la commande direct-inward-dial est configurée sous ce terminal de numérotation dial-peer.

• Si l'appel DID entrant n'est pas mis en correspondance avec un terminal de numérotation dial-peer POTS entrant basé sur le numéro appelé entrant ou l'adresse de réponse ou le modèle de destination ou le port, alors le terminal de numérotation dial-peer 0 par défaut sera utilisé. DID est désactivé par défaut sur le terminal de numérotation dial-peer 0.

Étude de cas

Utilisez l'exemple suivant pour illustrer les points ci-dessus. La société ACME dispose de lignes T1 PRI avec 40 liaisons DID comprises entre 555-3100 et 555-3139. L'objectif est d'attribuer les 20 premières lignes aux téléphones IP Cisco. Les 20 dernières lignes sont disponibles pour les tests, les extensions futures et pour l'instant, le routeur n'émet que des tonalités. En supposant que le commutateur CO envoie uniquement les cinq derniers chiffres du message de configuration RNIS, nous pouvons résumer les informations ci-dessus dans le tableau suivant.

Numérotation des utilisateurs PSTN	Chiffres envoyés par commutateur au routeur/modem routeur vocal	Utilisation	Nombre de faisceaux
555-3100 à 555-3119	53100 - 53119	Lignes DID pour téléphones IP	20
555-3120 à 555-3139	53120 - 53139	Tests et extension future	20

Configuration

Remarque : certains résultats de cet exemple sont omis.

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 

Problèmes courants

Remarque : les codes de cause de déconnexion ont des formats différents dans la sortie de la commande debug isdn q931 par opposition à la commande debug voip ccapi inout.

• Pour interpréter les codes de cause de déconnexion d'appel Q.931 à partir de debug voip ccapi inout, consultez : Dépannage et débogage des appels VoIP - Notions de base

• Pour interpréter les codes de cause de déconnexion de l'appel Q.931 à partir de debug isdn q931, consultez : Understanding debug isdn q931 Disconnect Cause Codes

Pour afficher les codes de cause d'événement Q.931 au format décimal, reportez-vous à la rubrique : Codes de cause d'événement RNIS

Voici quelques exemples de symptômes et les problèmes qui peuvent les causer :

• Symptôme : le routeur/modem routeur fournit une tonalité et attend que le minuteur inter-chiffres expire. Ensuite, il se déconnecte avec le code de cause debug voip ccapi inout = 0x1C (format de nombre non valide) ou debug isdn q931 (pour les interfaces RNIS) disconnect code de cause = 0x809C (format de nombre non valide).

  • Problème : DID est configuré sur le commutateur de l'opérateur téléphonique mais pas sur le routeur/la passerelle Cisco IOS.

• Symptôme : le routeur/la passerelle se déconnecte avec le code de cause debug voip ccapi inout = 0x1 (numéro non alloué / non attribué) ou debug isdn q931 (pour les interfaces RNIS) code de cause de déconnexion = 0x8081 (numéro non alloué / non attribué).

  • Problème : DID est configuré et le terminal de numérotation dial-peer POTS entrant correct correspond sur le routeur/la passerelle Cisco IOS, mais le message d'installation n'inclut pas le numéro appelé (DNIS). Dans ce cas, vérifiez auprès de l'opérateur téléphonique que la liaison est configurée pour DID.

• Symptôme : le routeur/la passerelle se déconnecte avec le code de cause debug voip ccapi inout = 0x1 (numéro non alloué/non attribué) ou debug isdn q931 (pour les interfaces RNIS) code de cause de déconnexion = 0x8081 (numéro non alloué/non attribué).

  • Problème : DID est configuré et correspond sur le routeur/la passerelle Cisco IOS, mais il n'y a pas de correspondance de terminal de numérotation dial-peer sortant sur le routeur/la passerelle.

  • Problème : assurez-vous que l'appel entrant correspond au terminal de numérotation dial-peer POTS correct où la commande direct-inward-dial est configurée. Pour plus d'informations, référez-vous à la section Correspondance du terminal de numérotation dial-peer POTS entrant correct pour DID de ce document

Exemple de résultat show and debug

Remarque : certaines des lignes de sortie de débogage suivantes sont divisées en plusieurs lignes à des fins d'impression.

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