IVR-basierte Fehlerbehebung bei Outbound Dialer

Einführung

Dieses Dokument beschreibt den IVR-basierten Outbound Dialer und enthält eine Beispiel-SIP-Gateway-Konfiguration, Protokollanalysen vom SIP-Gateway und der Cisco Unified Contact Center Express (UCCX)-Engine sowie die Einschränkungen des IVR-basierten Outbound Dialer.

In UCCX 8.5 wurde ein neuer Typ von Outbound Dialer eingeführt: den IVR-basierten Outbound Dialer (Interactive Voice Response). Anders als beim älteren Preview Outbound Dialer wird kein Agent für ausgehende Anrufe verwendet. UCCX ist direkt mit einem SIP-Gateway (Session Initiation Protocol) im Kundenunternehmen verbunden, um die ausgehenden Kontakte zu wählen. Wenn das Gateway ein Live-Sprach- oder Anrufbeantworter erkennt, wird der Anruf an einen UCCX-Trigger umgeleitet, der an eine ausgehende Anrufsteuerungsgruppe gebunden ist. Sobald die Verbindung mit dem CTI-Anschluss (Outbound Computer Telefony Integration) hergestellt ist, wird die dem Trigger zugeordnete Anwendung normal ausgeführt.

Informationen zu Funktionen

In UCCX-Versionen vor Version 8.5 gab es nur den Preview Outbound Dialer (Preview-Wählprogramm für ausgehende Anrufe). Dieser Wähler nutzte die Anrufsteuerung eines Drittanbieters über Java Telefony Application Programming Interface (JTAPI)/CTI, um das Telefon des Agenten anzuweisen, den Anruf zu tätigen. Der Anruf wurde getätigt, nachdem ein Mitarbeiter eine ausgehende Reservierung akzeptiert hatte. Die Interaktion zwischen Client und Server bei ausgehenden Reservierungen wurde über CTI realisiert.

Für bestimmte Anwendungsfälle (wie Terminerinnerungen und Self-Service-IVR-Anwendungen) war der Preview Outbound Dialer nicht geeignet. Um einen Anruf an eine Nummer in der Wählliste zu tätigen, wurde ein Agent während des Anrufs gebunden. Das bedeutete, dass der Mitarbeiter für jeden ausgehenden Anruf beschäftigt war, selbst wenn die PSTN-Nummer ungültig oder besetzt war oder zu einem Anrufbeantworter führte. Diese hohe Agentenauslastung war ein großer Nachteil von Preview Outbound Dialer für diese Anwendungsfälle.

IVR-basierter ausgehender Anrufablauf

Für dieselben Anwendungsfälle (Terminerinnerungen und Self-Service-IVR-Anwendungen) im IVR-basierten Outbound Dialer ist ein Mitarbeiter möglicherweise nie in den Anrufverlauf involviert. Dies ist der Anruffluss für IVR-basiertes Outbound Dialer:

1. Der ausgehende IVR-Wähler bestimmt die Anzahl der zu wählenden Kontakte (wie im Algorithmus definiert) und verwendet SIP, um ausgehende Anrufe über das Sprach-Gateway zu tätigen.
2. Das Sprach-Gateway erkennt den nicht-aktiven Kontakt mit seinen Funktionen zur Anruffortschrittsinformation (Call Progress Analysis, CPA) und sendet den Status des nicht-aktiven Kontakts an den Wähler. Der Wähler aktualisiert die Kontaktstatusinformationen in der Konfigurationsdatenbank.
3. Das Sprach-Gateway erkennt den Live-Kontakt mit seinen CPA-Funktionen und sendet den Status des Live-Kontakts an den Wähler. Der Wähler aktualisiert die Kontaktstatusinformationen in der Konfigurationsdatenbank und sendet außerdem eine SIP-Weiterleitungsmeldung an das SIP-Gateway, das den Anruf wiederum an den konfigurierten CTI-Weiterleitungspunkt im Cisco Unified Communications Manager (CUCM) weiterleitet.
4. Der CUCM leitet den Anruf an einen IVR-Port des Cisco UCCX-Servers weiter.
5. Das IVR-Subsystem ordnet den Anruf der IVR-Anwendung zu, die der Kampagne zugeordnet ist. Die Engine startet die Ausführung der Anwendung, und zwischen der IVR-Anwendung für die Kampagne auf UCCX und dem Kundenkontakt findet eine IVR-Sitzung statt.

