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.
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.
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.
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?
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.
The short answer is that you don't.... That isn't entirely true while at
the same time it kind of is, but for the most part you don't configure
the softkeys. You enable or disable them via TCL. Here is the long
answer. Be sure to read the whole thing or e...
Topology: IP Phone > Switches > Microsoft NPS setup to forward 802.1x
proxy to > ISE 2.1 patch 3 Authentication: EAP-TLS using Cisco MIC SANs
Phone Models 802.1X support? 802.1x flavor Addtl Comment EAP-MD5 EAP-TLS
Cisco 3905 Y Y N Cisco 6911 Y Y N Cisco ...
This document describe how DST changes and how time changes are
implemented in DST. Daylight Saving Time (DST) is the practice of
setting the clocks forward 1 hour from standard time during the summer
months, and back again in the fall, in order to make b...