Unique Call ID fro CTI purposes

[o.jamil]

In the Desktop Control Server document it is mentioned the the combination of the ConnectionCallID, ConnectionDeviceID, ConnectionDeviceType " ... uniquely identify a call."

However, I have a situation that this fields (actually the ConnectionDeviceID ) is changing within the life time of the call.

Example:

*************

18:11:45 Trace: BEGIN_CALL_EVENT: CallID=965.1101.2(s) CallType=CALLTYPE_AGENT_OUT

18:11:52 Trace: CALL_DATA_UPDATE_EVENT: CallID=965.1101.2(s) CallType=CALLTYPE_AGENT_OUT

18:11:52 Trace: CALL_DATA_UPDATE_EVENT: CallID=965.1101.2(s) NewCallID=965.1002.1(s) CallType=CALLTYPE_AGENT_OUT

18:11:52 Trace: CALL_ESTABLISHED_EVENT: CallID=965.1002.1(s) AnsweringDevice=(DEVICE)1002

18:11:52 Trace: AGENT EVENT: ID:1002 TALKING Group:1000 Priority:0 Reason:0

*************

The above is a printout from a CTITest session for one agent that got a call and has answered it.

As can be seen the BEGIN & UPDATE events have the same callID (965.1101.2), but once the agent has answered the call the callID for the ESTABLISHED event is changing ( 965.1002.1).

Any Advise.

[ciscomoderator]

Since there has been no response to your post, it appears to be either too complex or too rare an issue for other forum members to assist you. If you don't get a suitable response to your post, you may wish to review our resources at the online Technical Assistance Center (www.cisco.com/tac) or speak with a TAC engineer. You can open a TAC case online at www.cisco.com/tac/caseopen

If anyone else in the forum has some advice, please reply to this thread.

Thank you for posting.

[tofisher]

o.jamil,

Can you elaborate on what you are trying to accomplish by tracking the call? If you are trying to provide "cradle to grave" tracking of one call you actually need to be looking at the Day and Router Call Key in the termination call detail table. This table is in the ICM Logger or HDS. The Day + Router Call Key combination allows you to tie all the events for a particular call together and to create a custom report to track each call. Just as an FYI, if the call passes through multiple peripherals, you MUST translation route or use MIS for this tracking to function properly. Let me know if this is not your intention.

Good Luck,

Tom Fisher

Applications Consultant

Cisco Systems, Inc.

[o.jamil]

tofisher,

Yes, I do want to provide "cradle to grave" tracking, although not of one call but of all the calls an agent might have. But this doesn't make any difference (I think).

I'm aware of the call key fields only they are populated only when there a Translation / Post routing is performed and this is not the case for me.

These fields are not populated in our case.

Can I be sure that for any customer post routing will be performed?

What is a post routing any how?

Is it that when a routing script is being activated?

[tofisher]

o.jamil,

As far as the DeviceID changing on your CTI Trace this is to be expected as the call moves within the ACD. If you read a bit further from the documenation you quoted in your original post you will find the following paragraph...

"A ConnectionDeviceID uniquely identifies a call connection. However, it cannot directly identify the connected device; use other event message fields for that purpose. In some cases, the ConnectionDeviceID may simply be the ID of the connected device, the connected deviceID with additional identifying data included, or a string that does not contain the

deviceID at all. A valid CTI Server application can make no assumption about the content or format of a ConnectionDeviceID."

In other words, the ConnectionDeviceID can not be assumed to be unique and constant for any given call. If you read beyond the secion I just pasted, you will learn what a valid CTI Client must do to recognize the call and handle the changing ConnectionDeviceID's properly.

As far as the Day and Router Call Key values. These values are created for EVERY call that is routed through the ICM. This is true for Pre-Routed calls (calls that are routed by the ICM straight from the cloud) and Post-Routed calls (calls that are routed from one client peripheral to another). The Day and Router call key can then be leveraged to provide tracking for individual calls. If necessary these values can even be populated into call variables by the ICM for delivery to the CTI desktop client.

If you want to report on agent activity throughout the day, this is a standard reporting feature from within Monitor ICM. If your requirements extend beyond the standard reports, you can engage Cisco PSO to create a custom report to fit your needs.

Also, for a good overview of the ICM as well as the definitions for pre and post routing please see http://www.cisco.com/warp/public/cc/pd/cucxsw/prodlit/icmsw_ov.htm

Good Luck,

Tom Fisher

Applications Consultant

Cisco Systems, Inc.

[o.jamil]

Thanks.

I can not find these quotes that you have mentioned in the document I have (DesktopControlServer.pdf), and anyhow it seems to me that these two quotes are actually contradict, but whatever...

My goal is to find a way to track the call, and you are suggesting the call key values, which are perfectly fit, as long as they are populated even in the case ofpre-routing. I was told by one of Cisco's experts that these are populated only in the cases of post-routing & translation-routing!

Can you please verify what you're saying about the pre-routing?

[tofisher]

I just sent you the CTI Message Reference Guide I was referring to in my previous post (to the email associated with your ID). As far as the Day and Router call key, these values are created for EVERY request that comes into the ICM Router. This includes pre-route requests from the carrier. As long as you Translation Route from the carrier to the destination ACD you can populate this information into a variable and send it to the destination.

Now, having said that, if you are post-routing the call you must use translation routes to be able to keep the SAME Day/Router Call Key for the call across multiple peripherals. When the ICM gets a Translation Route Request the router will recognize that the call already has a Day/Router Call Key and will arrange the values so that you can do a search on that call key for the call. I believe it actually creates a parent/child relationship but I would have to do some testing to see how to best refence them in a report.

If you just do a post-route request without Translation Routing, the ICM will consider it a new call and issue a new Day/Router call key. Therefore, you lose your ability to track the call across peripherals. In addition, without Translation Routes there is no way to send the CTI desktop data to the remote destination.

-Tom