IVR-basierte Wähltypen

Es gibt zwei Arten von IVR-basierten Outbound Dialern: Progressive und Progressive. Da UCCX nur einen Anruf an einen IVR-Port weiterleitet, um ein Skript auszuführen, wenn eine Live-Sprache (oder ein konfigurierbares Anrufbeantworter) erkannt wird, kann davon ausgegangen werden, dass nicht jeder ausgehende Kontakt einen Port benötigt. Um die Wahrscheinlichkeit, dass ein CTI-Port benötigt wird, gegen die Wahrscheinlichkeit abzuwägen, dass Ring-Keine Antwort (RNA), belegte und ungültige Zahlen vorliegen, verändern prädiktive und progressive Wähler die Anzahl der ausgehenden Anrufe, die gleichzeitig getätigt werden, im Verhältnis zur Anzahl der konfigurierten ausgehenden CTI-Ports.

Ein vorausschauender IVR-basierter Outbound Dialer bietet folgende Funktionen:

• Die Anzahl der Leitungen für jeden Port kann abhängig von der Rate abgebrochener Anrufe eingestellt werden.
• Es ist kein manueller Eingriff erforderlich.
• Das Ziel besteht darin, genügend Leitungen zu wählen, um die IVR-Ports betriebsbereit zu halten, jedoch nicht die konfigurierte maximale Anzahl abgebrochener Anrufe zu überschreiten.

Ein progressiver IVR-basierter Outbound Dialer bietet folgende Funktionen:

• Sie können eine feste Anzahl von Leitungen festlegen, die immer für jeden verfügbaren IVR-Port für ausgehenden Datenverkehr gewählt werden.
• Die Anzahl der Posten kann zu einem späteren Zeitpunkt aktualisiert werden.
• Wenn es für jeden Port drei Leitungen gibt und die dedizierte Anzahl der Ports für ausgehende Anrufe drei beträgt, werden neun Anrufe (3x3) gewählt.
• Ein abgebrochener Anruf tritt auf, wenn ein Kunde das Telefon annimmt, aber kein Anschluss zur Aufforderung des Kunden verfügbar ist.
• Sie können Standardeinstellungen definieren.

Dialer-Komponenten mit UCCX

Alle Funktionen und internen Subsysteme werden abstrahiert, um diesem neuen IVR-basierten Outbound Dialer Rechnung zu tragen. Systemkomponenten im neuen Dialer, wie die Engine-Tabelle und die DialingList-Tabelle, sind mit den Systemkomponenten im Preview Outbound Dialer identisch, wobei Nebenanschlüsse (wie mehr CallStatus- und CallResult-Werte) hinzugefügt werden.

Gateway-Funktionsinformationen

Um die Erkennung von Live-Sprachübertragungen, Anrufbeantwortern und speziellen Informationstönen (SIT) zu unterstützen, muss das Gateway die CPA-Funktion unterstützen. Verwenden Sie den Cisco Feature Navigator, um die Cisco IOS^® Versionen für das Gateway zu ermitteln, die SIP Dialer und CPA unterstützen. Suchen Sie mithilfe der Suche nach Funktion nach "Serviceability Support for SIP Dialer and Call Progress Analysis" (Benutzerfreundlichkeitsunterstützung für SIP-Dialer und Anruffortschrittsanalyse).

Wie wirkt CPA?

Es gibt drei Hauptfunktionen in CPA:

• AMD (Answering Machine Detection)
• Fax-/Modemerkennung
• Automatisch terminierende Tonerkennung annehmen

