Sélection Directe à l'Arrivée

Présentation au sujet: "Sélection Directe à l'Arrivée"— Transcription de la présentation:

1 Sélection Directe à l'Arrivée
Comprendre la Sélection Directe à l'Arrivée (SDA)

2 Sommaire • Introduction • Rappel
• Configuration SDA pour des Dial Peers POTS • Correspondance avec le Dial Peer POTS correct en entrée pour la SDA • Etude de cas • Configurations • Problèmes communs • Exemples de sorties de commandes show et debug

3 Introduction Cette note technique est applicable aux routeurs/passerelles avec des IOS Cisco con- tenant des fonctionnalités voix et des interfaces numériques (E1/T1). Note: Sur la majorité des plateformes, la SDA (ou DID) est validée par défaut pour les interfaces CAS. Par conséquent ne configurez pas la commande direct-inward-dial pour les communications entrantes. Sur les plateformes Cisco AS5300, la SDA n'est pas supportée sur les interfaces E&M avec signalisation immédiate. Rappel La SDA est un service offert par les opérateurs de téléphonie et qui permet aux appe- lants de numéroter directement vers un poste d'un PABX (Private Automatic Branch Exchange) ou d'un système voix paquet sans l'assistance d'un opérateur ou d'un agent d'appel automatisé. Ce service utilise des circuits SDA lesquels acheminent uniquement les 3 à 5 derniers chiffres du numéro de téléphone vers le PABX ou le routeur/passerelle. Si par exemple, une société a les numéro de à et qu'un appelant numérote , le commutateur local (Central Office) public acheminera 234 vers le PABX ou le système voix paquet. Le PABX ou le système voix paquet (Cisco CallManager et IOS Routeur/Passerelle) sonnent le poste 234. Ce pro- cessus est entièrement transparent pour l'appelant. Dans ce document, nous allons traiter les deux types d'extrémité d'appel (Dial-peer) suivants: ● POTS (Plain Old Telephone System) - C'est une communication voix traditionnelle placée sur le RTC (Réseau Téléphonique Commuté) public sur lequel vous obtenez un circuit dédié à 64 Kb/s de bout en bout pour la durée de l'appel. Les extrémi- tés d'appel (Dial-peers) POTS pointeront toujours vers un port voix (voice port) sur le routeur/passerelle. ● Réseau Voix - Une communication voix sur un réseau de données est constituée de plusieurs tronçons. Chaque tronçon est soit entre des équipements de données (routeur/passerelles) soit entre des équipements de données et de téléphonie (tel un routeur et un PABX). Des extrémités d'appel (Dial-peers) réseau voix pointent vers des destinations différentes selon la technologie utilisée. Les extrémités ré- seau voix comprennent: VoIP (Voice over IP) VoFR (Voice over Frame Relay) VoATM (Voice over ATM) MMoIP (Multimedia Mail over IP) Quand une communication voix entre dans un routeur/passerelle avec un IOS Cisco, le port voix est pris en entrée par le PABX ou le commutateur public local. Le routeur /passerelle transmet ensuite la tonalité d'invitation à numéroter vers l'appelant et collecte les chiffres jusqu'à ce qu'il puisse une extrémité d'appel en sortie. Même si les chiffres sont composés à intervalles irréguliers par l'utilisateur ou très régulière- ment par un équipement téléphonique transmettant les premiers chiffres collectés,

