AT&T Transfer Connect Customer Voice Portal (CVP) en Intelligent Contact Management (ICM)

Inleiding

Dit document beschrijft een probleem dat is ondervonden bij het gebruik van CVP uitgebreide gespreksstroom met overdrachtsfunctie van AT&T (DTMF *8).

Voorwaarden

Vereisten

Cisco raadt kennis van de volgende onderwerpen aan:

• CVP versie 8.5
• Intelligent Contact Manager (ICM)
• AT&T-verbindingsservices overdragen

Gebruikte componenten

De informatie in dit document is gebaseerd op de volgende software- en hardware-versies:

• ICM 8.5
• CVP 8.5
• CUBE versie 15.1-3.T4
• AT&T-overdrachtaansluiting

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.

Symptomen

U stelt een oproep in en de oproep wordt via CVP naar Cisco Unified Contact Center Enterprise (UCCE) verzonden. De oproep wordt teruggestuurd naar een extern nummer op AT&T-netwerk (Transfer Connect Service). Wanneer het probleem zich voordoet, hoort u deze aanwijzingen bij AT&T:

Een ogenblik geduld

Het spijt ons dat uw telefoontje niet kan worden voltooid. Probeer uw oproep opnieuw

Oorzaak / Beschrijving van probleem

In een volledige CVP-gespreksstroom wordt een oproep ontvangen voor CVP, CVP ontvangt het label DTM *8, gevolgd door 500 milliseconde (MS) gepauzeerd en 1800 nummers. CVP stuurt DTMF naar het Cisco Unified Border Element (CUBE) en de gateway uit puls de cijfers naar het AT&T-netwerk. De oproep wordt echter niet overgebracht en de klant hoort berichten. Sorry dat uw oproep niet kan worden voltooid. Probeer het nog eens.

Stap 1. De beller plaatst een oproep van het openbare telefoonnetwerk (PSTN).

Stap 2. De Ingress Gateway (IGW) ontvangt de oproep van het PSTN, in dit geval is CUBE de Ingress-gateway.

Stap 3. De IGW stuurt een SIP INVITE-bericht naar CVP via een SIP-proxyserver.

Stap 4. CVP stuurt een nieuw gespreksverzoek naar de ICM.

Stap 5. De ICM voert het routingscript uit en stuurt een etiket van Voice Response Unit (VRU) naar CVP.

Stap 6. CVP stuurt een SIP INVITE-bericht via SIP-proxyserver naar de Voice XML Gateway (VXML GW).

Stap 7. De VXML GW voert het bootstrap-script uit en stuurt een HTTP-aanvraag naar CVP.

Stap 8. CVP stuurt de ICM een verzoek-instructies.

Stap 9. De ICM annuleert het VRU-been en stuurt het DTMF-label naar CVP. CVP beëindigt het VRU-been met de VXML GW.

Stap 10. CVP stuurt DTMF naar IGW (CUBE).

Stap 1. IGW (CUBE) breekt DTMF uit naar het AT&T-netwerk.

Stap 12. AT&T-netwerk verstuurt DTMF **7-netwerk niet ontvangen of kan het gedialogeerde nummer niet herkennen. Voor goede case scenario's stuurt CVP DTMF **6 en de klant hoort graag na Een ogenblik geduld.

Verifiëren

Stap 1. CVP-configuratie.

In het bestand sip.Properties onder de configuratiemap moet de functie SIP.ExterneTransferWachten worden toegevoegd en op 1000 (1 seconde) worden ingesteld. Na deze herstart de CVP-callserver.

Stap 2. CVP Call server logs.

Verzamel CVP-sporen met Select com.dynamicsoft.dsLibs.DSUALibs ingesteld op Debug-niveau.

Uit de CVP-documenten blijkt dat CVP-berichten versturen naar Ingress Gateway (CUBE) voor elke DTMF:

Bijvoorbeeld de "*" tint die van CVP naar IGW (CUBE) wordt gestuurd.