Es gibt komplexe Algorithmen, um diese Unterschiede zu machen, aber aus funktionaler Perspektive:

• Es wird erwartet, dass eine Live-Party-Antwort eine kurze Begrüßung und dann eine Zeit des Schweigens sein wird.
  Beispiel: "Hallo" + Stille
  Beispiel: "Hello, Johnson Residence" + Stille
• Ein Anrufbeantworter soll eine längere Anrede, aber keine Stille sein.
  Beispiel: "Sie sind in der Residenz Miller angekommen. Bitte hinterlassen Sie nach dem Signalton eine Nachricht."
• Ein Terminierungston eines Anrufbeantworters, der den Anrufbeantworter erkennt, muss erkannt werden, gefolgt von einer Pausenmeldung und einem abschließenden Ton.
• Bei einer Faxerkennung wird der Faxton erkannt.

Die Möglichkeit, diese Unterscheidungsmerkmale vorzunehmen, kann schwierig sein. Sie müssen daher möglicherweise die Timing-Parameter anpassen, um die Konfiguration zu optimieren.

Ein weiterer zu berücksichtigender Faktor ist, dass die Mobilfunkanbieter unterschiedliche Verzögerungen zwischen der Präsentation eines Anrufs bei ihnen, dem Standort der Zelle und der Präsentation des Anrufs an die Zelle selbst haben können.

Dies ist ein Beispiel für die Berechnung:

1. UCCX sendet eine SIP-Einladung an das Gateway (T1).
2. Gateway sendet eine ISDN-Anrufeinrichtung an Service Provider und Mobilfunkanbieter (T2).
3. Mobiltelefon klingelt und startet den Timer für keine Antwort (T3)
4. Zellen-RNA-Timer läuft ab und leitet sie an Voicemail (T4) weiter

Wenn Sie annehmen, dass der RNA-Timer für die Zelle 15 Sekunden beträgt, beträgt die tatsächliche Zeit, die ein Anruf an eine Zelle für die Weiterleitung an die Voicemail benötigt, (T1 + T2 + T3 + 15). T1 + T2 + T3 könnte deutlich länger sein als die Zeit, die erforderlich ist, um einen Anruf an ein Festnetzgerät oder ein anderes Gerät außerhalb des Mobilfunknetzes weiterzuleiten.

Wenn Sie also die Obergrenze für den Klingelton "No Answer" (Keine Antwort) für eine Kampagne festlegen, muss der Zeitraum ausreichend lang sein, um das Voicemail-System für Mobiltelefone zu erreichen. Dies wäre beispielsweise das gewünschte Verhalten für eine Kampagne, die eine Nachricht hinterlassen soll.

Hinweis: CPA ist eine Funktion des Gateways. Im Gegensatz zu Cisco Unified Contact Center Enterprise (UCCE) kann CPA auf UCCX nicht aktiviert oder deaktiviert werden. CPA kann zwar auf dem Gateway deaktiviert werden, Cisco rät davon jedoch ab. Weitere Informationen finden Sie unter Übersicht über die Anruffortschritts-Analyse.

Die Auswahl von IOS-Gateway-Codes geht über den Rahmen dieses Dokuments hinaus. Der Gateway-Code muss CPA und SIP Dialer unterstützen, um IVR-basierten Outbound Dialer verwenden zu können. Mit dem Cisco Feature Navigator können Sie IOS-Versionen finden, die die Funktionsanforderungen erfüllen. Stellen Sie sicher, dass Ihre IOS-Version mit allen Komponenten kompatibel ist, die mit diesem Gateway interagieren.

Fehlerbehebung

Hinweis: Verwenden Sie das Command Lookup Tool (nur registrierte Kunden), um weitere Informationen zu den in diesem Abschnitt verwendeten Befehlen zu erhalten.

Bestimmen Sie zur Fehlerbehebung bei einem IVR für ausgehende Anrufe, ob das Gateway, der CUCM oder UCCX Fehler aufweisen. Die Fehlerbehebung ist einfacher, wenn Sie das Problem auf eine bestimmte Komponente zurückführen. Es ist hilfreich, diese Informationen von den Systemkomponenten zu erfassen.

