Inhalt

Einführung

Informationen zu Funktionen

IVR-basierter ausgehender Anrufablauf

IVR-basierte Wähltypen

Dialer-Komponenten mit UCCX

Gateway-Funktionsinformationen

Fehlerbehebung

Datenanalyse

SIP-Gateway-Beispielkonfiguration

IVR-basierte Analyse der Anrufnachverfolgung bei ausgehenden Anrufen

Beispiel für eine MIVR-Protokollanalyse

Häufige Probleme

Es wird kein CPA vom Gateway an UCCX gesendet.

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

Wiederholungen werden nicht gewählt

DTMF funktioniert bei Verbindung mit IVR-Skript nicht

Zugehörige Informationen

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

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