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

Introduction

Cet avis technique s'applique pour des routeurs/passerelles Cisco IOS activés par la voix avec des interfaces numériques (T1/E1). Pour plus d'informations sur la sélection directe à l'arrivée analogique Cisco (DID) se rapporter à : DID analogique pour des routeurs de la gamme 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 liaison, 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

Conditions requises

Aucune spécification déterminée n'est requise pour ce document.

Components Used

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Conventions

Pour plus d'informations sur les conventions des documents, référez-vous aux Conventions utilisées pour les conseils techniques de 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 PBX (Private Branch Exchange) ou un système vocal par paquets sans l'aide d'un opérateur ou d'un standardiste automatique. Ce service utilise des liaisons DID, qui transmettent 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 de téléphone 555-1000 à 555-1999 et qu'un appelant compose le 555-1234, le central téléphonique local (CO) transfère le numéro 234 au PBX ou au système vocal par paquets. Le PBX ou le système vocal par paquets (routeur/passerelle Cisco CallManager et IOS) sonnerait ensuite le poste 234. Tout ce processus est transparent pour l'appelant.

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

• POTS (Plain Old Telephone Service) : appel vocal traditionnel placé sur le réseau téléphonique public commuté (RTPC), où vous recevez un segment d'appel de bout en bout dédié de circuit de 64 000 pendant la durée de l'appel. Les terminaux de numérotation dial-peer POTS pointent toujours vers un port vocal sur le routeur

• Réseau vocal : un appel vocal sur le réseau de données est composé de plusieurs segments d'appel. Chaque segment d'appel se déplace 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 voix-réseau pointent vers différentes destinations en fonction de la technologie réseau utilisée. Les terminaux de numérotation dial-peer voix-réseau 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 dans le routeur/passerelle Cisco IOS, le port vocal du routeur est saisi en entrée par un commutateur PBX ou CO. Le routeur/passerelle présente ensuite une tonalité à l'appelant et recueille des chiffres jusqu'à ce qu'il puisse identifier un homologue de numérotation sortant. Que les chiffres soient composés à intervalles irréguliers par des êtres humains ou de façon régulière par l'équipement de téléphonie envoyant les chiffres précollectés, la correspondance des homologues de numérotation se fait chiffre par chiffre. Cela signifie que le routeur/la passerelle tente de faire correspondre un terminal de numérotation dial-peer une fois chaque chiffre reçu. Ce processus est appelé numérotation en deux étapes.

Cependant, si le commutateur PBX ou CO envoie un message de configuration contenant « tous » les chiffres nécessaires pour acheminer l'appel, ces chiffres peuvent être mappés directement à un terminal de numérotation dial-peer Voice-Network sortant. Avec DID, le routeur/passerelle ne présente pas de tonalité à l'appelant et ne collecte pas de chiffres. Il transfère l'appel directement à 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 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 une compagnie de téléphone qui fournit le numéro appelant (le numéro de l'initiateur de l'appel). L'ANI est également appelée identification de ligne appelante (CLID).

Configuration DID pour les homologues de numérotation POTS

Lors de la réception d'un appel entrant à partir d'une interface POTS (plain old phone service), la fonction DID des terminaux de numérotation dial-peer permet au routeur/passerelle d'utiliser le numéro appelé (DNIS) pour faire 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 segment d'appel sortant.

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

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

Correspondance de l'homologue de numérotation POTS entrant correct 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 entrant call-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 les suivantes : address_réponse ani_string , destination-pattern string ou port voice-port. L'avantage de l'utilisation de la commande entrant call-number est que chaque appel a associé des informations DNIS (call-number) et qu'il a priorité sur les commandes précédentes.

Si vous n'utilisez pas la commande entrant call-number pour faire correspondre le terminal de numérotation dial-peer entrant, tenez compte des points suivants :

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

• Si l'adresse de réponse n'est PAS mise en correspondance avec ANI, 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 en fonction du numéro appelé ou de l'adresse-réponse ou du modèle de destination ou du port, le terminal de numérotation dial-peer par défaut 0 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. ACME Company a des lignes T1 PRI avec 40 liaisons DID dans la plage de 555-3100 à 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 le test, l'extension future et pour l'instant le routeur ne donne que la tonalité. En supposant que le commutateur CO n’envoie que 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 RTPC	Chiffres envoyés par commutateur vers routeur/passerelle voix	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 développement futur	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 de debug voip ccapi inout reportez-vous à : Dépannage et débogage des appels VoIP - Notions de base

• Pour interpréter les codes de cause de déconnexion d'appel Q.931 de debug isdn q931, reportez-vous à : Présentation des codes de motif de déconnexion debug isdn q931

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

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

• Symptôme : Le routeur/passerelle fournit une tonalité et attend jusqu'à ce que le compteur d'interchiffres expire. Il se déconnecte ensuite 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/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 affecté) ou debug isdn q931 (pour les interfaces RNIS) disconnect code de cause = 0x8081 (numéro non affecté / non affecté).

  • Problème : DID est configuré et le terminal de numérotation dial-peer POTS entrant correct est mis en correspondance sur le routeur/la passerelle Cisco IOS, mais le message de configuration n'inclut pas le numéro d'appel (DNIS). Dans ce cas, vérifiez auprès de la compagnie de téléphone que la liaison est provisionné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 affecté) ou debug isdn q931 (pour les interfaces RNIS) disconnect code de cause = 0x8081 (numéro non affecté/non affecté).

  • Problème : DID est configuré et mis en correspondance sur le routeur/passerelle Cisco IOS, mais il n'existe aucune correspondance de terminal de numérotation dial-peer sortant sur le routeur/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, reportez-vous à la section Correspondance de l'homologue de numérotation POTS entrant approprié 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

Informations connexes

• Compréhension des homologues de numérotation et des signaux d'appel sur des plates-formes Cisco IOS
• Présentation des homologues de numérotation entrante et sortante sur les plates-formes Cisco IOS
• Types, codes et valeurs de commutateurs RNIS
• Configurer des plans de numérotation, des partenaires de numérotation et la manipulation de chiffres
• Configuration de la voix sur IP pour la gamme Cisco 3600
• Présentation des cartes d'interface vocale à 2 ports DID (Direct Inward Dial)
• Support technique - Cisco Systems