Führen Sie für das Kabelmodem die folgenden Befehle aus:

1. Showtechnik
2. Debugging-CSIP-Meldungen
3. debuggen voip ccapi inout
4. debug isdn q931 (oder ähnliches Debuggen zum Erfassen der PSTN-seitigen Signalisierung)
5. debug voip hpi all (zur Fehlerbehebung bei CPA)
6. debug voip vtsp all (zur Fehlerbehebung bei CPA)

Überprüfen Sie für UCCX Protokolldateien und -konfigurationen:

1. MIVR-Protokolldateien mit aktiviertem SS_OB-Debuggen und XDebug1 - XDebug3
2. JTAPI-Protokolldateien (zur Fehlerbehebung bei REFER-Anrufausfall)
3. SIP-Gateway-Konfiguration von UCCX AppAdmin

Überprüfen Sie für den CUCM die Konfigurationen:

1. Detaillierter CallManager
2. Detaillierter CTIManager
3. SIP-Trunk-Konfiguration, die auf das für ausgehende IVR verwendete Gateway verweist

Datenanalyse

Das SIP-Gateway muss die erforderliche Konfiguration enthalten, nicht nur um Anrufanfragen von UCCX an das PSTN weiterzuleiten, sondern auch um die Weiterleitung dieser Anrufe an den für ausgehende Anrufe festgelegten UCCX-Trigger zu verarbeiten. Diese SIP-Gateway-Konfiguration muss folgende Merkmale aufweisen:

1. Eingehende Dial-Peers, um eingehende SIP-Anfragen von UCCX abzugleichen.
2. Outbound-Dial-Peers (entweder VoIP oder Plain Old Telefone Service [POTS]) zur Weiterleitung von Anrufen an das PSTN.
3. Ausgehende Dial-Peers (VoIP) zur Weiterleitung des umgeleiteten (REFERed) Anrufs an den in UCCX integrierten CUCM-Cluster.

Der CUCM-Server muss so konfiguriert werden, dass er eingehende SIP-Anrufanfragen vom SIP-Gateway (den REFER-Anrufen) empfängt und die Anfragen entsprechend an den UCCX-Trigger und die CTI-Ports der UCCX-Anrufsteuerungsgruppe weiterleitet.

SIP-Gateway-Beispielkonfiguration

Dies ist ein Beispiel für eine SIP-Gateway-Konfiguration mit Anmerkungen. Die PSTN-Konnektivität in diesem Beispiel ist die ISDN Primary Rate Interface (PRI).

Hinweis: Andere Arten von TDM-Verbindungen (Time Division Multiplexing) werden unterstützt, Cisco Unified Border Element (CUBE) wird jedoch nicht unterstützt. Weitere Informationen zur CUBE-Unterstützung finden Sie in den Cisco Bug-IDs CSCui62525 und CSCuf44826. Es werden mehrere Verbindungen zum TDM-PSTN unterstützt, um verschiedene Anrufklassen (lokal, über große Entfernungen oder international) an verschiedene Trunks oder Provider weiterzuleiten.

RyanIVRRouter#show run
Building configuration...

Für ISDN PRI konfigurierter T1-Controller

!
controller T1 0/0/0
 cablelength long 0db
 pri-group timeslots 1-24
!

Für ISDN PRI konfigurierte serielle Schnittstelle

!
interface Serial0/0/0:23
 no ip address
 encapsulation hdlc
 isdn switch-type primary-ni
 isdn incoming-voice voice
 no cdp enable
!

Sprach-Port für die Weiterleitung ausgehender Anrufe an das PSTN

!
voice-port 0/0/0:23
!

Eingehender VoIP-DFÜ-Peer

