Voix : Digital CCS

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

18 octobre 2016 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires


Contenu


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 Plateformes, A FAIT est activé par défaut sur des interfaces de CAS (immédiat, clignez de l'oeil, retard). Par conséquent, ne configurez pas la commande de direct-inward-dial pour des appels entrant. Sur des Plateformes de Cisco AS5300, A FAIT n'est pas pris en charge sur des interfaces configurées pour la signalisation immédiate E et M.

Conditions préalables

Conditions requises

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

Composants utilisés

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

A FAIT est un service proposé par des opérateurs téléphoniques qui permet à des appelants de composer directement à une extension sur un autocommutateur privé (PBX) ou le système vocal par paquets sans assistance d'un opérateur ou d'un préposé automatisé d'appel. Ce service se sert A FAIT les joncteurs réseau, qui expédient seulement les les trois derniers à cinq chiffres d'un numéro de téléphone au PBX ou au routeur/à passerelle. Si par exemple, une société a des extensions de téléphones 555-1000 à 555-1999, et des cadrans d'un appelant 555-1234, le bureau central local (Co) expédierait 234 au PBX ou au système vocal par paquets. Le PBX ou le système vocal par paquets (Cisco CallManager et routeur IOS/passerelle) sonnerait alors l'extension 234. Tout ce processus est transparent pour l'appelant.

Dans ce document, nous discutons deux types de pairs de cadran comme suit :

  • Réseau téléphonique public commuté (POTS) — C'est une communication voix traditionnelle placée au-dessus du réseau téléphonique public commuté (PSTN) où vous obtenez un segment d'appel de bout en bout sur circuit 64k dédié pendant la durée de l'appel. Les homologues de numérotation POTS indiqueront toujours un port vocal sur le routeur

  • Réseau voix — Une communication voix au-dessus du réseau de données se compose de plusieurs appel-tronçons. Chaque appel-tronçon voyage entre les périphériques de données (Routeurs/passerelles) ou entre les périphériques de transmission de données et de téléphonie (tels qu'un routeur à un PBX). Les homologues de numérotation sur réseau voix indiquent différentes destinations selon la technologie de réseau utilisée. Les homologues de numérotation sur réseau voix incluent ce qui suit :

    • Voix sur ip (VoIP)

    • Voix sur relais de trame (VOFR)

    • Voix sur ATM (VoATM)

    • Messagerie multimédias sur IP (MMoIP)

Quand une communication voix entre dans le routeur Cisco IOS/passerelle, le port vocal sur le routeur est d'arrivée saisi par un PBX ou commutateur CO. Le routeur/passerelle alors présente une tonalité à l'appelant et collecte des chiffres jusqu'à ce qu'elle puisse identifier un homologue de numérotation en sortie. Si les chiffres sont composés avec des intervalles irréguliers par des humains ou d'une façon habituelle par l'équipement de téléphonie envoyant les chiffres pré-collectés, la mise en correspondance du homologue de numérotation est chiffre-par-chiffre fait. Ceci signifie les tentatives de routeur/passerelle d'apparier un pair de cadran après que chaque chiffre soit reçu. Ce processus s'appelle composition à deux étages.

Cependant, si le PBX ou commutateur CO envoie un message de configuration contenant les « tous les » chiffres nécessaires pour conduire entièrement l'appel, ces chiffres peuvent être tracés à un partenaire de numérotation de réseau vocal sortant directement. Avec A FAIT, le routeur/passerelle ne présente pas une tonalité à l'appelant et ne collecte pas des chiffres. Il en avant l'appel directement à la destination configurée. Ceci s'appelle la composition en une étape.

Les chiffres nécessaires pour conduire les appels que nous avons discutés dans les paragraphes ci-dessus sont des deux types suivants :

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

  • L'enregistrement automatique des numéros (ANI) est compagnie de téléphone-a fourni le service numérique qui fournit le numéro appelant (le nombre de l'émetteur d'appel). L'ANI désigné également sous le nom de identification de ligne d'appel (CLID).

A FAIT la configuration pour des homologues de numérotation POTS

Quand la réception d'un appel d'arrivée d'une interface de réseau téléphonique public commuté (POTS), a comporté dans des pairs de cadran permet au routeur/à passerelle d'utiliser le numéro appelé (DNIS) pour apparier directement un homologue de numérotation en sortie. Quand A FAIT est configuré sur l'homologue de numérotation POTS d'arrivée, le numéro appelé est automatiquement utilisé pour apparier le modèle de destination pour le signal d'appel sortant.

Pour configurer un homologue de numérotation POTS pour A FAIT, sélectionner les commandes Cisco IOS suivantes commençant en mode de configuration globale :

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

Apparier l'homologue de numérotation POTS d'arrivée correct pour A FAIT

Pour avez fonctionné correctement, s'assurent que l'appel entrant apparie l'homologue de numérotation POTS correct où le direct-inward-dial de commande est configuré. Pour apparier l'homologue de numérotation en entrée correct, nous recommandons utilisant la commande de homologue de numérotation incoming called-number dnis_string en vertu du AVONS FAIT l'homologue de numérotation POTS.

D'autres commandes utilisées pour apparier des cadran-pairs incluent : port vocal ani_string, de chaîne de configuration de destination ou de port de réponse-adresse. L'avantage d'utiliser la commande entrante de numéro appelé est que chaque appel a associé les informations DNIS (numéro appelé) et elles ont la priorité au-dessus des commandes précédentes.

Si vous n'utilisez pas la commande entrante de numéro appelé d'apparier l'homologue de numérotation en entrée, considérez ce qui suit :

  • Si l'utilisation des informations ANI pour apparier A FAIT l'homologue de numérotation POTS, s'assurent que la réponse-adresse de commande est configurée correctement et le commutateur de la compagnie de téléphone fournit les informations ANI. Quelques fournisseurs RNIS et la plupart de canal de signalisation associé de t1 (CAS), à moins que le groupe D (fgd) de caractéristique, ne fournissent pas les informations ANI.

  • Si la réponse-adresse n'est pas appariée contre l'ANI, alors l'ANI peut apparier la destination-pattern configurée (pour la composition sortante) sous un autre homologue de numérotation POTS. Si la destination-pattern est appariée contre l'ANI, assurez-vous que le direct-inward-dial de commande est configuré sous ce cadran-pair.

  • Si l'appel entrant DID n'est pas apparié à un homologue de numérotation POTS d'arrivée basé sur le numéro appelé ou la réponse-adresse ou la destination-pattern ou le port entrante, alors l'homologue de numérotation par défaut 0 sera utilisé. A FAIT est désactivé par défaut sur le dial-peer 0.

Étude de cas

Employez l'exemple suivant, pour illustrer les points ci-dessus. ACME Company a des lignes de T1 PRI avec des 40 jonctions réseau DID de l'ordre de 555-3100 à 555-3139. Le but est d'assigner les 20 premières lignes aux Téléphones IP de Cisco. Les 20 dernières lignes sont disponibles pour tester, la future extension et pour l'instant le routeur donne la tonalité seulement. Supposant que le commutateur CO envoie seulement les cinq derniers chiffres dans le message de configuration RNIS, nous pouvons récapituler les informations ci-dessus dans le tableau suivant.

Cadran d'utilisateurs PSTN Chiffres envoyés par le commutateur pour exprimer le Router/Gateway Utilisation # joncteurs réseau
555-3100 à 555-3119 53100 - 53119 A FAIT des lignes pour des Téléphones IP 20
555-3120 à 555-3139 53120 - 53139 Test et expansion future 20

/image/gif/paws/14072/callmanager-gw.gif

Configuration

Remarque: Une partie de la sortie dans cet exemple est omise.

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: Codes de motif de déconnexion ont des formats différents dans la sortie du debug isdn q931 par opposition à la commande de debug voip ccapi inout.

Pour voir codes de motif d'événement Q.931 dans le format décimal se rapporter : Codes de motif d'événement RNIS leavingcisco.com

Ce qui suit sont quelques exemples des symptômes et des questions qui peuvent les entraîner :

  • Symptôme : Le routeur/passerelle fournit la tonalité et attend jusqu'aux temps de valeur de temps inter-chiffres. Alors il déconnecte avec code de cause de debug voip ccapi inout = code de motif de déconnexion 0x1C (format de numéro incorrect) ou de debug isdn q931 (pour des interfaces RNIS) = 0x809C (format de numéro incorrect).

    • Question : A FAIT est configuré sur le commutateur de la compagnie de téléphone mais pas sur le routeur Cisco IOS/passerelle.

  • Symptôme : Débranchements de routeur/passerelle avec code de cause de debug voip ccapi inout = nombre (non affecté/non affecté) 0x1 ou code de motif de déconnexion de debug isdn q931 (pour des interfaces RNIS) = nombre (non affecté/non affecté) 0x8081.

    • Question : A FAIT est configuré et l'homologue de numérotation POTS d'arrivée correct est apparié sur le routeur Cisco IOS/passerelle, mais le message de configuration n'inclut pas le numéro appelé (DNIS). Vérifiez dans ce cas avec la compagnie de téléphone que le joncteur réseau provisioned pour A FAIT.

  • Symptôme : Débranchements de routeur/passerelle avec code de cause de debug voip ccapi inout = nombre (non affecté/non affecté) 0x1 ou code de motif de déconnexion de debug isdn q931 (pour des interfaces RNIS) = nombre (non affecté/non affecté) 0x8081.

    • Question : A FAIT est configuré et apparié sur le routeur Cisco IOS/passerelle, mais il n'y a aucune concordance d'homologues de numérotation sortants sur le routeur/passerelle.

    • Question : Assurez-vous que l'appel entrant apparie l'homologue de numérotation POTS correct où le direct-inward-dial de commande est configuré. Le pour en savoir plus se rapportent à apparier l'homologue de numérotation POTS d'arrivée correct pour a sectionné de ce document

Exemple de résultat show and debug

Remarque: Certaines des lignes suivantes de sortie de débogage sont divisées en plusieurs lignes pour des raisons 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


Document ID: 14072