4 Correspondance avec le Dial Peer POTS correct en entrée pour la SDA
la correspondance avec le dial-peer se fait chiffre par chiffre. Cela signifie que le rou- teur/passerelle tente de trouver une extrémité d'appel après la réception de chaque chiffre. Ce processus est appelé numérotation à deux étages. Toutefois si le PABX ou le commutateur public local transmettent un message Setup contenant tous les chiffres nécessaires pour router l'appel, ces chiffres peuvent être mis directement en correspondance avec un dial-peer réseau voix en sortie. Avec la SDA, le routeur/passerelle ne transmet pas la tonalité d'invitation à numéroter vers l'appelant et ne collecte pas les chiffres. Celui-ci achemine directement l'appel vers la destination configurée. Ceci est appelé numérotation à un étage. Les chiffres nécessaires pour router les appels dont nous avons parlé dans les para- graphes précédents sont de deux types: ● DNIS (Digital Number Identification Service) est un service numérique d'opérateur de téléphonie qui délivre le numéro appelé (le numéro qui a été composé. ● ANI (Automatic Number Identification) est un service numérique d'opérateur de téléphonie qui délivre le numéro appelant (le numéro qui est à l'origine de l'appel) ANI est également référencé comme CLID (Caller Line Identification). Configuration SDA pour les extrémités d'appel POTS Quand elle reçoit un appel entrant d'une interface POTS, la fonctionnalité SDA des "dial-peers" permet au routeur/passerelle d'utiliser le numéro appelé (DNIS) pour trouver directement une extrémité d'appel en sortie. Quand la SDA est configurée sur un "dial-peer" POTS en entrée, le numéro appelé est automatiquement utilisé pour la correspondance avec le motif de destination pour le tronçon de communication en sortie. Pour configurer un dial-peer POTS pour la SDA, entrez les commandes IOS Cisco sui- vantes en débutant en mode de configuration global. Router(config)#dial−peer voice number pots Router(config−dial−peer)#direct−inward−dial Correspondance avec le Dial Peer POTS correct en entrée pour la SDA Pour que la SDA fonctionne correctement, assurez-vous que les appels entrants cor- respondent au dial-peer POTS sur lequel la commande direct-inward-dial a été con- figurée. Pour une correspondance correcte de dial-peer entrant, nous recommandons l'utilisation de la commande incoming called-number dnis_string sous le dial-peer POTS avec SDA. Les autres commandes utilisées pour la correspondance de dial-peer sont: answer−address ani_string , destination−pattern string ou port voice−port. L'avantage d'utiliser incoming called-number est que chaque appel a une informa- tion DNIS associée (numéro appelé) et celle-ci a la priorité sur les commandes pré- cédentes.

5 Si vous n'utilisez pas la commande incoming called-number pour la correspondan- ce de dial-peer, considérez ce qui suit: ● Si vous utilisez l'information ANI pour la correspondance de dial-peer POTS SDA, assurez-vous que la commande answer-address est correctement configurée et que le commutateur de l'opérateur fournit l'information ANI. ● Si answer-address ne correspond pas avec l'ANI, alors l'ANI peut correspondre avec destination-pattern configurée (appel sortant) sous un autre dial-peer POTS Si destination-pattern correspond avec l'ANI, assurez-vous que la commande direct-inward-dial est configurée sous le dial-peer. ● Si l'appel SDA entrant ne correspond pas à un dial-peer POTS entrant sur la base du incoming called-number ou answer-address ou destination-pattern ou port alors le dial-peer par défaut 0 sera utilisé. La SDA est dévalidée par défaut sur le dial-peer 0. Etude de cas Utilisez l'exemple suivant pur illustrer les points précédents. La compagnie ACME a des lignes T1 PRI avec 40 circuits SDA dans l'intervalle à Le but est d'affecter les 20 premières lignes à des IP Phones Cisco. les 20 dernières lignes sont disponibles pour du test, des extensions futures et pour l'instant le routeur envoie la tonalité d'invitation à numéroter. En supposant que le commutateur public local transmet uniquement les cinq derniers chiffres dans le message RNIS Setup, nous pouvons résumer toutes ces informations dans le tableau suivant: Les utilisateurs RNIS numérotent Chiffres transmis par le commutateur vers le Routeur/passerelle Utilisation Nombre de Circuits à 53100 à 53119 Lignes SDA pour IP Phones 20 à 53120 à 53199 Test et extension future

6 Configuration Réseau IP RTC dial−peer voice 2 pots
Routeur/passerelle Cisco CallManager Tronçon de communication VoIP Tronçon de communication POTS Configuration dial−peer voice 2 pots destination−pattern 9T port 1/0:23 !−−− Ce dial−peer est principalement utilisé pour des appels !−−− sortants avec le motif de destination 9T mappé au port 1/0:23. !−−− Notez que 9 est une correspondance explicite et sera supprimé. !−−− Ce qui veut dire qu'un appel venant du CallManager avec un !−−− DNIS , le router transmettra Si vous !−−− ajoutez la commande dial−peer prefix 9 ou la commande !−−− forward−digit all alors le numéro est transmis. !−−− Notez que dial−peer voice 2 pots est également configuré pour !--- délivrer la tonalité d'invitation aux utilisateurs numérotant !--- dans cet intervalle: (53120 − 53139). dial−peer voice 3 pots !−−- Ce dial−peer peut correspondre uniquement aux appels entrants incoming called−number 5310. !−− Intervalle DNIS 53100−53109 direct−inward−dial !−−- Si ce dial-peer correspond en entrée, il est mis en mode SDA. ! dial−peer voice 4 pots incoming called−number 5311. !−− Intervalle DNIS 53110−53119

7 Problèmes communs dial−peer voice 5 voip
!−−- Dans notre cas, ce dial−peer correspond en sortie uniquement. destination−pattern 53... !−−- Quand les appels se terminent sur ce routeur, le dial−peer 5 !--- peut correspondre en entrée également. session target ipv4: !−−- Adresse IP du CallManager codec g711ulaw Problèmes communs Note: Les codes de cause de déconnexion ont des formats différents dans la sortie de la commande debug isdn q931 à l'opposé de la commande debug voip ccapi inout. ● Pour interpréter les codes de cause de connexion Q.931 à partir de la commande debug voip ccapi inout, référez-vous au document Troubleshooting & Debug VoIP Calls - Basics. ● Pour interpréter les codes de cause de connexion Q.931 à partir de la commande debug isdn q931, référez-vous au document Understanding debug isdn q931 Disconnect Cause Codes. Pour voir les codes de cause d'événement Q.931 en décimal référez-vous à: ISDN event cause codes. Voici quelques exemples de symptômes et les problèmes qui en sont la cause: ● Symptôme: Le routeur/passerelle fournit la tonalité d'invitation à numéroter et attend jusqu'à ce que le timer inter-chiffre expire. Ensuite il déconnecte avec le code de cause debug voip ccapi inout égal à 0x1C (format de numéro invalide) ou avec le code de cause déconnexion debug isdn q931 (pour les interfaces RNIS) égal à 0x809C (format de numéro invalide) Problème: La SDA est configurée sur le commutateur de l'opérateur mais pas sur routeur/passerelle Cisco. ● Symptôme: Le routeur/passerelle déconnecte avec le code de cause dans debug voip ccapi inout égal à 0x1 (non-alloué/numéro non-affecté) ou le code de cause de déconnexion dans debug isdn q931 (pour les interfaces RNIS) égal à 0x (non-alloué/numéro non-affecté) Problème: La SDA est configurée sur le routeur/passerelle IOS Cisco mais le message Setup n'inclut pas le numéro appelé (DNIS). Dans ce cas vérifiez avec l'opérateur que le circuit est bien configuré pour la SDA.

8 ● Symptôme: Le routeur/passerelle déconnecte avec le code de cause dans debug
voip ccapi inout égal à 0x1 (non-alloué/numéro non-affecté) ou le code de cause de déconnexion dans debug isdn q931 (pour les interfaces RNIS) égal à 0x (non-alloué/numéro non-affecté). - Problème: La SDA est configurée et correspond avec le routeur/passerelle IOS Cisco mais il n'y a pas de correspondance avec un dial-peer en sortie sur le rou- teur/passerelle. - Problème: Assurez-vous que l'appel entrant correspond au dial-peer POTS correct sur lequel la commande direct-inward-dial est configurée. Exemples de sorties de commandes show et debug 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 debug DSLs. (On/Off/No DSL:1/0/−) DSL 0 −−> 31 1 − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − − voip: !−−− Action: Le routeur/passerelle IOS Cisco reçoit un appel du RTC vers !−−− le poste "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, !−−− Les debugs ISDN Q.931 et voip ccapi inout montrent un DNIS égal à !−−− et un ANI (Automatic Number Identification) égal à 408 transmis !--- dans un plan de numérotation inconnu. *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=0x ) *Mar 1 04:51:11.888: >>>>CCAPI handed cid 41 with tag 3 to app "DEFAULT" !

9 !−−− Le dial−peer POTS 3 correspond en entrée.
*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) !−−− Le tronçon POTS est crée et un callid égal à 0x29 lui est affecté. *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) !−−− A cause de direct−inward−dial configurée sous dial−peer 3, le DNIS !−−− transmis dans le message setup est considéré suffisant pour la !−−− la correspondance avec un dial-peer en sortie. Cela est validé par !--- le flag fixé à 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) !−−− La table de Dial−peer liste le dial−peer 5 comme correspondance en !--- sortie pour ce DNIS. *Mar 1 04:51:11.892: ssaSetupPeer cid(41), destPat(53103), matched(2), prefix(), peer(83369DB8), peer−>encapType (2) !−−− A cause d'une destination−pattern ayant 2 chiffres et trois points la !−−− correspondance explicite est ramenée à 2 chiffres. *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 !−−− Juste avant la correspondance avec un dial-peer en sortie, nous nous !−−− souvenons d'avoir vu les mêmes ANI et DNIS dans le message setup RNIS !−−− et la sortie de la commande debug voip ccapi initiale. En d'autres !−−− termes,le routeur ne collecte pas d'autres chiffres après la prise du !--- circuit. *Mar 1 04:51:11.896: accountNumber=, finalDestFlag=1, guid=c66d.980c.17a a.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

10 *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=0x C) *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) !−−− Sortie supprimée !−−− La sortie suivante affiche la libération de communication. *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), *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) !−−− Ces deux lignes sont importantes pour trouver la source de la !−−− déconnexion. Elles nous disent que le premier tronçon de communication !--- avec le callid 0x29 (tronçon POTS) s'est déconnecté avec la cause !−−− 0x10. Soit l'utilisateur d'extrémité POTS a raccroché ou l'équipement !--- s'est déconnecté sans raison. Du point de vue du routeur cela revient !−−− au même.

11 *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 tronqué ici 2600#show call active voice brief !−−− Cette commande show est utile pour vérifier quels sont les dial−peers !--- qui correspondent à la communication. Dans l'exemple ci-dessous, la !−−− sortie montre que le tronçon POTS correspond au dial−peer voice 3 pots !--- (pid:3) et le tronçon VoIP correspond au dial−peer voice 5 voip !--- (pid:5). !−−− Sortie supprimée Total call−legs: 2 3A : hs 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 : hs pid:5 Originate active dur 00:00:07 TX:160/23690 rx:385/61600 IP :25704 rtt:0ms pl:4980/0ms lost:0/0/0 delay:64/64/65ms g711ulaw