I'm facing a scripting problem on ICM 7 which someone else might already found a solution before.
I need to create a script that collects various inputs from the caller with microapps, performs a DB lookup, changes the call type based on the previous inputs and sends the call to a queue based on caller input and DB content.
Changing the call type is a management requirement for having granular Webview stats on call handling.
My problem is that I have no idea how to implement this in a nice way.
I'm expecting having hundreds (maybe thousands) of call types, so adding IF+CALLTYPE nodes for each one of them doesn't seem to be an option.
Returning a label dynamically generated by the script and triggering a second queueing scrip by that is problematic as well as I need to preserve information from the caller.
I wish there would be a dynamic call type node.... or a way of accessing call type as a variable with a SET node.
Maybe this should be approached in a completely different way. I don't know.
Any thoughts on this would be greatly appreciated.
I faced a similar situation at a customer site that used custom TDM VRUs and ICM. The customer was looking for extremely detailed reporting information on call disposition, based on callerID and options selected in the VRU application. Additionally, after the VRU performed a mainframe database lookup, the VRU would include the lookup results and other related information to the ICM in the RUN_SCRIPT_RESULT message it sent when the VRU app was complete. (That information was also passed along via CTISVR to a CRM application.)
While designing the solution, I anticipated that these reporting needs would only become more complex as time went on, because the site had very little information of this type available prior to implementing ICM. (Once the information is available to users, experience has shown me that other users and managers succumb to 'report envy.')
After examining the different scripting options, we elected to use a combination of PVs and ECCs, and a custom reporting solution that leveraged the TCD and TCV tables that we would export from the ICM.
There is no way to assign a call type dynamically using the ICM product, nor could we trigger a DB WRITE of some kind to an external table using the ICM or the SCI layer with the TDM VRUs. Additionally, in this customer environment, bouncing the call back and forth between the source ACD and the VRU and back was limited to a total of three 'hops,' so the re-routing scenario you described in your post would not work for this customer either. An Application Gateway-based trigger to write to an external DB seemed like overkill, and would require custom development time.
Since the combination of call disposition and caller behavior in the VRU application resulted in (potentially) hundreds of different call types, and ICM scripting for call types is not dynamic, we concluded that using Call Types to track these items was not going to be practical, and would also present an insurmountable maintenance challenge.
The only other logical location for this information was the TCD or TCV tables, using PVs and ECCs set by ICM and the VRU during the SCI dialogue.
The challenge with the PV/ECC approach was that the standard WebView reports don't expose the PV or ECC variables, so custom reports were required. We first developed some reports using the Sybase InfoMaker product suite and were successful, but the product was difficult to use-and there aren't many folks out there that have worked with it.
We instead went with a Microsoft Reporting Services implementation on a SQL2005 server, and found that the .NET development environment for these reports was much less troublesome. The RS implementation allowed the customer to develop their own custom reports using a familiar tool set, and offered the flexibility that the Sybase tools did not.
We export the ICM's Termination_Call_Detail and Termination_Call_Variable tables nightly (along with most of the half-hour tables) to the RS server. (This is a Cisco best-practices requirement-queries to the TCD and TCV are resource-intensive). It's not an immediate, ad-hoc reporting environment, but so far, it has worked very well with this customer.
Any additional layer of caller classification would simply require an additional PV or ECC variable, and the reports could be altered to accommodate the new classifications. If the additional PV/ECC information does not affect call routing, then the ICM scripts don't have to change, either-the new PV/ECC is just included with the others when the call ends and the call is written to the TCD and TCV tables.
I use hundreds of call types for reporting purposes. I always choose to map PV10 at the same time as I change the call type. This is just done so I can later say "if call type == x". Since you can't branch off the call type, as you know, I check PV10 instead.
I make the call type string and the value of the PV10 exactly the same so it's easy to follow and not confuse myself.
I have some paths that reset the call type 7 times as more information is applied to the call. For example, all calls from customer service, calls from a certain country, calls from a certain region of the country, calls with different DB lookup characteristics, and finally a queuing call type for ASA, abandon rate etc (in IPCC).
These nested call types provide a rich set of peg count statistics. Being able to branch off (effectively) a call type enables you to funnel calls back to a central distribution script (after say DB lookup) which is great for monitoring.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...