IVR-gebaseerde probleemoplossing voor uitgaande snelkiezer

Inleiding

Dit document beschrijft de op IVR gebaseerde uitgaande snelkiezer en bevat een configuratie van de SIP-gateway, loganalyses van zowel de SIP-gateway als de Cisco Unified Contact Center Express (UCCX)-motor en de beperkingen van de op IVR gebaseerde uitgaande snelkiezer.

In UCCX 8.5 werd een nieuw type uitgaande dialer geïntroduceerd: de op Interactive Voice Response (IVR) gebaseerde uitgaande snelkiezer. In tegenstelling tot de oudere Uitgaande Kiezer van de Voorbeeld wordt geen agent gebruikt om de uitgaande vraag te maken. UCCX sluit rechtstreeks aan op een Session Initiation Protocol (SIP)-poort in de klantonderneming om de uitgaande contacten te bellen. Wanneer de gateway een levende stem of antwoordmachine detecteert, wordt de vraag opnieuw gericht naar een UCCX trigger die aan een uitgaande gesprekscontrolegroep wordt gebonden. Zodra beëindigd op de uitgaande computer telefonie integratie (CTI) poort, wordt de toepassing die met de trigger verbonden is uitgevoerd als normaal.

Functieinformatie

In UCCX-versies eerder dan 8.5 bestond alleen de Preview Outbound Dialer. Deze dialer gebruikte gespreksbeheer van derden via Java Telephony Application Programming Interface (JTAPI)/CTI om de telefoon van de agent te instructies om het gesprek te maken. De oproep werd gedaan nadat een beambte een reservering had geaccepteerd. De interactie tussen de client en server voor uitgaande reserveringen werd gerealiseerd via CTI.

Voor bepaalde gebruiksgevallen (zoals aanstellingsaanmaningen en zelfservice IVR-toepassingen) was de Preview-keuzeknop niet geschikt. Om een aantal in de DialingList te maken, werd een agent verbonden terwijl de vraag werd geplaatst. Dat betekende dat de agent werd bezet voor elke uitgaande oproep, zelfs als het PSTN-nummer (Public Switched Telephony Network) ongeldig was, druk bezig was of resulteerde in een antwoordapparaat. Dit hoge niveau van gebruik van middelen was een belangrijke terugslag van de Preview Outbound Dialer voor deze gebruiksgevallen.

IVR-gebaseerde uitgaande CallFlow

Voor hetzelfde gebruik (aanstellingsherinneringen en zelfservice IVR-toepassingen) in de IVR-gebaseerde uitgaande snelkiezer, kan een agent nooit bij de aanloopstroom betrokken zijn. Dit is de aanroep stroom voor IVR-gebaseerde uitgaande snelkiezer:

1. De uitgaande IVR-dialer bepaalt het aantal contacten om te bellen (zoals gedefinieerd in het algoritme) en gebruikt SIP om uitgaande oproepen door de spraakgateway te plaatsen.
2. De spraakgateway detecteert niet-rechtstreeks contact met de mogelijkheden van de Call Progress Analysis (CPA) en stuurt de status van het niet-live contact naar het dialer. De dialer werkt de informatie van de contactstatus in de configuratiegegevensbestand bij.
3. De spraakgateway detecteert live contact met de CPA-functies en verstuurt de status van het live contact naar het dialer. Het dialer werkt de informatie van de contactstatus in de configuratiegegevensbestand bij en stuurt ook een SIP verwijzingsbericht naar de SIP gateway, die, op zijn beurt, de vraag naar het gevormd CTI routepunt op de Cisco Unified Communications Manager (CUCM) overbrengt.
4. Het CUCM transporteert de aanroep naar een IVR-poort op de Cisco UCCX-server.
5. Het IVR-subsysteem associeert de oproep met de IVR-toepassing die aan de campagne is gekoppeld. De motor begint met de uitvoering van de toepassing en er vindt een IVR-sessie plaats tussen de IVR-toepassing voor de campagne op UCCX en de klant-contactpersoon.

