IPCC w/redundant IPIVRs--how are CTI ports selected?

[platkeet]

I am having difficulty figuring out how CTI ports are selected in the following scenario:

* Two IPIVRs (CRA 2.2.2c)

* Two CallManagers in one cluster (CM 3.1.4)

* Each IPIVR is using the same JTAPI user (IVRUser, very original) to connect to BOTH the Publisher and Subscriber CM boxes

* 48 CTI Ports configured for each of the two IPIVR boxes

* One post-route port group on each IPIVR box, corresponding to the 48 CTI ports programmed on the IPIVRs and the CallManagers.

The CTIRP in the cluster is controlled by the IVRUser JTAPI user.

When a call arrives from the PSTN or internally, what mechanism is utilized to determine which IPIVR gets the call?

The distribution appears to be random sometimes, and sequential sometimes...so no help there.

Thoughts?

[platkeet]

As a follow-on to this message, I've included an excerpt from a Cisco white paper on IPCC redundancy...it's a draft document called "IPCC Failover Redundancy Design Considerations," authored by Richard Wu and J.Duke Bond.

from the IPIVR section:

"The IP-IVR application is the one responsible to assign its available CTI ports to the Call Manager. Although the CTI ports, or IP-IVR trunks—are devices registered and controlled by the Call Manager service, it is the IP-IVR which decides which port to take the calls."

Still, I don't have a clear understanding of how a port is selected if more than one IPIVR is using the same JTAPI user, and each IPIVR is connecting to either the Publisher or Subscriber CM in a cluster.

Perhaps Richard or Duke could shed some light on this?

[sandgupta]

Hi,

So you have 2 IP IVRs and CTI Route Points associated to respective IP IVR JTAPI User. Your problem is call distribution is random on IP IVRs. Right? IP IVR gets call based on what route point it is associated with.

You might want to set up a pilot number, hunt group, add all the route points. Then configure the hunt group for 1st available hunt group member by or longest idle hunt group member by using the drop down selection under pilot point configuration.

This way, you can get call distribution as required.

Thanks,

[platkeet]

I'm following your suggestion, but I am concerned that this would create a reporting issue in ICM, in that two CTIRPs (which correspond to dialed numbers in ICM) would be involved for one "type" of call.

By following the redundancy guide, a single CTIRP is used, with two groups of CTI ports. The single CTIRP and all of the CTI ports are registered with the single JTAPI user for BOTH IPIVRs. Each IPIVR only has "some" of the CTI ports programmed on the CCM cluster.

In that scenario, is the selection of a CTI port random?

We can always load balance between the IPIVRs by putting the CTIRP under the ICM JTAPI user, and doing a translation route. With some judicious programming, we could create three translation routes: one with half of the CTI ports assigned to one IPIVR, and half from the other, and the other two translation routes would contain all of the ports assigned to one individual IPIVR. ICM scripting could check IPIVR peripheral status, and if both are online, use the "half and half" translation route, and if one is offline, use the peer IPIVR's translation route.

Ultimately, I just want to know how the CTI port choice is made, given the configuration above. It didn't appear to be random when we tested it.

[wiwebb]

The configuration you have described was not designed to work. Multiple IVRs can share a single JTAPI User, but they cannot each have a JTAPI Trigger (Application, like ICM Translation Routing) off the same CTI Route Point. I would be interested in the behavior you have actually experienced, because with this configuration there is no mechanism for the IVRs to determine who should accept the call. It is likely that one IVR is taking all calls until it can no longer accept them (?) Are both IVR's Engines showing "IN_SERVICE"?

The correct way to do this is as Sandeep described - a different CTI Route Point for each IVR. Reporting is not really an issue, depending on how you configure the ICM. It would be recommended to use a CTI Route Point that would be owned by the PG User - basically creating a CallManager Post-Route. This way, your ICM script can perform whatever duties you need it to and return any Label you wish, either directly or through a Translation Route, etc. Now you have 1 Dialed Number that corresponds to a Call Type but is not directly tied to a particular IVR.

- Bill