Dieser Dial-Peer stimmt mit eingehenden SIP-Anrufanfragen von UCCX überein. Wenn kein eingehender VoIP-Dial-Peer konfiguriert ist, wird der Standard-Dial-Peer (Dial-Peer 0) zugeordnet. Es empfiehlt sich, einen eingehenden VoIP-Dial-Peer zu definieren und zuzuordnen. Dieser DFÜ-Peer benachrichtigt das Gateway über den Codec, das Protokoll und das DTMF-Relay (Dual-Tone Multifrequency), der auf der eingehenden SIP-Strecke von UCCX verwendet wird.

Dieser DFÜ-Peer stimmt alle eingehenden SIP-INVITEs mit einem DNIS-Dienst (Digital Number Identification Service) überein, der mit 717 beginnt und zehn Ziffern umfasst. In diesem Beispiel befinden sich alle von UCCX gewählten Kontakte im Ortscode 717 und haben eine zehnstellige Telefonnummer.

!
dial-peer voice 100 voip
 description -- Outbound Calls From UCCX -- 
 session protocol sipv2
 incoming called-number 717.......
 dtmf-relay rtp-nte
 codec g711ulaw
!

POTS-DFÜ-Peer

Dieser DFÜ-Peer leitet Anrufe über die zuvor konfigurierte PRI an das PSTN weiter. Es ist der ausgehende Dial-Peer für Anrufanfragen von UCCX und der ausgehende Dial-Peer für den VoIP-Dial-Peer 100 oben. Dieser DFÜ-Peer dient auch als eingehender DFÜ-Peer für Anrufe, die vom PSTN zu Testzwecken eingehen. Im ausgehenden UCCX-Dialer-Anruffluss wird dieser Dial-Peer nicht als eingehender Dial-Peer zugeordnet.

!
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
!

Outbound VoIP Dial-Peer

Dieser Dial-Peer fungiert als ausgehender Dial-Peer, der vom SIP-Gateway benötigt wird, um Anrufe an das für den UCCX-Trigger bestimmte CUCM-Cluster weiterzuleiten. Dieser DFÜ-Peer wird vom Gateway verwendet, um die von UCCX gesendete REFER weiterzuleiten, wenn eine Live-Sprachübertragung (oder, falls vorhanden, ein Anrufbeantworter) erkannt wird. Dieser Dial-Peer definiert das Protokoll, das DTMF-Relay, den Codec und die IP-Adresse des CUCM-Knotens, über den das SIP-Gateway den umgeleiteten Anruf weiterleiten soll. Aus Redundanz- und Lastenausgleichs können mehrere DFÜ-Peers dieses Typs vorhanden sein. Sie können partitioniert werden, um Anforderungen an mehrere CUCM-Knoten im Cluster zu leiten, oder sie können bereitgestellt werden, um Umleitungen für bestimmte Trigger an verschiedene CUCM-Knoten weiterzuleiten.

In diesem Beispiel sind die UCCX-Trigger für IVR-basierte Outbound-Kampagnen 2001 und 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
!

IVR-basierte Analyse der Anrufnachverfolgung bei ausgehenden Anrufen

Dies ist eine detaillierte Analyse eines Beispiel-Messaging-Protokolls zwischen dem SIP-Gateway, UCCX und dem PSTN.

Die erste INVITE-Nachricht von UCCX weist das Gateway an, einen Anruf an die PSTN-Nummer zu tätigen. Die INVITE-Nachricht enthält die Call-ID, mit der alle Nachrichten verfolgt werden können, die diesem Anruf zugeordnet sind, sowie das Session Description Protocol (SDP) (Medienparameter).

Wichtiger noch: Die INVITE-Anfrage enthält die Parameter, die das Gateway zum Abschließen des CPA verwenden sollte. Diese Parameter werden auf den UCCX AppAdmin-Seiten konfiguriert, von UCCX jedoch nicht verwendet. Stattdessen werden sie in der INVITE-Nachricht an das Gateway gesendet und vom Gateway zur Konfiguration der digitalen Signalprozessoren (DSPs) für CPA für diesen Anruf verwendet. Diese Parameter werden daher anrufabhängig an das Gateway gesendet und können jederzeit von AppAdmin geändert werden.