Op IVR gebaseerde kiesfunctietypen

Er zijn twee soorten op IVR gebaseerde Outbound Dialers, voorspellend en progressief. Omdat UCCX alleen een aanroep naar een IVR-poort overdraagt om een script uit te voeren wanneer een live spraak (of een configureerbare antwoordmachine) wordt gedetecteerd, is het redelijk om aan te nemen dat niet elk uitgaande contact een poort vereist. Om de kans dat een haven van CTI tegen de waarschijnlijkheid in balans is dat Ring Geen Antwoord (RNA), druk en ongeldig cijfersituaties bestaan, veranderen voorspelbare en progressieve dialers het aantal uitgaande oproepen die in een tijd tegen het aantal geconfigureerde uitgaande havens van CTI worden gemaakt.

Een voorspellende IVR-gebaseerde uitgaande snelkiezer heeft deze functies:

• Het aantal lijnen voor elke haven kan worden aangepast, op basis van het verlaten telefoontarief.
• Er is geen handmatige interventie nodig.
• Het doel is om genoeg lijnen te draaien om de havens IVR bezig te houden maar niet om het gevormde maximum verlaten tarief te overschrijden.

Een progressieve IVR-gebaseerde uitgaande snelkiezer heeft deze functies:

• U kunt een vast aantal lijnen instellen die altijd voor elke beschikbare uitgaande IVR-poort worden geselecteerd.
• Het aantal lijnen kan op een latere datum worden bijgewerkt.
• Als er drie lijnen zijn voor elke haven en het toegewezen aantal havens voor verlaten drie is, dan worden negen vraag (3x3) geselecteerd.
• Een verlaten vraag komt voor wanneer een klant de telefoon beantwoordt, maar geen haven is beschikbaar om de klant te vragen.
• U kunt standaardinstellingen definiëren.

Kiezeronderdelen met UCCX

Alle functionaliteit en interne subsystemen worden geabstraheerd om rekening te houden met deze nieuwe IVR-gebaseerde uitgaande snelkiezer. De componenten van het systeem in het nieuwe dialer, zoals de tabel Engine en DialingList, zijn dezelfde als in de tabel Uitgaande Voorbeeld, met toegevoegde uitbreidingen (zoals meer CallStatus en CallResultaatwaarden).

Informatie over gateways

Om de detectie van live spraak, antwoordapparaat en speciale informatietonen (SIT) te ondersteunen, moet de toegangspoort de CPA-functie ondersteunen. Gebruik de navigator van de Functie van Cisco om de gateway Cisco IOS zinnige versies te bepalen die SIP dialer en CPA ondersteunen; Gebruik de zoekopdracht 'Zoeken naar optie' voor 'Ondersteuning van service voor SIP-dialer en analyse van gespreksvoortgang.'

Hoe werkt CPA?

Er zijn drie primaire functies in CPA:

• Apparaatdetectie (AMD)
• Detectie van fax/modem
• Het beantwoorden van de toondetectie van de machine

Er worden complexe algoritmen geïmplementeerd om dit onderscheid te maken, maar vanuit een functioneel stand point:

• Een rechtstreeks antwoord van een partij zal naar verwachting een korte salutatie zijn, daarna een periode van stilte.
  Voorbeeld: "Hallo" + stilte
  Voorbeeld: "Hallo, Johnson residentie" + stilte
• Een antwoordapparaat zal naar verwachting een langer salutatie zijn, dan geen stilte.
  Voorbeeld: "Je hebt de verblijfplaats van Miller bereikt, laat een bericht achter na de piep"
• Een antwoordapparaat terminating tone detectie is verwacht van de antwoordmachine, dan zwijgen, dan een terminating tone.
• Een fax-detectie is herkenning van de faxtoon.

De mogelijkheid om deze afwijkingen te maken kan moeilijk zijn, zodat u de tijdparameters moet aanpassen om de configuratie te optimaliseren.