264788: 10.1.1.1: Nov 25 2013 12:28:25.362 -0800: %CVP_8_5_SIP-7-CALL:  {Thrd=pool-1-thread-197-SIP-61173} 409D1D04-4D6B11E3-8E94E199-7280FCFD: Starting an external transfer with label: DTMF*8,,,,,18YYNXXXXXX
2059160: 10.1.1.1: Nov 25 2013 12:28:25.362 -0800: %_Connection-7-com.dynamicsoft.DsLibs.DsUALibs.DsSipLlApi.Connection:  Sending Message (NB): INFO sip:5123809981@10.1.2.2:5060 SIP/2.0
Via: SIP/2.0/TCP 10.1.1.1:5060;branch=z9hG4bKa74MS0n9A4oRWinVIAjXSA~~47394
Max-Forwards: 70
To: <sip:5123809981@10.1.2.2>;tag=658DC428-11DA
From: <sip:5008007435000@10.1.1.11>;tag=dsefb53fdb
Call-ID: 409D1D04-4D6B11E3-8E94E199-7280FCFD@10.1.2.2
CSeq: 1 INFO
Content-Length: 26
Contact: <sip:10.1.1.1:5060;transport=udp>
Content-Type: application/dtmf-relay
Signal=*    
Duration=100

Stap 3. Verzamel Ingress gateway-loggen (CUBE).

csip-bericht debug

debug van voip-sessienaam

De DTMF-relais waarover op het PSTN-gedeelte (AT&T) is onderhandeld, is RTP-NTE met een payload-type 100.
De DTMF-relais waarover op het CVP-been is onderhandeld, is sip-info en rtp-nte met een payload-type 101.

Op basis van de blogs wordt gezien dat Ingress Gateway (CUBE) alle cijfers van de CVP ontvangt met behulp van het SIP-info-bericht en het naar het PSTN stuurt (AT&T)

Bijvoorbeeld CUBE verzenden van cijfer 7 naar het PSTN / AT&T-netwerk

289591: Nov 15 22:20:52.244:          s=DSP d=VoIP payload 0x64 ssrc 0x149A460E sequence 0xBD4 timestamp 0x2B700
289592: Nov 15 22:20:52.244:          Pt:100    Evt:7       Pkt:0A 00 00  <Snd>>>
289593: Nov 15 22:20:52.244:          s=DSP d=VoIP payload 0x64 ssrc 0x149A460E sequence 0xBD5 timestamp 0x2B700
289594: Nov 15 22:20:52.244:          Pt:100    Evt:7       Pkt:0A 00 00  <Snd>>>
289595: Nov 15 22:20:52.244:          s=DSP d=VoIP payload 0x64 ssrc 0x149A460E sequence 0xBD6 timestamp 0x2B700

Stap 4. Verzamel de pakketvastlegging op de poort en bevestig de AT&T-vereisten.

Vereisten:

Inter-cijfer tijd uit = 3 seconden

Voor DTMF-signalering naar het netwerk moet de VRU van de omleidingspartij (in dit geval CVP en CUBE) DTMF-tonen met ten minste 80 ms van cijfermatige duur en 80 ms van dubbelcijferige stilte verzenden.

Tussen de *T en het omleidingsnummer of de SD-code moet een pauze van ten minste 350 ms worden aangebracht. (De onderste en bovenste rand zijn 300 ms - 11 seconden.)

Packet Capture Analysis

In de goede oproepen, nadat CUBE het laatste cijfer naar AT&T stuurt, stuurt AT&T de DTMF "* 6" rond 500 MS

Tijd tussen cijfers verzonden naar AT&T = 200 MS

Tijd vanaf DTMF *8 wordt verzonden en het eerste cijfer = 400 MS

Bewijsduur - lengte = 100 MS

Slecht geluid:

AT&T stuurt DTMF **7, 6 seconden later na ontvangst van het laatste cijfer

Tijd tussen cijfers verzonden naar AT&T = 200 MS

Tijd vanaf DTMF *8 wordt verzonden en het eerste cijfer = 400 MS

Bewijsduur - lengte = 100 MS

Er is geen verschil tussen de goede en slechte gesprekken in de pakketvastlegging.

Resolutie

Aangezien de DTMF's die naar AT&T worden gestuurd voor goede en slechte gesprekken, dezelfde eigenschappen en timers hebben, maar in sommige scenario's wordt de DTMF niet erkend, worden tests uitgevoerd met pauzes vóór specifieke groep van cijfers en de combinatie die het probleem oplost is: DTMF*8,,,,,1,,8YY,, NXX, XXXX,,,". Dit wordt gewijzigd in het ICM script.