UCCX sendet diese CPA-Konfigurationsattribute für jeden Anruf an das Gateway:

Parametername	Parameterwert	Vorgeschlagener Wert
Mindestdauer für Pausen (100-1000)*	Millisekunden	375
Analysezeitraum (1000-10000)*	Millisekunden	2500
Maximale Zeitanalyse (1000 - 10000)*	Millisekunden	3000
Minimale gültige Sprechzeit (50 - 500)*	Millisekunden	112
Maximale Term Tone-Analyse (1000 - 60000)*	Millisekunden	15.000

Konfigurierbare Werte werden in AppAdmin auf der Seite "SIP Gateway Configuration" (SIP-Gateway-Konfiguration) angezeigt.

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

Während der Anruf über die DFÜ-Peers des Kabelmodems verarbeitet wird, erhält UCCX die Nachricht "100 Test".

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

Wenn ein ausgehender Anruf mit einem ausgehenden DFÜ-Peer übereinstimmt, wird er mithilfe des konfigurierten TDM-Protokolls an das PSTN gesendet. In diesem Fall wird eine PRI verwendet:

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

Der Anruf geht weiter, und die Signalisierung wird zwischen dem PSTN und dem Gateway ausgetauscht. Das Gateway wird darüber benachrichtigt, dass das PSTN-Telefon mit der Warnmeldung klingelt.

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

Das Gateway sendet einen 183 Session Progress zurück an UCCX, um UCCX darüber zu informieren, dass das PSTN-Telefon klingelt. Dazu gehört auch SDP für die Medienverhandlung der Freizeichentöne.

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

Der Anruf wird auf der TDM-Strecke verbunden, während das PSTN-Telefon den Anruf entgegennahm. Das Gateway sendet eine Bestätigung in 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

Das Gateway benachrichtigt UCCX, dass der Anruf mit einem 200 OK verbunden ist. UCCX ACKs, wie es für die SIP-RFC erforderlich ist. Der 200 OK enthält auch SDP für die Medienverhandlung, wird jedoch von UCCX nicht verwendet.

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

Das Gateway erkennt den Anruffortschritt mit CPA und benachrichtigt UCCX über den Anruffortschritt durch eine Reihe von UPDATE-Nachrichten. UCCS ACKs dies, wie von der SIP RFC erforderlich.

In diesem Beispiel eines SIP-Updates lautet das Ereignis "Erkannt", und der Status lautet "CpaS".

• CpaS gibt an, dass das CPA begonnen hat.
• Wenn ein Anrufbeantworter erkannt wird, lautet der Status 'Asm'.
• Wenn der Ton des Anrufbeantworters qualifiziert ist, lautet der Status 'AsmT'.

In dieser Tabelle sind die x-cisco-cpa-Statuscodes aufgeführt, die in den SIP-Aktualisierungsnachrichten verwendet werden:

Name	Definition
FT	Fax-/Modemton
ASM	Answer Machine
AsmT	Anrufbeantworter - Abschlusston.
LS	Live-Sprache.
SitIC	SIT tone IC - Intercept - Vacant No. oder AIS usw.
SitNC	SIT-Tone-NC - kein Circuit-, Emergency- oder Trunk-Blocker
SitVC	SIT tone VC - Vacant Code
SitRO	SIT-Ton RO - Ankündigung zur Neuanordnung
SitMT	Anderer SIT-Ton
CPAs	Beginn des CPA
LV	Anruf bei geringem Volumen oder bei Luftverlust

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 sendet eine Benachrichtigung an das Gateway, um den Anruf an den Trigger umzuleiten, der dieser ausgehenden Kampagne zugewiesen ist. Das Gateway ACKs this.

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

Das Gateway muss diesen Anruf wie bei jeder normalen Anrufverarbeitung über die DFÜ-Peers am Gateway an das neue Ziel weiterleiten.

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)

Der Anruf wird vom Gateway basierend auf der Konfiguration im ausgehenden Dial-Peer weitergeleitet, der für das in der REFER enthaltene Ziel zugeordnet ist.

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