Een andere factor om over na te denken is dat aanbieders van mobiele telefoons verschillende gradaties van vertraging kunnen hebben tussen de presentatie van een aanroep, de locatie van de cel en de presentatie van de aanroep aan de cel zelf.

Dit is een voorbeeld van de berekening:

1. UCCX stuurt een SIP-oproep naar de poort (T1)
2. Gateway stuurt een ISDN-aanroep naar serviceprovider en naar mobiele provider (T2)
3. Telefoonringen van mobiele telefoon en start zijn geen antwoordtimer (T3)
4. De timer van Cell RNA verloopt en stuurt naar voicemail (T4)

Als u ervan uitgaat dat de RNA-timer voor de cel 15 seconden is, is de werkelijke hoeveelheid tijd die nodig is voor een verbinding naar een cel om door te sturen naar voicemail (T1 + T2 + T3 + 15). T1 + T2 + T3 zou aanzienlijk hoger kunnen zijn dan de tijd die nodig is om een oproep aan een vaste lijn of ander niet-celapparaat in te dienen.

Dus, wanneer u de ringlimiet van het antwoord van Geen voor een campagne definieert, moet de tijd lang genoeg zijn om het voicemail systeem voor mobiele telefoons te bereiken; dat zou bijvoorbeeld het gewenste gedrag zijn voor een campagne die een boodschap moet achterlaten .

Opmerking: CPA is een functionaliteit van de poort; in tegenstelling tot Cisco Unified Contact Center Enterprise (UCCE) kan CPA niet op UCCX worden ingeschakeld of uit. Terwijl CPA op de gateway kan worden uitgeschakeld, adviseert Cisco dit niet. Raadpleeg voor meer informatie de Call Progress Analyse - Overzicht.

Selecteren van IOS-gatewaycodes valt buiten het bereik van dit document. De gateway-code moet CPA en SIP-dialer ondersteunen om IVR-gebaseerde uitgaande snelkiezer te gebruiken. De navigator van de Functie van Cisco kan u helpen IOS releases te vinden die aan eigenschapvereisten voldoen. Zorg er altijd voor dat uw IOS release compatibel is met alle onderdelen die op deze gateway reageren.

Problemen oplossen

Opmerking: Gebruik de Command Lookup Tool (alleen voor geregistreerde gebruikers) voor meer informatie over de opdrachten die in deze sectie worden gebruikt.

Om een uitgaande IVR-account op te lossen, dient u te bepalen of de gateway, CUCM of UCCX defect is. Problemen oplossen is gemakkelijker wanneer u het probleem met een bepaalde component hebt geïsoleerd. Het is nuttig deze informatie bij de systeemcomponenten te verzamelen

Start deze opdrachten voor de gateway:

1. toontechniek
2. csip-berichten debug
3. voip ccapi inout debug
4. debug van ISDN Q931 (of vergelijkbaar debug om PSTN-zijsignalering op te nemen)
5. voip hpi all debug (in probleemoplossing CPA)
6. voip vtsp all (naar probleemoplossing CPA)

Bekijk voor UCCX de logbestanden en de configuratie:

1. MIVR-logbestanden met SS_OB Debugging en XDebug1 - XDebug3 ingeschakeld
2. JTAPI-logbestanden (voor problemen oplossen met REFERed Call defect)
3. SIP-poortconfiguratie via UCCX AppAdmin

Voor CUCM-configuraties:

1. Gedetailleerde CallManager
2. Gedetailleerde CTIManager
3. SIP-trunkconfiguratie die naar de gateway wijst die wordt gebruikt voor uitgaande IVR

Gegevensanalyse

De SIP-gateway moet niet alleen de benodigde configuratie bevatten om telefoonverzoeken van UCCX naar het PSTN te verzenden, maar ook om de overdracht van die oproepen naar de UCCX-trigger die voor uitzending is aangewezen, af te handelen. Deze SIP gateway-configuratie moet zijn:

