JTAPI Exception: Terminal Connection does not belong to the CCNVector

[RyanHarmon56961]

Hi everyone,

I have a JTAPI application in a customer call center that opens monitors on various agent extensions and processes the call events.

Part of the processing involves calling the JTAPI function "getPeerUUID" on certain call connections, as this value maps to metadata we correlate with SIPREC invites.

The "getPeerUUID" call almost always works, except for one agent in particular, where it will sometimes fail with the following exception: "Terminal Connection does not belong to the CCNVector"

I can't find any documentation on this exception online or in the JTAPI developers guide. Does anyone have info on what this means or how to troubleshoot?

We don't see any issue with other agents, so we are trying to figure out if there is a configuration issue particularly with this one. We noticed that when we see this exception, there are multiple "Terminal Connections" with the agents extension on the call, which never happens for anyone else.

For example, if we call the following function on the call object for this agent

getCurrentCallingTerminal().getTerminalConnections()

We get an array with two elements that looks like this (I've replaced actual data with placeholders for privacy)

[[NAME/[1234::1/(P1-cti) GCID=(1,xxxxxxx)->ACTIVE]->ALERTING]->RINGING, [NAME/[1234::1/(P1-cti) GCID=(1,xxxxxxx)->ACTIVE]->ESTABLISHED]->TALKING]

I'm not sure why we see two connections with extension 1234, one in a state of RINGING and another in a state of ESTABLISHED. I'm wondering if this would happen when forwarding calls to a cell phone, but our customer has told us that this agent does not use that feature, so I'm curious if anyone else has an idea of a situation that would cause this.

Thank you in advance, please let me know if I left out any critical pieces of info to help troubleshoot this.

[dstaudt]

Can't find any direct info on "CCNVector", but several defect descriptions mentioning "ICCNDervice interface" seem to involve situations where the device built-in-bridge is disabled/unavailable, attempting operations like adding parties to a conference with invalid terminals/connections, or otherwise unexpected things happening when BiB/recording/monitoring related operations are attempted on incorrect objects or objects in unexpected states.
Your observation on multiple Terminal Connections being present suggests behaviours associated to shared line and/or hunt list quirks of Cisco's JTAPI implementation.  You might see if the agent's DN is shared with another device or a member of a hunt group/pickup group.  If so, and the customer is OK with removing that config, the problem may go away; however it may be better to learn about the changed behaviour in those situations so you can handle them sanely in future.

For example, when a call lands at a Hunt Pilot, the new ringing call will be modeled in JTAPI as a call with three connections - the two normal ones for calling party and called party (hunt member), but also an extra one representing the hunt pilot.  Only one is the "real" device that you will end up using methods like getPeerUUID() with, and you should be able to iterate through the array of multiple terminal connections to find the "real" one, i.e. based on a Cisco extension method for that purpose, e.g. call.getCurrentCalledParty() for a call to a Hunt Pilot returns an address of type CiscoAddress.HUNT_PILOT.

[RyanHarmon56961]

Thank you for the response, this is extremely helpful.

As it happens, the issue we are seeing is being reported specifically for calls coming to a hunt list. However, we have a hunt list setup in our development lab and I do not see the duplicate connections when I am testing there.

I have reached out to our customer to see if the agent in question has a shared line, since we do not have that configured in our lab. Regardless, your explanation makes sense and I think will give us what we need to support this scenario.

Thanks!