Beispiel für eine MIVR-Protokollanalyse

Diese Ausschnitte aus einem MIVR-Protokoll bieten eine Übersicht über den Anruf aus UCCX-Sicht. Aktivieren Sie diese Debug-Ebenen, um die richtigen Informationen zu erfassen:

• SS_OB - Debug, XD1, XD2, XD3
• SS_RM - Debug,XDebug1
• CFG_MGR - Debug,XDebug1 (wenn das Problem mit den Wähllistenaufzeichnungen besteht)
  

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

Hinweis: Da möglicherweise mehrere Kampagnen gleichzeitig vorhanden sind, ist es wichtig, die KampagneID und die recordID zu beachten.

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. 

Hier sind die formatierten und unformatierten Telefonnummern:

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 )

Die SIP-Signalisierung beginnt:

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

Überprüfen Sie, ob diese Meldungen auf dem Gateway mit der zuvor erläuterten Gateway-Meldung verarbeitet werden.

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

Das Gateway sendet eine SIP-UPDATE-Nachricht zusammen mit der CPA-Nachricht. Die CPA-Software wird auf dem Gateway ausgeführt und analysiert das Real-Time Transport Protocol (RTP) von der angerufenen Partei. Dadurch kann zwischen Sprach- und Anrufbeantwortern am angerufenen Ende unterschieden werden. Sie können eine CPA-SIP-UPDATE-Nachricht anhand des Inhaltstyps "application/x-cisco-cpa" identifizieren.

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

Häufige Probleme

Es wird kein CPA vom Gateway an UCCX gesendet.

Nachdem der Anruf mit dem PSTN-Anrufer verbunden wurde, werden vom Gateway keine Nachrichten mehr an UCCX gesendet, um anzuzeigen, dass CPA abgeschlossen wurde und dass ein Anruf getätigt wurde (Live-Sprache, Besetzt, Anrufbeantworter usw.). Stellen Sie sicher, dass die IOS-Version auf dem Gateway CPA unterstützt. Prüfen Sie das Gateway, um sicherzustellen, dass CPA ordnungsgemäß funktioniert.

Anruf wird nach Erkennen von Live-Sprachfunktionen nicht an UCCX umgeleitet

Überprüfen Sie, ob dem Gateway ein Dial-Peer zugewiesen ist, der mit der für die Kampagne zugewiesenen UCCX-Trigger-Rufnummer (DN) übereinstimmt. Stellen Sie sicher, dass ein Anruf vom Gateway zu diesem CTI-Routing-Point/-Trigger in CUCM weitergeleitet werden kann.

Wiederholungen werden nicht gewählt

Ähnlich wie Callbacks im Preview Outbound Dialer, müssen Sie überprüfen, ob diese Datensätze in der DialingList-Tabelle korrekt als Retry (Wiederholen) markiert sind, wenn Anrufe, die RNA empfangen oder besetzt sind, nicht erneut versucht werden. Überprüfen Sie anhand der MIVR-Protokolle, ob der Anrufversuch zur angegebenen Rückruf- oder Wiederholungszeit durchgeführt wird.

DTMF funktioniert bei Verbindung mit IVR-Skript nicht

Stellen Sie sicher, dass DTMF ordnungsgemäß zwischen dem CUCM und dem Gateway ausgehandelt wird und benannte Dial-Peers zugeordnet sind (Dial-Peer 0 enthält keine DTMF-Relay-Konfiguration). UCCX unterstützt nur Out-of-Band-DTMF über JTAPI, sodass für einige Gateway-Typen und Anrufabläufe ein Media Termination Point (MTP) aufgerufen werden muss, um das DTMF-Interworking abzuschließen. Überprüfen Sie das Gateway, um sicherzustellen, dass das Gateway und der CUCM DTMF-Anfragen und -Aushandlungen ordnungsgemäß verarbeitet.

Zugehörige Informationen

• Technischer Support und Dokumentation - Cisco Systems