1. Ingebonden kiespeers om inkomende SIP-verzoeken van UCCX aan te passen.
2. Uitgaande kiespeers (VoIP of gewoon oude telefoonservice [POTS]) om oproepen naar het PSTN te sturen.
3. Uitgebreide dial-peers (VoIP) om de hergerichte (REFERed) vraag naar de CUCM-cluster te leiden die met UCCX geïntegreerd is.

De CUCM server moet worden geconfigureerd om inkomende SIP-aanspreekverzoeken te ontvangen van de SIP-gateway (de REFERed-aanroepen) en de verzoeken dienovereenkomstig te verzenden naar de UCCX-trigger en de UCCX Call Control Group CTI-poorten.

Configuratie van SIP-gateway

Dit is een voorbeeld van een SIP gateway configuratie met notaties. De PSTN-connectiviteit in dit voorbeeld is ISDN Primaire Rate Interface (PRI).

Opmerking: Andere soorten time Division Multiplexing (TDM) PSTN-connectiviteit worden ondersteund, maar Cisco Unified Border Element (CUBE) wordt niet ondersteund. Zie Cisco bug-ID’s CSCui62525 en CSCuf4826 voor meer informatie over CUBE-ondersteuning. Meervoudige verbindingen met het TDM PSTN worden ondersteund om verschillende klassen gesprekken (lokaal, lange afstand, internationaal) naar verschillende stammen of aanbieders te leiden.

RyanIVRRouter#show run
Building configuration...

T1 controller geconfigureerd voor ISDN PRI

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

Seriële interface geconfigureerd voor ISDN PRI

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

Spraakpoort voor routing naar PSTN

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

Ingebonden VoIP-dial-peers

Deze dial-peers past inkomende SIP vraagverzoeken van UCCX aan. Als een inkomende VoIP dial-peer niet wordt gevormd, wordt de standaard wijzerplaat-peer (wijzerplaat-peer 0) geëigend. Het is best practice om een inkomende VoIP-dial-peer te definiëren en vergelijken. Deze dial-peers meldt de gateway van het codec, protocol en dual-tone multifrequentie (DTMF) relais die op het inkomende SIP-been van UCCX moet worden gebruikt.

Deze dial-peers past alle inkomende SIP INVITEs met een Digital Number Identification Service (DNIS) aan die met 717 begint en die 10 cijfers lang zijn. In dit voorbeeld, zijn alle contacten die door UCCX worden gedraaid in de 717 gebiedscode en hebben telefoonnummers 10 lange cijfers.

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

POTS-dial-peers

Deze dial-peers routeert naar PSTN over de PRI die eerder werd gevormd. Het is de uitgaande dial-peer voor vraagverzoeken die van UCCX en de uitgaande wijzerplaat-peer voor VoIP wijzerplaat-peer 100 hierboven komen. Deze dial-peer dient ook als een inkomende wijzerplaat-peer voor vraag die van PSTN voor testdoeleinden komt. In de UCCX uitgaande dialer aanroep flow, wordt deze dial-peer niet gevat als een inkomende dial-peer.

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

Uitgaande VoIP-dial-peers

Deze dial-peer dient als de uitgaande wijzerplaat-peer die door de SIP gateway nodig is om oproepen naar de CUCM cluster te leiden die voor de UCCX trigger bestemd is. Deze dial-peer wordt gebruikt door de gateway om de REFER te leiden die door UCCX wordt verzonden wanneer de levende stem (of de antwoordmachine als de configuratie bestaat) wordt gedetecteerd. Deze wijzerplaat-peer definieert het protocol, DTMF relais, codec en IP adres van het knooppunt van CUCM waar de SIP gateway de hergerichte vraag zou moeten leiden. Voor redundantie en taakverdeling zouden er meerdere kiespeers van dit type kunnen bestaan. Ze zouden kunnen worden gesplitst naar routeverzoeken naar meerdere CUCM-knooppunten in de cluster of aan route-omleidingen voor bepaalde triggers naar verschillende CUCM-knooppunten kunnen worden toegewezen.

In dit voorbeeld zijn UCCX triggers voor IVR-gebaseerde uitgaande campagnes 2001 en 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
!

