Seems I've been getting mixed information on deploying a predictive UCCX dialer with CPA enabled on the gateway. I've gone through the CPA pdf guide, found exceptions that can/can't be on the CUBE, but I'm hoping someone can sanity check some of my thoughts, as well as share/confirm knowledge base.
Here's the situation:
Steps for reproducing the problem:
1. Campaign contacts configured and activated
2. Finesse agent can see outbound reserved in state
3. Contacts are dialed to my test cell phones simultaneously (configured that way in campaign).
4. The first phone in the contact list is answered, i talk on the cell phone, receives disconnect.
5. The second phone in the contact list is answered, I talk on the cell phone (second cell phone), transfers to IVR because condition in the campaign if answering machine detected or abandoned call detected.
6. Second call sits in queue. Note: my test jabber phone (internally connected) is in the queue, waiting and not connecting. Also it's stuck in reserved still, even after the call is ended. Only way to reset this is restarting ccx engine.
Notes:
1. It is my understanding that the call path for the campaign, which is pointed directly at a CUBE, uses the CTI outbound port that resides in CUCM where the IP of the port has the active ccx node, then forms a SIP call leg with the CUBE. Is this correct? Shouldn't the refer end up connecting this CTI port?
2. Call progress analysis is configured with the basic configuration referred to in Cisco CPA document.
3. I confirmed that G711 is negotiated in SDP. However I noticed media attribute is showing 101, so from my understanding that means inband RFC 2833. This means it violates the CPA config document: "CPA cannot not be detected if Dialer uses Inband as DTMF relay mechanism, that is, Inband to RTP-NTE DTMF inter-working is not supported with CPA."
4. voice service voip does show dtmf-interworking rtp-nte. Is there something to configure on the CTI ports perhaps?
5. Left wondering if there is a way to override in dial peer, and/or removing that global and make specific in dial peers.
6. Connection is going across a SIP provider. I thought I remember seeing somewhere that SIP provider link wasn't supported, but doc could have been deprecated.
7. Without IVR to trigger in campaign, it will connect, then when caller answers, then disconnect for both test contacts.
8. I've been using term IVR = Script in trigger, but I'm hoping isn't incorrect nomenclature somehow.
EDIT:
Confirmed the following SIP flow:
Invite SDP
Trying
183 SDP
200 ok SDP
ACK
UPDATE
200 OK
UPDATE
200 OK
REFER
202 ACCEPTED
NOTIFY
200 OK
NOTIFY
200 OK
BYE
200 OK
Cross referencing with Cisco material, this is the proper flow.
However, digging at details in the REFER shows an unrecognized SIP header from CTI/UCCX to CUBE. I'm presuming there's missing CPA fields that the CUBE doesn't know what to do with.
My current speculation is that this could be from the TDM requirement missing on the system, because this gateway is all SIP on both sides of the CUBE. Per the guide (i ended up finding) "CPA is supported only on the TDM gateway where one of the call legs is terminated." (guide: https://www.cisco.com/c/en/us/support/docs/voice/session-initiation-protocol-sip/111980-cpa-00.html) I'm now curious what other mechanism might be supported to analyze voice detection. Surely there is something that doesn't rely on TDM that UCCX supports. Or perhaps there is an exception / workaround to this?
