IPIVR in the UCCE environment is used for IVR treatment and also in modifying enterprise variables. In the UCCE environment, the ICM router controls the call flow and the call logic. If there is a need for the call to be queued, or if there is any IVR treatment that needs to be given, the two major options are:
- IPIVR (UCCX with an IPIVR license)
- CVP
In this article, let’s talk only about the IPIVR solution and how we can understand its role in the call flow.
Let us consider the following environment:
- Simplex UCCE Environment
- Single IPIVR box
- Single CUCM
IPIVR is a peripheral to the ICM. Just as any other peripheral, the communication between the router and the peripheral is through the peripheral gateway (PG). Therefore, we have one PG for the IPIVR and one PG for the CUCM. For simplicity, the peripheral gateway is the interface through which the router communicates with its peripherals.
The different types of connections in this environment are:
- The IPIVR has a JTAPI connection with the CUCM. This is same as the connection in UCCX.
- The IPIVR talks to the PG using the serial control interface (SCI) and this communication is over the GED-125 protocol.
Note: although IPIVR is very similar to UCCX in terms of installation and structure, one very important difference is that it HAS NO CONTROL over agents, unlike the UCCX.
In this article, let's talk about the basic concept of IPIVR and also a few common areas of troubleshooting in these call flows.
It is important to note that most IPIVR deployments use a concept called “Translation Routing.” It is an extremely important concept that was developed to ensure that the enterprise data of a particular data is tied to the call through its entire journey. We won’t be dealing much on translation routing in this article, but this white paper explains the concept in detail:
http://developer.cisco.com/documents/18005/0837357b-73a4-4f6d-a74f-ee8990d5c6b5
Common Troubleshooting Scenarios
In an UCCE environment, the call flow gets tricky as the size of the environment grows. It is extremely important that we isolate whether the issue is with the IPIVR or if it is outside the IPIVR. This will significantly help in reducing the time for resolution. This is absolutely critical in money-churning deployments such as the contact centers.
A few of the common areas of troubleshooting are discussed below:
Wrong Label Returned
Although, technically this is more of a UCCE issue; knowing this is good from a troubleshooting perspective.
When the route request is sent to the router, it replies with the label. As explained before, this label is the number of the CTI-RP (trigger) for the IPIVR. There might be scenarios where you believe that the call is leaving the UCCE but failing when being sent to the IPIVR. At that point in time, ask the question “What is the label returned to the CUCM?” Make sure that the label points to the CTI-RP (or a translation pattern to the RP). As always, the CTI-RP and the ports need to be registered.
From the Router logs, you can see the label being returned:
02:43:35:182 ra-rtr Trace: (65543 x 0 : 0 0) TranRouteToVRU: Label=4111, CorID=9, VRUID=5000
02:43:35:182 ra-rtr Trace: (65543 x 0 : 0 0) Connect: CID=(150429,102), EventSelect=64, ServiceType=1, RCID=5000, Label(s)=4111
Script Being Invoked Does Not Exist/Script Name Mismatch
This is a common issue where the call lands on the IPIVR. Then IPIVR asks the PG “What should I do with this call?” The PG then asks the Router the same question. Based on the script, the Router will ask the IPIVR to invoke a VRU script. The call fails at this step and you think that the call is failing on the IPIVR. Why?
This is because the script label received by the PG and the IPIVR does not match the script name on the IPIVR. Therefore, the IPIVR does not know what to play and the call fails.
From the router logs:
22:35:21:895 ra-rtr Trace: (15 15 12 : 0 0)
Runscript sent. Dialog pending. //Run script is
sent. This is because the agent is not-ready
From the PG logs, we see the script name:
22:35:20:751 PG1A-opc Trace: ProcessINRCMsgs - BEGIN Msg=15 src=48 dest=1
flag=2 size=136 22:35:20:751 PG1A-opc Trace: SendPIMINRCMessage:
RUN_SCRIPT RCID=5001 PID=5000 DID=15 DIDRelSeq#=0 InvokeID=3
CRS(RtrDate=150429,RtrCID=105) RCKSeq#=2 CallTypeID=5000
NICCalledParty#=3101 ScriptID=BasicQ ScriptConfig= CallingParty#=1009 CED=
UUI(Type=1)=1415/1 22:35:20:751 PG1A-opc Trace: ProcessINRCMsgs - END
Msg=15 src=48 dest=1 flag=2
//The Router asks the IPIVR to run the script: BasicQ
We need to make sure that the ScriptID has the same name as the script in the IPIVR. It is case sensitive. The script needs to be named as BasicQ only on the IPIVR.
Translation Route to IPIVR Fails Due to Trunk Number Mismatch
The call will fail in the translation route to VRU node to IPIVR. You will hear a prompt “I am sorry, we are currently experiencing system problems.” Therefore, it is very easy to assume that the issue is on the IPIVR side. Looking at the MIVR logs, the exception is:
45844: Jan 19 20:37:44.457 PST %MIVR-LIB_ICM-6-ABORTING_CALL:Aborting
ICM Call: Call id=1,Media id=4008/1,Trunk number=1,Trunk Group id=2
Exception=com.cisco.wf.subsystems.ged125.GED125RuntimeException
45846: Jan 19 20:37:44.457 PST %MIVR-APP_MGR-3-EXCEPTION:com.cisco.wf.subsystems.ged125.GED125RuntimeException
As you know, GED is the protocol used between the IPIVR and the PG. The error in the router logs is:
4:11:04:722 ra-rtr Trace: (65538 x 0 : 0 0) NewCall:
CID=(150499,104), DN=3121, ANI=1009, CED=, RCID=5000, MRDID=1,
CallAtVRU=0, OpCode=0
04:11:04:731 ra-rtr Trace: (65538 x 0 : 0 0) TranRouteToVRU:
Label=4111, CorID=1, VRUID=5001
04:11:04:739 ra-rtr Trace: (65538 x 0 : 0 0) Connect:
CID=(150499,104), EventSelect=64, ServiceType=1, RCID=5000,
Label(s)=4111
04:11:04:745 ra-rtr Trace: (65538 x 1 : 0 0) CallEventReport: CID=(150499,104),Event=DIVERT_ON_BUSY_NOT_SUPPORTED, DlgEnds=0,
FromVRU=0, CallState=1, Cause=INVALID_CAUSE
This issue is caused by a configuration mismatch on the ICM: the DN is sent to the IPIVR (peripheral) using the Network Trunk Group. There is a very important condition: the trunk group peripheral number on the ICM Network Trunk Group configuration MUST be the same as the Call Control Group ID on the UCCX.
ICM Subsystem remains OUT OF SERVICE on the IPIVR
This is when the IPIVR is unable to reach the VRU PG by hostname. This happens when the ICM/PG sends the protocol version and the IPIVR cannot support it. In this scenario, it is important that the IPIVR tells the PG back again that it does not support it so that a new protocol version can be sent. When reverse DNS is not configured, this fails and therefore the ICM subsystem remains out of service. In the MIVR logs, the following error is seen:
3563: Dec 18 03:48:58.051 CET MIVR-LIB_ICM-6-ACCEPTING_VRU_CONN
Accepting VRU connection: VRU
Connection=Socket[addr=/10.240.145.6,port=59548,localport=5001]
3564: Dec 18 03:48:58.051 CET MIVR-LIB_ICM-6-VRU_CONN_ESTABLISHED
VRU connection established with ICM: ICM Address=/10.240.145.6
3565: Dec 18 03:48:58.051 CET MIVR-LIB_ICM-4-UNSUPPORTED_VERSION
Unsupported VRU protocol version: Version=8
3566: Dec 18 03:48:58.052 CET MIVR-LIB_ICM-5-ENCODING_ERROR ICM
Message encoding error: ICM Message=FAILURE_EVENT,Call
id=null,Media id=null,Exception=java.net.SocketException: Connection reset
3567: Dec 18 03:48:58.052 CET MIVR-LIB_ICM-5-EXCEPTION
java.net.SocketException: Connection reset
Ensure that you have configured both the forward and reverse DNS on the IPIVR so that the IPIVR can reach the PG by the hostname to bring the ICM subsystem to service.
To troubleshoot any issues, you would need logs. For looking at IPIVR/ICM issues, the following logs are required from the IPIVR side:
- MIVR with the following set to XDebug4
- SS_CM
- SS_CMT
- SS_ICM
- JTAPI logs set to Detailed
I would like to stress again the point that the changes made on IPIVR, especially scripts, need not be followed by the ICM. Therefore, before making changes on the IPIVR scripts related to call control, first make a detailed analysis on how this would affect your entire call flow.
| Abhiram Kramadhati is an engineer with the Contact Center Backbone. He has been working with Unified Contact Center Express (UCCX) since he joined Cisco. During two years at Cisco, he has built his expertise around UCCX telephony applications, Java Telephony API (JTAPI) integration, UCCX system behavior, LDAP components and UCCX as IP Interactive Voice Response in Unified Contact Center Enterprise (UCCE) environments. He also works on other technologies including Unified Communications Manager and UCCE. He has been involved in many technical escalations in the Asia Pacific region. |
This article is featured in the May 2013 issue of the Cisco TS Newsletter. Are you subscribed?