Monster van IVR-gebaseerde analyse van uitgaande gesprekken

Dit is een gedetailleerde analyse van een voorbeeldberichtenlog tussen de SIP gateway, UCCX en PSTN.

De eerste INVITE van UCCX geeft de gateway opdracht om een verbinding naar het PSTN-nummer te maken. INVITE bevat de Call-ID, die kan worden gebruikt om alle berichten te volgen die bij deze oproep horen, en het Session Description Protocol (SDP) (mediaspelers).

Belangrijker is dat het INVITE de parameters bevat die de toegangspoort zou moeten gebruiken om de CPA te voltooien. Deze parameters worden ingesteld in de pagina's van UCCX AppAdmin, maar worden niet gebruikt door UCCX. Zij worden in het INVITE naar de poort gestuurd en door de poort gebruikt om de digitale signaalprocessors (DSP's) voor CPA te configureren voor deze oproep. Als resultaat hiervan worden deze parameters verzonden naar de gateway per vraag en kunnen op elk moment van AppAdmin worden gewijzigd.

UCCX stuurt deze CPA configuratie eigenschappen naar de gateway voor elke oproep:

Parameter Naam	Parameter Waarde	Aanbevolen waarde
Minimumstilheidsperiode (100 - 1000)*	Milmilliseconden	375
Analyseperiode (1000 - 10000)*	Milmilliseconden	2500
Maximale tijdanalyse (1000 - 10000)*	Milmilliseconden	3000
Minimale geldige spreektijd (50 - 500)*	Milmilliseconden	112
Maximale tijdsanalyse (1000 - 60000)*	Milmilliseconden	15000

De configureerbare waarden worden in AppAdmin weergegeven op de pagina met SIP-gateway.

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

Aangezien de vraag door de wijzerplaat-peers van de gateway verwerkt, wordt UCCX verzonden een bericht van '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

Wanneer de uitgaande vraag overeenkomt met een uitgaande bel-peer, wordt deze naar het PSTN verzonden met behulp van het geconfigureerde TDM-protocol. In dit geval wordt een PRI gebruikt:

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

De vraag vordert en de signalering wordt uitgewisseld tussen het PSTN en de poort. De poort wordt op de hoogte gesteld dat de PSTN-telefoon met het ALERTING-bericht belt.

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

De gateway stuurt een 183 Session Progress terug naar UCCX om UCCX te laten weten dat de PSTN-telefoon rinkelt. Dit omvat SDP voor media onderhandeling over de ringbandtonen.

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

De vraag wordt aangesloten op het TDM been aangezien de telefoon PSTN op de vraag beantwoordde. De poort stuurt een bevestiging 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

De gateway meldt UCCX dat de verbinding tot 200 OK heeft. UCCX ACK's deze, zoals vereist door de SIP RFC. Het OK van 200 OK bevat ook SDP voor mediaonderhandeling, maar het wordt niet door UCCX gebruikt.

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

De gateway detecteert de gespreksvoortgang met CPA en waarschuwt UCCX van de telefoonvoortgang door een reeks UPDATE-berichten. UCS ACKs dit, zoals vereist door de SIP RFC.

In dit voorbeeld van een update van het SIP is de gebeurtenis "herkend" en de status is "CpaS".

• CpaS geeft aan dat de CPA is begonnen.
• Wanneer een antwoordapparaat wordt gedetecteerd, is de status 'Asm'.
• Wanneer de toon van de antwoordmachine is gekwalificeerd, is de status 'AsmT'.

Deze tabel bevat de statuscodes van x-cisco-pa die in de SIP-update-berichten worden gebruikt:

Name	Definitie
FT	Fax/modem.
ASM	Antwoordmachine.
AsmT	Tone van antwoordmachine eindigen.
LS	Live menselijke toespraak.
SitIC	SIT tone IC - Intercept - Vacant Nr. of AIS enzovoort.
SitNC	SIT-tint NC - geen Circuit-, Noodtoestand- of Trunkblokkering
SitVC	SIT-tint VC - vluchtige-code
SitRO	SIT-toon RO - aankondiging van herschikking
SitMT	Misc SIT-toon
CpaS	Begin van de CPA
LV	Lage volume of dode lucht

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 stuurt een kennisgeving naar de gateway om de aanroep om te sturen naar de trigger die aan deze uitgaande campagne is toegewezen. De toegangspoort is dit.

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

