Showing results for 
Search instead for 
Did you mean: 

Chalk Talk: Understanding IPIVR in an UCCE Environment


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:

  1. IPIVR (UCCX with an IPIVR license)
  2. 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:

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
45846: Jan 19 20:37:44.457 PST

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,

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

3564: Dec 18 03:48:58.051 CET  MIVR-LIB_ICM-6-VRU_CONN_ESTABLISHED

VRU connection established with ICM: ICM Address=/
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, Connection reset
3567: Dec 18 03:48:58.052 CET  MIVR-LIB_ICM-5-EXCEPTION 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?

Recognize Your Peers
Content for Community-Ad