Dépannage sortant basé sur RVI de numéroteur
Contenu
Introduction
Ce document décrit le numéroteur sortant basé sur RVI et comporte une configuration de passerelle de SIP témoin, des analyses de log de la passerelle de SIP et de l'engine du Cisco Unified Contact Center Express (UCCX), et les limites du numéroteur sortant basé sur RVI.
Dans UCCX 8.5, un nouveau type de numéroteur sortant a été introduit : le numéroteur sortant basé sur de la réponse vocale interactive (RVI). À la différence du numéroteur sortant d'aperçu plus ancien, aucun agent n'est utilisé pour faire l'appel sortant. UCCX se connecte directement à une passerelle de Protocole SIP (Session Initiation Protocol) à l'entreprise de client pour composer les contacts sortants. Quand la passerelle détecte une Voix vivante ou un répondeur, l'appel est réorienté à un déclencheur UCCX attaché à un groupe témoin d'appel sortant. Une fois terminé sur le port sortant de l'intégration de couplage de la téléphonie et de l'informatique (CTI), l'application associée avec le déclencheur est exécutée en tant que normale.
Les informations de caractéristique
Dans des versions UCCX plus tôt que 8.5, seulement le numéroteur sortant d'aperçu ont existé. Ce numéroteur a utilisé le tiers Contrôle d'appel par l'intermédiaire de l'interface de programmation de téléphonie de Javas (JTAPI) /CTI pour demander au téléphone de l'agent pour faire l'appel. L'appel a été fait après qu'un agent ait reçu une réservation sortante. L'interaction entre le client et serveur pour des réservations sortantes faisait par l'intermédiaire de CTI.
Pour certains cas d'utilisation (tels que des rappels de rendez-vous et des applications IVR de libre-service), le numéroteur sortant d'aperçu n'était pas une bonne adaptation. Pour faire un appel à un nombre dans le DialingList, un agent a été attaché vers le haut de tandis que l'appel était placé. Cela a signifié que l'agent a été occupé pour chaque appel sortant, même si le nombre commuté public du réseau téléphonique (PSTN) était non valide, occupé ou eu comme conséquence un répondeur. Ce haut niveau d'utilisation d'agent était un inconvénient majeur de numéroteur sortant d'aperçu pour ces cas d'utilisation.
Écoulement basé sur RVI d'appel sortant
Pour les mêmes cas d'utilisation (des rappels de rendez-vous et des applications IVR de libre-service) dans le numéroteur sortant basé sur RVI, un agent pourrait ne jamais être impliqué dans l'écoulement d'appel. C'est l'écoulement d'appel pour le numéroteur sortant basé sur RVI :
- Le numéroteur sortant RVI détermine le nombre de contacts pour composer (comme défini dans l'algorithme) et les utilisations SIROTENT pour placer des appels sortants par la passerelle de Voix.
- La passerelle de Voix détecte le contact non-vivant avec ses capacités d'analyse de progression de l'appel (CPA) et envoie le statut du contact non-vivant au numéroteur. Le numéroteur met à jour les informations d'état de contact dans la base de données de configuration.
- La passerelle de Voix détecte le contact vivant avec ses capacités de CPA et envoie le statut du contact vivant au numéroteur. Le numéroteur met à jour les informations d'état de contact dans la base de données de configuration et envoie également un SIP se réfèrent le message à la passerelle de SIP, qui, consécutivement, transfère l'appel vers le point de routage CTI configuré sur Cisco Unified Communications Manager (CUCM).
- Le CUCM transfère l'appel vers un port IVR sur le serveur de Cisco UCCX.
- Le sous-système RVI associe l'appel avec l'application IVR associée avec la campagne. L'engine commence l'exécution de l'application et une session RVI a lieu entre l'application IVR de campagne sur UCCX et les relations clients.
Types basés sur RVI de numéroteur
Il y a deux types de numéroteurs sortants basés sur RVI, prévisionnel et progressif. Puisqu'UCCX transfère seulement un appel vers un port IVR pour exécuter un script quand une Voix vivante (ou le répondeur configurable) est détectée, il est raisonnable de supposer que non chaque contact sortant exige un port. Afin d'équilibrer occasion qu'un port CTI est nécessaire contre la probabilité qui sonnent le pas de réponse (ARN), occupé et les situations de nombre non valide existent, prévisionnel et les numéroteurs progressifs modifient le nombre d'appels sortants qui sont faits à la fois contre le nombre de ports CTI sortants configurés.
Un numéroteur sortant basé sur RVI prévisionnel a ces caractéristiques :
- Le nombre de lignes pour chaque port peut être accordé, basé sur le débit d'appel d'abandon.
- Aucune intervention manuelle n'est nécessaire.
- Le but est de composer assez de lignes pour maintenir les ports IVR occupés mais pour ne pas dépasser le débit d'appel maximum configuré d'abandon.
Un numéroteur sortant basé sur RVI progressif a ces caractéristiques :
- Vous pouvez spécifier un nombre fixe de lignes qui sont toujours composées pour chaque port IVR sortant disponible.
- Le nombre de lignes peut être mis à jour à une date ultérieure.
- S'il y a trois lignes pour chaque port et le nombre dédié de ports pour sortant est trois, alors neuf appels (3x3) sont composés.
- Un appel abandonné se produit quand un client répond au téléphone, mais aucun port n'est disponible pour inciter le client.
- Vous pouvez définir des valeurs par défaut.
Composants de numéroteur avec UCCX
Tous les fonctionnalité et sous-systèmes internes sont abrégés pour expliquer ce nouveau numéroteur sortant basé sur RVI. Les composants système dans le nouveau numéroteur, comme la table d'engine et de DialingList, sont identiques que dans le numéroteur sortant d'aperçu, avec des extensions (comme plus de valeurs de callStatus et de callResult) ajoutées.
Les informations de caractéristique de passerelle
Afin de prendre en charge la détection de la Voix vivante, le répondeur et les tonalités de l'information d'offre spéciale (REPOSEZ-VOUS), la passerelle doivent prendre en charge la caractéristique de CPA. Utilisez le navigateur de caractéristique de Cisco afin de déterminer les versions de Cisco IOS® de passerelle que numéroteur et CPA de SIP de support ; utilisez la « recherche par la caractéristique » recherchent le « soutien d'utilité du numéroteur de SIP et de l'analyse de progression de l'appel. »
Comment CPA fonctionne-t-il ?
Il y a trois fonctions primaires dans CPA :
- Détection de répondeur (AMD)
- Détection de télécopie/modem
- Répondeur terminant la détection de tonalité
Il y a les algorithmes complexes mis en application pour faire ces distinctions, mais, à partir d'un point fonctionnel de support :
- On s'attend à ce qu'une réponse vivante d'interlocuteur soit une salutation courte, puis une période de silence.
Exemple : « Bonjour » + silence
Exemple : « Bonjour, résidence de Johnson » + silence - On s'attend à ce qu'un répondeur soit une plus longue salutation, puis aucun silence.
Exemple : « Vous avez atteint la résidence du Miller, laissez s'il vous plaît un message après le bip » - On s'attend à ce qu'un répondeur terminant la tonalité les détectent soit détection du répondeur, puis de silence, puis d'une tonalité de terminaison.
- Une télécopie les détectent est reconnaissance de la tonalité de télécopie.
La capacité de faire ces distinctions pourrait être difficile, ainsi vous pourriez devoir ajuster des paramètres de synchronisation afin d'optimiser la configuration.
Un autre facteur à considérer est que les fournisseurs de téléphone portable pourraient avoir de divers degrés de retard entre la présentation d'un appel à eux, emplacement de la cellule, et présentation de l'appel à la cellule elle-même.
C'est un exemple du calcul impliqué :
- UCCX envoie un SIP invite à la passerelle (le t1)
- La passerelle envoie un établissement d'appel RNIS au fournisseur de services et sur le fournisseur de cellules (le T2)
- Le téléphone portable sonne et met en marche son temporisateur de pas de réponse (le T3)
- Le temporisateur d'ARN de cellules expire et en avant à la messagerie vocale (T4)
Si vous supposez que le temporisateur d'ARN pour la cellule est de 15 secondes, le montant effectif de temps où il prendrait pour un appel à une cellule pour expédier à la messagerie vocale est (t1 + T2 + T3 + 15). Le t1 + le T2 + le T3 pourraient être de manière significative supérieur à la durée qu'il prend pour présenter un appel à des lignes terrestres ou à tout autre périphérique de non-cellule.
Ainsi, quand vous définissez la limite de sonnerie de pas de réponse pour une campagne, le délai prévu doit être assez long pour atteindre le système de messagerie vocale pour des téléphones portables ; ce serait le comportement désiré, par exemple, pour une campagne destinée pour laisser un message.
La sélection des codes de passerelle IOS est hors de portée de ce document. Le code de passerelle doit prendre en charge CPA et SIROTER le numéroteur pour utiliser le numéroteur sortant basé sur RVI. Cisco comportent le navigateur peut vous aider à trouver les releases IOS qui répondent à des exigences de fonctionnalité. Assurez toujours que votre release IOS est compatible avec tous les composants qui interagissent avec cette passerelle.
Dépanner
Afin de dépanner un RVI sortant, déterminez si la passerelle, le CUCM ou l'UCCX est fautif. Le dépannage est plus facile une fois que vous localisez le problème dans un élément spécifique. Il est utile de collecter ces informations des composants système
Pour la passerelle, exécutez ces commandes :
- affichez le tech
- debug ccsip messages
- debug voip ccapi inout
- debug isdn q931 (ou semblables mettez au point pour capturer la signalisation de côté PSTN)
- debug voip hpi tout (pour dépanner CPA)
- debug voip vtsp tout (pour dépanner CPA)
Pour UCCX, fichiers journal et configuration d'examen :
- Fichiers journal MIVR avec l'élimination des imperfections SS_OB et le XDebug1 - XDebug3 activé
- Fichiers journal JTAPI (pour dépanner l'échec d'appel référé)
- Configuration de passerelle de SIP d'UCCX AppAdmin
Pour le CUCM, configurations d'examen :
- CallManager détaillé
- CTIManager détaillé
- SIROTEZ la configuration de joncteur réseau qui indique la passerelle utilisée pour le RVI sortant
Analyse de données
La passerelle de SIP doit contenir la configuration nécessaire non seulement pour conduire des demandes d'appel d'UCCX au PSTN, mais pour manipuler également le transfert de ces appels au déclencheur UCCX indiqué pour sortant. Cette configuration de passerelle de SIP doit avoir :
- Homologues de numérotation en entrée pour apparier des demandes entrantes de SIP d'UCCX.
- Homologues de numérotation en sortie (VoIP ou réseau téléphonique public commuté [POTS]) pour conduire des appels au PSTN.
- Homologues de numérotation en sortie (VoIP) pour conduire l'appel (référé) réorienté à la batterie CUCM qui est intégrée avec UCCX.
Le serveur CUCM doit être configuré pour recevoir des demandes d'appel d'arrivée de SIP de la passerelle de SIP (les appels référés) et pour conduire les demandes en conséquence au déclencheur UCCX et aux ports CTI de groupe de Contrôle d'appel UCCX.
Configuration de passerelle de SIP témoin
C'est un exemple d'une configuration de passerelle de SIP avec des notations. La connectivité RTPC dans cet exemple est l'interface PRI RNIS (PRI).
RyanIVRRouter#show run
Building configuration...
Contrôleur de t1 configuré pour le PRI RNIS
!
controller T1 0/0/0
cablelength long 0db
pri-group timeslots 1-24
!
Interface série configurée pour le PRI RNIS
!
interface Serial0/0/0:23
no ip address
encapsulation hdlc
isdn switch-type primary-ni
isdn incoming-voice voice
no cdp enable
!
Port vocal pour conduire des appels sortants au PSTN
!
voice-port 0/0/0:23
!
Homologue de numérotation VoIP d'arrivée
Demandes de cet de mises en correspondance des homologues de numérotation appel entrantes de SIP d'UCCX. Si un homologue de numérotation VoIP d'arrivée n'est pas configuré, l'homologue de numérotation par défaut (dial-peer 0) est apparié. Il est dans pratique recommandée de définir et apparier un homologue de numérotation VoIP d'arrivée. Ce cadran-pair informe la passerelle du relais de codecs, de protocole et de Multifréquence deux tons (DTMF) à utiliser sur le tronçon d'arrivée de SIP d'UCCX.
Ce les mises en correspondance des homologues de numérotation toutes des SIP INVITE d'arrivée avec une identification numérique de numéro entretiennent (DNIS) ce début avec 717 et ce sont 10 chiffres longs. Dans cet exemple, tous les contacts composés par UCCX sont dans code postal 717 et ont des numéros de téléphone 10 chiffres longs.
!
dial-peer voice 100 voip
description -- Outbound Calls From UCCX --
session protocol sipv2
incoming called-number 717.......
dtmf-relay rtp-nte
codec g711ulaw
!
Homologue de numérotation POTS
Ce cadran-pair conduit des appels au PSTN au cours du PRI configuré précédemment. C'est le cadran-pair sortant pour les demandes d'appel provenant UCCX et l'homologue de numérotation en sortie pour l'homologue de numérotation VoIP 100 ci-dessus. Ce cadran-pair sert également d'homologue de numérotation en entrée aux appels provenant le PSTN pour le test. Dans l'écoulement sortant d'appel de numéroteur UCCX, ce cadran-pair n'est pas apparié en tant qu'homologue de numérotation en entrée.
!
dial-peer voice 10 pots
description -- POTS Dial Peer To/From PSTN Simulator --
destination-pattern 717.......
incoming called-number .
direct-inward-dial
port 0/0/0:23
forward-digits all
!
Homologue de numérotation VoIP sortant
Ce cadran-pair sert d'homologue de numérotation en sortie requis par la passerelle de SIP pour conduire des appels à la batterie CUCM destinée pour le déclencheur UCCX. Ce cadran-pair est utilisé par la passerelle pour conduire REFER envoyé par UCCX si vivant expriment (ou répondeur si la configuration existe) est détecté. Ce cadran-pair définit le protocole, le relais de DTMF, les codecs et l'adresse IP du noeud CUCM où la passerelle de SIP devrait conduire l'appel réorienté. Aux fins de la Redondance et de l'Équilibrage de charge, les plusieurs homologues de numérotation de ce type pourraient exister. Ils pourraient être divisés aux demandes de route à de plusieurs Noeuds CUCM dans la batterie ou provisioned pour conduire réoriente pour certains déclencheurs à différents Noeuds CUCM.
Dans cet exemple, les déclencheurs UCCX pour des campagnes sortantes basées sur RVI sont 2001 et 2002.
!
dial-peer voice 102 voip
description -- Redirect Calls to UCCX 90 --
destination-pattern 200[1-2]
session protocol sipv2
session target ipv4:14.10.166.15
incoming called-number 200[1-2]
dtmf-relay rtp-nte
codec g711ulaw
!
Analyse de suivi basée sur RVI d'appel sortant d'échantillon
C'est une analyse détaillée d'un log de Messagerie d'exemple entre la passerelle de SIP, UCCX et le PSTN.
L'initiale INVITENT d'UCCX demande à la passerelle pour faire un appel au nombre PSTN. L'INVITATION contient l'ID d'appel, qui peut être utilisé pour dépister tous les messages associés avec cet appel, et la Session Description Protocol (SDP) (paramètres de medias).
D'une manière primordiale, l'INVITATION inclut les paramètres que la passerelle devrait employer pour se terminer CPA. Ces paramètres sont configurés dans les pages UCCX AppAdmin, mais ne sont pas utilisés par UCCX. En revanche, ils sont introduits l'INVITATION à la passerelle et utilisés par la passerelle pour configurer les processeurs de signaux numériques (DSP) pour CPA pour cet appel. En conséquence, ces paramètres sont envoyés à la passerelle sur une base de par-appel et peuvent être changés à tout moment d'AppAdmin.
UCCX envoie à ceux-ci des attributs de configuration de CPA à la passerelle pour chaque appel :
| Nom de paramètre | Valeur de paramètre | Valeur suggérée |
| Période minimum de silence (100 - 1000)* | Millisecondes | 375 |
| Période d'analyse (1000 - 10000)* | Millisecondes | 2500 |
| Analyse de temps maximum (1000 - 10000)* | Millisecondes | 3000 |
| Temps valide minimum de la parole (50 - 500)* | Millisecondes | 112 |
| Analyse maximum de tonalité de terme (1000 - 60000)* | Millisecondes | 15000 |
Des valeurs configurables sont présentées dans AppAdmin à la page de configuration de passerelle de SIP.
Received:
INVITE sip:7175551212@14.10.153.56:5060;transport=udp SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
Content-Type: multipart/mixed;boundary=unique_boundary
--unique_boundary
Content-Type: application/sdp
Content-Disposition: session;handling=required
v=0
o=Cisco-UCCX 1608 1 IN IP4 14.10.166.16
s=SIP Call
c=IN IP4 0.0.0.0
t=0 0
m=audio 12345 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=ptime:20
--unique_boundary
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional
Events=FT,Asm,AsmT,Sit
CPAMinSilencePeriod=375
CPAAnalysisPeriod=2500
CPAMaxTimeAnalysis=3000
CPAMinValidSpeechTime=112
CPAMaxTermToneAnalysis=15000
--unique_boundary--
Pendant que l'appel traite par les cadran-pairs de la passerelle, UCCX est envoyé à un message '100 Trying.
Sent:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 14.10.166.16:5065;branch=z9hG4bKEsF4FAHPTVliP0ozE1BcOQ~~17
From: <sip:9195551212@14.10.166.16>;tag=dsa994554a
To: <sip:7175551212@14.10.153.56>
Date: Fri, 03 Aug 2012 18:38:46 GMT
Call-ID: 134401919546410@14.10.166.16
CSeq: 100 INVITE
Allow-Events: telephone-event
Server: Cisco-SIPGateway/IOS-12.x
Content-Length: 0
Quand l'appel sortant apparie un homologue de numérotation en sortie, il est envoyé au PSTN utilisant le protocole configuré TDM. Dans ce cas, un PRI est utilisé :
Aug 3 18:38:46.559: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8 callref = 0x008D
Bearer Capability i = 0x8090A2
Standard = CCITT
Transfer Capability = Speech
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98397
Exclusive, Channel 23
Calling Party Number i = 0x2180, '9195551212'
Plan:ISDN, Type:National
Called Party Number i = 0xA1, '7175551212'
Plan:ISDN, Type:National
Les progressions de l'appel et la signalisation est permutées entre le PSTN et la passerelle. On annonce la passerelle que le téléphone PSTN sonne avec le message d'ALERTE.
Aug 3 18:38:46.595: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8 callref = 0x808D
Channel ID i = 0xA98397
Exclusive, Channel 23
Aug 3 18:38:46.603: ISDN Se0/0/0:23 Q931: RX <- ALERTING pd = 8 callref = 0x808D
Progress Ind i = 0x8188 - In-band info or appropriate now available
La passerelle envoie une progression de 183 sessions de nouveau à UCCX pour informer UCCX que le téléphone PSTN sonne. Ceci inclut le SDP pour la négociation de support des tonalités de rappel.
Sent:
SIP/2.0 183 Session Progress
...
Call-ID: 134401919546410@14.10.166.16
...
--uniqueBoundary
Content-Type: application/sdp
Content-Disposition: session;handling=required
v=0
o=CiscoSystemsSIP-GW-UserAgent 7343 9805 IN IP4 14.10.153.56
s=SIP Call
c=IN IP4 14.10.153.56
t=0 0
m=audio 32330 RTP/AVP 0 101 19
c=IN IP4 14.10.153.56
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20
...
--uniqueBoundary
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional
event=enabled
--uniqueBoundary--
L'appel est connecté sur le tronçon TDM comme le téléphone PSTN a répondu à l'appel. La passerelle envoie une confirmation dans le CONNECT_ACK.
Aug 3 18:38:49.207: ISDN Se0/0/0:23 Q931: RX <- CONNECT pd = 8 callref = 0x808D
Aug 3 18:38:49.211: ISDN Se0/0/0:23 Q931: TX -> CONNECT_ACK pd = 8 callref = 0x008D
La passerelle informe UCCX que l'appel est connecté à un OK 200. UCCX Acks ceci, selon les exigences du RFC de SIP. L'OK 200 contient également le SDP pour la négociation de support, mais il n'est pas utilisé par UCCX.
Sent:
SIP/2.0 200 OK
...
Call-ID: 134401919546410@14.10.166.16
...
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 271
v=0
o=CiscoSystemsSIP-GW-UserAgent 7343 9805 IN IP4 14.10.153.56
s=SIP Call
c=IN IP4 14.10.153.56
t=0 0
m=audio 32330 RTP/AVP 0 101 19
c=IN IP4 14.10.153.56
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20
Received:
ACK sip:7175551212@14.10.153.56:5060 SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
La passerelle détecte la progression de l'appel avec CPA et informe UCCX de la progression de l'appel par une gamme de messages de MISE À JOUR. UCCS Acks ceci, selon les exigences du RFC de SIP.
Dans cet exemple d'une mise à jour de SIP, l'événement « est détecté » et l'état est « CpaS ».
- CpaS indique que CPA a commencé.
- Quand un répondeur est détecté, l'état est « ASM. »
- Quand la tonalité de répondeur est qualifiée, l'état est « AsmT. »
Ce tableau présente codes d'état de x-Cisco-CPA utilisés dans les messages de mise à jour de SIP :
| Nom | Définition |
Pi |
Tonalité de télécopie/modem. |
ASM |
Ordinateur de réponse. |
AsmT |
L'ordinateur de réponse terminent la tonalité. |
LS |
Discours humain vivant. |
SitIC |
REPOSEZ la tonalité IC - Interception - No. vide ou AIS ou tellement en avant. |
SitNC |
REPOSEZ la tonalité OR - Aucune circuit, urgence ou blocage de joncteur réseau |
SitVC |
REPOSEZ LE circuit virtuel de tonalité - Code vide |
SitRO |
REPOSEZ LE RO de tonalité - Commandez à nouveau l'annonce |
SitMT |
Divers REPOSEZ la tonalité |
CpaS |
Début de CPA |
BT |
Appel de bas volume ou d'air mort |
Sent:
UPDATE sip:9195551212@14.10.166.16:5065;transport=udp SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
Content-Type: application/x-cisco-cpa
Content-Disposition: signal;handling=optional
Content-Length: 26
event=detected
status=CpaS
Received:
SIP/2.0 200 Ok
...
Call-ID: 134401919546410@14.10.166.16
...
UCCX envoie une notification à la passerelle pour réorienter l'appel au déclencheur assigné à cette campagne sortante. La passerelle Acks ceci.
Received:
REFER sip:7175551212@14.10.153.56:5060 SIP/2.0
...
Call-ID: 134401919546410@14.10.166.16
...
Refer-To: <sip:2001@14.10.153.56>
...
Sent:
SIP/2.0 202 Accepted
...
Call-ID: 134401919546410@14.10.166.16
...
La passerelle doit conduire cet appel à la nouvelle destination en tant que n'importe quel Traitement des appels normal par les cadran-pairs sur la passerelle.
Aug 3 18:39:07.275: //60/7120520F060E/CCAPI/ccCallSetupRequest:
Destination=, Calling IE Present=FALSE, Mode=0,
Outgoing Dial-peer=102, Params=0x31BDB494, Progress Indication=NULL(0)
L'appel est conduit par la passerelle basée sur la configuration dans l'homologue de numérotation en sortie apparié pour la destination contenue dans le RÉFÉRER.
Sent:
INVITE sip:2001@14.10.166.15:5060 SIP/2.0
...
Call-ID: 5789DBCB-DCD111E1-8081ADFE-F735B3DC@14.10.153.56
...
Content-Type: application/sdp
Content-Disposition: session;handling=required
Content-Length: 270
v=0
o=CiscoSystemsSIP-GW-UserAgent 5187 301 IN IP4 14.10.153.56
s=SIP Call
c=IN IP4 14.10.153.56
t=0 0
m=audio 25002 RTP/AVP 0 101 19
c=IN IP4 14.10.153.56
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20
Analyse de log témoin MIVR
Ces extraits d'un log MIVR fournissent un aperçu de l'appel d'un point de vue UCCX. Activez ces derniers mettent au point des niveaux pour saisir les informations correctes :
- SS_OB - Debug,XD1,XD2,XD3
- SS_RM - Debug,XDebug1
- CFG_MGR - Debug,XDebug1 (si la question est avec les enregistrements de composition de liste)
135533948: Aug 20 21:34:54.631 EDT %MIVR-CFG_MGR-7-UNK:ConfigManagerImpl-getAll():CIR
[0]=ConfigImportRecord[schema=DialingListConfig#2,time=2012-08-20 21:34:42.0,
recordId=239,implClass=class com.cisco.crs.outbound.DialingListConfig,desc=,
values=[239, 2, 1662760, NAME, TEST777, 9785551212, , , 343, true, -1, true, -1, true, ,
2012-08-20 21:34:42.0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, null, null, null, null],evalues=null]
//Import the record from the dialing list. In this case, the recordID=239
135533949: Aug 20 21:34:54.632 EDT %MIVR-CFG_MGR-7-UNK:ConfigManagerImpl-getAll():con
figObjs[0]=DialingListConfig[schema=DialingListConfig#2,time=2012-08-20 21:34:42.0,
recordId=239,desc=,recordID=0,dialingListID=239,campaignID=2,accountNumber=1662760,
firstName=NAME,lastName=TEST777,phone01=9785551212,phone02=,phone03=,gmtZonePhone01=343,
dstPhone01=true,gmtZonePhone02=-1,dstPhone02=true,gmtZonePhone03=-1,dstPhone03=true,
callbackNumber=,callbackDateTime=2012-08-20 21:34:42.0,callStatus=1,callResult=0,
callResult01=0,callResult02=0,callResult03=0,lastNumberDialed=0,callsMadeToPhone01=0,
callsMadeToPhone02=0,callsMadeToPhone03=0,numMissedCallback=0,isRetries=false]
//RecordID=239; campaignID=2
B-7-UNK:CMgrUtil: getPhoneNumber: callStatus=2callResult=0lastNumDialed=0
135534103: Aug 20 21:34:55.424 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getPhoneNumber:
callStatus=2callResult=0lastNumDialed=0
135534104: Aug 20 21:34:55.424 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getUnformattedPhoneNumber:
dlcID:239
135534105: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getFormattedPhoneNumber:
phoneNum=9785551212
135534106: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getFormattedPhoneNumber:
intPrefix= localAreaCode = 416 lenAreaCode = 3 include lac = true dialingPrefix = 9
longDistPrefix = 91
135534107: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getFormattedPhoneNumber():
domestic number
135534108: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getFormattedPhoneNumber():
long distance number
135534109: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:numToDial=9919785551212
135534110: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getUnformattedPhoneNumber:
dlcID:239
135534111: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getTimeZoneId -
phoneNum=9785551212
135534112: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil: getGmtOffset:
DST observed=true
135534113: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:CMgrUtil.getTimeZoneId -
phoneNum=9785551212
//Based on the Campaign config, the phone number is modified accordingly. In a failed call
scenario, you might want to verify what the number is after the formatting is done. Look
for 'MIVR-SS_OB-7-UNK:numToDial=' which gives you the actual number to be dialed.
135534128: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:OutboundIVRContactsRequestor:
Contacts returned from CampaignMgr for campaignID:2 are [OutboundContactInfo: dlc:239
(phoneNumber:9919785551212 unformattedPhoneNumber:9785551212 timezone -240
callStartTime 0 answeringMachine false ) ]
//phoneNumber:9919785551212; unformattedPhoneNumber:9785551212.
Voici les phoneNumbers formatés et non formatés :
135534131: Aug 20 21:34:55.425 EDT %MIVR-SS_OB-7-UNK:IVRDialer:findValidContact() -
processing contact in queue OutboundContactInfo: dlc:239 (phoneNumber:9919785551212
unformattedPhoneNumber:9785551212 timezone -240 callStartTime 0 answeringMachine false )
Le SIP signalant des débuts :
SIP-9919785551212 INVITE sip:9919785551212@10.10.10.7:5060;transport=udp SIP/2.0
SIP-9919785551212 SIP/2.0 100 Trying
SIP-9919785551212 SIP/2.0 183 Session Progress
SIP-9919785551212 SIP/2.0 200 OK
Vérifiez la manipulation de ces messages sur la passerelle avec la Messagerie de passerelle expliquée précédemment.
135534720: Aug 20 21:34:58.809 EDT %MIVR-SS_OB-7-UNK:ProcessAccepted: DialerSipCall-68,
State=CONTACTING, fromDN=8005553434, toDN=9919785551212,
callId=134551289542668@10.10.10.5 sending
SIP-9919785551212 ACK sip:9919785551212@10.10.10.7:5060 SIP/2.0
135534722: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:OnConnectionCompleted DialerSipCall-68,
State=ACTIVE, fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5
notify
com.cisco.wf.subsystems.outbound.SIPAdapterCallListenerImpl@1b91fa4.onConnectionCompleted()
//The initial SIP signalling is completed
135534723: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:SIPAdapterCallListenerImpl.
onConnectionCompleted post OutboundPlaceGWCallRespMsg: GWCall: dlcID: 239, csqID: -1,
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE,
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, status=OK
//The outbound subsystem posts the 'Place call' request to the gateway
135534724: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:OutboundDialerProcessor:Processing msg:
OutboundPlaceGWCallRespMsg: GWCall: dlcID: 239, csqID: -1,
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE,
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5,
status=OK135534725: Aug 20 21:34:58.810 EDT
%MIVR-SS_OB-7-UNK:IVRDialer:ProcessOutboundPlaceGWCallRespMsg:
OutboundPlaceGWCallRespMsg: GWCall: dlcID: 239, csqID: -1,
contactNumToDial:9919785551212false, dialerType:IVR_DIALER,
DialerSipCall-68, State=ACTIVE, fromDN=8005553434, toDN=9919785551212,
callId=134551289542668@10.10.10.5, status=OK
//The OutboundPlaceCall request is processed by the Outbound Dialer, then by the IVR
Dialer processes
135534728: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:CampaignStatistics:
incrementAttemptedCalls() for phoneNumber=9919785551212 to 1
135534729: Aug 20 21:34:58.810 EDT %MIVR-SS_OB-7-UNK:HalfHourCampaignData:
incrementAttemptedCalls() by 1. Total attempted calls = 1
//Since this is the first time the record is dialled out, the total attempted calls = 1
La passerelle envoie un message de MISE À JOUR de SIP avec le message de CPA. Le logiciel de CPA fonctionne sur la passerelle et analyse le Protocole RTP (Real-Time Transport Protocol) de l'appelé. Ceci aide à différencier entre la Voix et le répondeur à l'extrémité d'appelé. Vous pouvez identifier un message de MISE À JOUR de SIP de CPA par son type de contenu de « application/x-cisco-cpa ».
SIP-9919785551212 UPDATE sip:8005553434@10.10.10.5:5060;transport=udp SIP/2.0
SIP-9919785551212 Via: SIP/2.0/UDP 10.10.10.7:5060;branch=z9hG4bK2362542
SIP-9919785551212 Max-Forwards: 69
SIP-9919785551212 To: <sip:8005553434@10.10.10.5>;tag=dsaf56bbcc
SIP-9919785551212 From: <sip:9919785551212@10.10.10.7>;tag=3D33950C-948
SIP-9919785551212 Call-ID: 134551289542668@10.10.10.5
SIP-9919785551212 CSeq: 102 UPDATE
SIP-9919785551212 Content-Length: 26
SIP-9919785551212 Date: Tue, 21 Aug 2012 01:34:58 GMT
SIP-9919785551212 User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
SIP-9919785551212 Supported: timer,resource-priority,replaces,sdp-anat
SIP-9919785551212 Timestamp: 1345512899
SIP-9919785551212 Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
SIP-9919785551212 Contact: <sip:9919785551212@10.10.10.7:5060>
SIP-9919785551212 Min-SE: 1800
SIP-9919785551212 Content-Type: application/x-cisco-cpa
SIP-9919785551212 Content-Disposition: signal;handling=optional
SIP-9919785551212
SIP-9919785551212 event=detected
SIP-9919785551212 status=CpaS
SIP-9919785551212 UPDATE sip:8005553434@10.10.10.5:5060;transport=udp SIP/2.0
SIP-9919785551212 Via: SIP/2.0/UDP 10.10.10.7:5060;branch=z9hG4bK23714F6
SIP-9919785551212 Max-Forwards: 69
SIP-9919785551212 To: <sip:8005553434@10.10.10.5>;tag=dsaf56bbcc
SIP-9919785551212 From: <sip:9919785551212@10.10.10.7>;tag=3D33950C-948
SIP-9919785551212 Call-ID: 134551289542668@10.10.10.5
SIP-9919785551212 CSeq: 103 UPDATE
SIP-9919785551212 Content-Length: 163
SIP-9919785551212 Date: Tue, 21 Aug 2012 01:34:58 GMT
SIP-9919785551212 User-Agent: Cisco-SIPGateway/IOS-15.2.4.M1
SIP-9919785551212 Supported: timer,resource-priority,replaces,sdp-anat
SIP-9919785551212 Timestamp: 1345512902
SIP-9919785551212 Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE,
NOTIFY, INFO, REGISTER
SIP-9919785551212 Contact: <sip:9919785551212@10.10.10.7:5060>
SIP-9919785551212 Min-SE: 1800
SIP-9919785551212 Content-Type: application/x-cisco-cpa
SIP-9919785551212 Content-Disposition: signal;handling=optional
SIP-9919785551212
SIP-9919785551212 event=detected
SIP-9919785551212 status=LV
SIP-9919785551212 pickupT=320
SIP-9919785551212 maxActGlitchT=0
SIP-9919785551212 numActGlitch=0
SIP-9919785551212 valSpeechT=20
SIP-9919785551212 maxPSSGlitchT=0
SIP-9919785551212 numPSSGlitch=0
SIP-9919785551212 silenceP=0
SIP-9919785551212 termToneDetT=0
SIP-9919785551212 noiseTH=1000
SIP-9919785551212 actTh=32000
//This shows that Low Volume is detected. Now, based on the Campaign setting 'Handle Low
Volume as Voice,' this call is handled accordingly
135535726: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:OnCPAStatus DialerSipCall-68,
State=ACTIVE, fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5
notify com.cisco.wf.subsystems.outbound.SIPAdapterCallListenerImpl@1b91fa4.onCPAStatus
(status=LowVolume)
135535727: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:SIPAdapterCallListenerImpl.onCPAStatus
post OutboundUpdateGWCallStatusMsg: GWCall: dlcID: 239, csqID: -1,
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE,
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, status=LowVolume
135535728: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:OutboundDialerProcessor:Processing msg:
OutboundUpdateGWCallStatusMsg: GWCall: dlcID: 239, csqID: -1,
contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68, State=ACTIVE,
fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5, status=LowVolume
135535729: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg: OutboundUpdateGWCallStatusMsg: GWCall: dlcID: 239,
csqID: -1, contactNumToDial:9919785551212false, dialerType:IVR_DIALER, DialerSipCall-68,
State=ACTIVE, fromDN=8005553434, toDN=9919785551212, callId=134551289542668@10.10.10.5,
status=LowVolume
135535730: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg(): Low Volume detected
135535731: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg(): Handle Low Volume as Voice is true
135535732: Aug 20 21:35:02.036 EDT %MIVR-SS_OB-7-UNK:IVRDialer:
ProcessOutboundUpdateGWCallStatusMsg(): PostingOutboundIVRUpdateContactMsg with
callstatus = 3(Closed), callresult = 1(Low Volume) for dlcID = 239
Problèmes courants
Aucun CPA n'est envoyé de la passerelle à UCCX
Après que l'appel soit connecté à l'appelant PSTN, aucun message n'est renvoyé à UCCX par la passerelle pour indiquer que CPA a été terminé et qu'un appel a résulté (vivent le répondeur de Voix, occupé, et ainsi de suite). Assurez-vous la version IOS sur les supports CPA de passerelle. Étudiez la passerelle pour vérifier CPA fonctionne correctement.
L'appel n'est pas réorienté à UCCX après que vivant expriment détecté
Vérifiez la passerelle a un cadran-pair qui apparie le numéro composé par déclencheur UCCX (DN) assigné à la campagne. Vérifiez qu'un appel de la passerelle peut conduire à ce point de routage CTI/déclencheur dans CUCM.
Des relances ne sont pas composées
Semblable aux rappels dans le numéroteur sortant d'aperçu, si des appels qui reçoivent l'ARN ou occupé ne sont pas relancés, vérifiez que ces enregistrements sont correctement marqués comme relance dans la table de DialingList. Vérifiez des logs MIVR que la tentative d'appel est faite au rappel ou à la relance spécifié.
DTMF ne fonctionne pas une fois connecté au script IVR
Vérifiez que DTMF est négocié correctement entre CUCM et la passerelle et que des cadran-pairs Désignés sont appariés (dial-peer 0 ne contient pas la configuration de relais de DTMF). UCCX prend en charge seulement DTMF hors bande par l'intermédiaire de JTAPI, ainsi quelques types de passerelle et écoulements d'appel pourraient exiger d'un Media Termination Point (MTP) d'être appelés pour se terminer l'interworking DTMF. Étudiez la passerelle pour vérifier la passerelle et CUCM traitent correctement des demandes et la négociation DTMF.
Informations connexes
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)