De gateway moet deze vraag naar de nieuwe bestemming zoals om het even welke normale telefoonverwerking door de wijzerplaat-peers op de gateway leiden.

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)

De verbinding wordt door de gateway gestuurd op basis van de configuratie in de uitgaande wijzerplaat-peer die voor de bestemming in de REFER is afgestemd.

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

MIVR-loganalyse

Deze fragmenten uit een MIVR-logbestand bieden een overzicht van de oproepen vanuit een UCCX-perspectief. Schakel deze debug-niveaus in om de juiste informatie op te nemen:

• SS_OB - Debug,XD1,XD2,XD3
• SS_RM - Debug,XDebug1
• CFG_MGR - Debug,XDebug1 (als het probleem is met het draaien van lijstrecords)
  

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

Opmerking: Aangezien er meerdere campagnes tegelijkertijd kunnen zijn, is het belangrijk aandacht te besteden aan de campagneID en 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. 

Dit zijn de geformatteerde en niet geformatteerde telefoonnummers:

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 )

De SIP-signalering wordt gestart:

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

Controleer de verwerking van deze berichten op de gateway met het bericht dat eerder werd uitgelegd.

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

De poort verstuurt een SIP UPDATE-bericht samen met het CPA bericht. De CPA-software loopt op de gateway en analyseert het Real-Time Transport Protocol (RTP) van de opgeroepen partij. Dit helpt onderscheid te maken tussen spraak en antwoordapparaat aan het genoemde partijeind. U kunt een CPA SIP UPDATE-bericht identificeren door het content-type van 'application/x-cisco-cpa' te gebruiken.

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

Vaak voorkomende problemen

Er wordt geen CPA verzonden van gateway naar UCCX

Nadat de oproep is verbonden met de PSTN-beller, worden er geen berichten teruggestuurd naar UCCX door de gateway om aan te geven dat de CPA is voltooid en dat een gesprek heeft geresulteerd (actieve stem, drukke, antwoordapparaat, enz.). Zorg ervoor dat de IOS versie op de gateway CPA ondersteunt. Onderzoek de toegangspoort om te controleren of de CPA goed werkt.

Bel niet opnieuw naar UCCX wordt gericht nadat live spraak is herkend

Controleer of de gateway een dial-peer heeft die het UCCX gedraaide nummer (DN) aanpast dat aan de campagne is toegewezen. Controleer dat een verbinding van de poort naar dat CTI routepunt/trigger in CUCM kan leiden.

Regels zijn niet gesloten

Gelijkaardig aan callbacks in de Uitstaande Kiezer van de Voorbeeld, als de vraag die RNA ontvangt of bezig is niet wordt opnieuw beproefd, controleer of deze records correct zijn gemarkeerd als Terugzetten in de tabel DialingList. Controleer aan de MIVR-logboeken dat de callpoging wordt gedaan bij de opgegeven callback of probeer de tijd opnieuw.

DTMF werkt niet wanneer verbinding wordt gemaakt met IVR-scripts

Controleer dat DTMF correct tussen CUCM en de gateway wordt onderhandeld en dat de genoemde dial-peers worden aangepast (kies-peer 0 bevat geen DTMF relaisconfiguratie). UCCX ondersteunt alleen out-of-band DTMF via JTAPI, zodat voor sommige gatewaytypen en callstromen een media Termination Point (MTP) moet worden opgeroepen om DTMF-interworking te voltooien. Onderzoek de gateway om de poort te controleren en CUCM verwerkt op de juiste manier DTMF-verzoeken en -onderhandelingen.

Gerelateerde informatie

• Technische ondersteuning en documentatie – Cisco Systems