Contenu

Introduction

Les informations de caractéristique

Écoulement basé sur RVI d'appel sortant

Types basés sur RVI de numéroteur

Composants de numéroteur avec UCCX

Les informations de caractéristique de passerelle

Dépanner

Analyse de données

Configuration de passerelle de SIP témoin

Analyse de suivi basée sur RVI d'appel sortant d'échantillon

Analyse de log témoin MIVR

Problèmes courants

Aucun CPA n'est envoyé de la passerelle à UCCX

L'appel n'est pas réorienté à UCCX après que vivant expriment détecté

Des relances ne sont pas composées

DTMF ne fonctionne pas une fois connecté au script IVR

Informations connexes

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 :

1. 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.

2. 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.

3. 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).

4. Le CUCM transfère l'appel vers un port IVR sur le serveur de Cisco UCCX.

5. 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é :

1. UCCX envoie un SIP invite à la passerelle (le t1)

2. La passerelle envoie un établissement d'appel RNIS au fournisseur de services et sur le fournisseur de cellules (le T2)

3. Le téléphone portable sonne et met en marche son temporisateur de pas de réponse (le T3)

4. 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.

Note: CPA est une fonctionnalité de la passerelle ; à la différence du Cisco Unified Contact Center Enterprise (UCCE), CPA ne peut pas être tourné "Marche/Arrêt" sur UCCX. Tandis que CPA peut être arrêté sur la passerelle, Cisco ne recommande pas ceci. Le pour en savoir plus, se rapportent à l'aperçu d'Analyis de progression de l'appel.

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

Note: Utilisez l'Outil de recherche de commande (clients enregistrés seulement) pour obtenir plus d'informations sur les commandes utilisées dans cette section.

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 :

1. affichez le tech

2. debug ccsip messages

3. debug voip ccapi inout

4. debug isdn q931 (ou semblables mettez au point pour capturer la signalisation de côté PSTN)

5. debug voip hpi tout (pour dépanner CPA)

6. debug voip vtsp tout (pour dépanner CPA)

Pour UCCX, fichiers journal et configuration d'examen :

1. Fichiers journal MIVR avec l'élimination des imperfections SS_OB et le XDebug1 - XDebug3 activé

2. Fichiers journal JTAPI (pour dépanner l'échec d'appel référé)

3. Configuration de passerelle de SIP d'UCCX AppAdmin

Pour le CUCM, configurations d'examen :

1. CallManager détaillé

2. CTIManager détaillé

3. 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 :

1. Homologues de numérotation en entrée pour apparier des demandes entrantes de SIP d'UCCX.

2. Homologues de numérotation en sortie (VoIP ou réseau téléphonique public commuté [POTS]) pour conduire des appels au PSTN.

3. 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).

Note: D'autres types de connectivité RTPC du multiplexage temporel (TDM) sont pris en charge, mais le Logiciel Cisco Unified Border Element (CUBE) n'est pas pris en charge. Voir les id CSCui62525 et CSCuf44826 de bogue Cisco pour plus d'informations sur le support de CUBE. De plusieurs connexions au PSTN TDM sont prises en charge pour conduire des classes différentes d'appels (gens du pays, longue distance, internationaux) à différents joncteurs réseau ou fournisseurs.

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

Note: Puisqu'il pourrait y avoir de plusieurs campagnes en même temps, il est important de prêter l'attention au campaignID et au recordID.

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&colon;

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

- Support et documentation techniques - Cisco Systems