I seem to be floundering when it comes to finding someone who can answer CVPD questions that come up in class. I know you don't want me to post questions regarding CVPD here, but where else should I go?

PLEASE tell me what the appropriate forum/email to use is. The more I can understand, the better job I can do disseminating the information to my students.

For example,

ReqIcmLabel element - student wants to know whether it's possible to use this element to send data to ICM in a Comprehensive CVP Solution. I know this element is meant for systems where ICM didn't preroute the call to Studio app, but that's not the question. The question is, whether it's POSSIBLE to use this element to communicate with ICM in the middle of a Studio app if ICM DID route the call into Studio app? And if someone could explain in some detail what's going on in ICM when the ReqIcmLabel element is used, that would be GREAT.

I also have a question on this element. Does a specific script need to be configured to run on ICM that the ReqIcmLabel invokes when it runs?

Thanks! Janine

So far, I haven't found anyone who has used or tried this element -- but I'm "sure" someone at Cisco must have tried it out before "releasing" it. So, there must be someone out there with some knowledge...

I actually found some information in the CAG (Config and Admin Guide for CVP).

The ReqIcmLabel element is for use in a CVP Standalone environment but where you want to request a route from ICM.

So it's different than the comprehensive environment. Here, ICM doesn't send the call in to the Studio application and doesn't route the call after the Studio app finishes.

Instead, the call comes into the Voice Gateway and then into the Studio app. If the app needs to transfer, it can use the ReqICMLabel element and pass all kinds of data to an ICM script (call peripheral vars 1-10, fromExtVxml 0-4, and caller_input). This starts an ICM script which will return the route information (a label) into Element Data for the Studio ReqIcmLabel {Data.Element.ReqIcmLabel.result}.

Then it's up to the Studio app to perform the transfer using a Transfer element and the information returned from the ICM script.

The CAG is not incredibly clear when it describes all the data that can be returned from ICM into the Studio element. The 'result' (label) itself is returned into element data {Data.Element.ReqIcmLabel.result}.

ICM can return more data using ToExtVxml [ J ] as "varName=varValue" pairs (the array can be up to size 5, J=0,1,2,3,4), in which case it becomes Session Data named varName with the value varValue.

ICM can also return data using by setting the Call Variables 1-10, then the data comes in as Element Data for the ReqIcmLabel element. The element data is named callVar1 callVarReturn1 (not sure of the exact case, and it IS case sensitive). Here's where the CAG is unclear.

I believe that if ICM returns call variable 1 = "varValue" then you'll end up with element data {Data.Element.ReqIcmLabel.callReturnVar1}=varValue

But that if ICM returns a name/value pair: call variable 1 = "varName = varValue" then you'll end up with element data {Data.Element.ReqIcmLabel.callVar1}=varName
and {Data.Element.ReqIcmLabel.callReturnVar1}=varValue

But, I haven't been able to test the element and the doc'n is a little unclear on the return values.

Anyway, the CAG ref manual tells you about the script to create on ICM to interface with this element, and you need to configure the Call Server also.

Hope this helps!
Janine

Here's an 'educated'(?) guess:

I bet that you can pass it in the FromExtVxml 0 (or1,2,3) setting in
Studio ReqIcmLabel element, and it'll then be available in ICM's
FromExtVxml[0] array element.

Or you could pass it in the caller_input setting in Studio ReqIcmLabel
element and it'll be available in ICM's ECC variable
user.microapp.caller_input.

And the ICM script writer just needs to know which of these variables
will contain the information.

That's how most Studio to ICM interaction works.

Please DO let me know if you find out.

Janine

Hi Janine,

Today the ReqICMLabel functionality is supported in the standaone model only. Based on tests that I have done, it won't work in the comprehensive model today since the call server does not pass the ANI/DNIS up to the VXML Server as part of the VXML generated via the GS VXML template when starting the VXML Server sub-dialog(i.e. send call to VXML Server to run an app)

One could pass the DNIS/ANI today using the ToExtVXML vars array but then would somehow need to override the ANI/DNIS in CallData of the VXML app since that's the one that's used when the ReqICMLabel from VXML Server is sent to CVP Call Server. As far as I know, it's not possible to override the call data with session data.

Even if the change is made where this data is passed up to the VXML Server, the current implementation would not easily fit in the comprehensive call flow for the following reason.

Comprehensive call flow is as follows:

• Call comes into CVP call server (SIP or H.323) with DNIS 1111
• Switch leg dialog is setup with ICM and NEW_CALL request is sent to ICM
• ICM responds with a VRU label on the switch leg
• SIP or H.323 sub-system will send an outbound call to the VXML GW to setup the VRU leg of the call
• VRU leg dialog is setup with ICM and a REQUEST_INSTRUCTIOn is sent to ICM
• ICM sends back a RUN_SCRIPT_REQ on the VRU leg dialog (i.e. GS microapp)
• Call server sends this VXML up to IOS GW which sends the call to VXML Server

At this point, since the VRU leg dialog from CVP Call Server to ICM is already setup and a RUN_SCRIPT_REQ is sent from ICM to CVP Call Server to start the VXML Server sub-dialog(e.g. GS microapp), we can do nothing but send back a RUN_SCRIPT_RESULT on this dialog.

Hence, the call from VXML Server has to be a new dialog with ICM(e.g. another NEW_CALL). But what DNIS should this request use? If the same DNIS(1111) is used, the same script that started with the call from Call Server will execute again.

So again, there are multiple solutions here:

• If the original DNIS is used to send the ReqICMLabel NEW_CALL, the ICM script could be written with an IF block differentiating the NEW_CALL request from the call server vs. the request from VXML Server with some flag in the call/ECC vars.

• Instead of passing up the original DNIS, we allow the script writer to configure a dnis on the request ICM label node which may be different from the original dnis in which case there's no need to pass up the original DNIS.

• Now the user could run the same script with an IF node or another script in ICM based on this DNIS

Again, all of the above proposed solution is speculative as none of this is implemented today.

In terms of what's going on with the ReqICMLabel today in the standalone model, basically when a stand alone call in VXML Server today hits the ReqICMLabel node, a NEW_CALL request is sent to ICM via the CVP Call server with the DNIS/ANI of the standalone call. The script that's scheduled in ICM based on this DNIS will be executed. The RUN_SCRIPT_REQ nodes are not supported with the ReqICMLabel functionality. One can do other operations in the script such as DB lookup etc.. but in the end, only a CONNECT message from ICM is what's supported which includes the call context (call vars/ecc vars).

One of the key reasons behind the development of this element was so that a Self Service application can transfer its call to a separate full-blown Unified CVP system for agent selection and queuing. Full call context is preserved throughout.

For example, think of the CVP Standalone VoiceXML Server as just another routing client in ICM.  ICM can send any label to it including, for example, a translation route to VRU label.  Unfortunately you can't use Type 10 and SendToVRU here, because the correlationId won't be handled correctly inside the VXML Subsystem.

So the ICM routing script would do a TranslationRouteToVRU to the full CVP (which is Type 10), and because it is Type 10 it would do its automatic second transfer to the VRU leg.

The configuration from ICM's perspective is identical to doing a transfer into CVP from a 3rd party TDM VRU or ACD.

Hope this clarifies some of the questions!

-Harun

Harun,
Thank you for that very nice explanation of using the ReqICMLabel
element in Studio. I'll pass it along to my students.
Janine

Hi Harun -
 
You are correct in that with the ReqICMLabel creating a new call object, there is not much call-specific information that could be gathered, so its use would be limited.
 
It could, however, still be used to check environmental conditions in real-time, for example:
 
1. Are there Agents still logged into the Skill Group that this call is queued to?
2. Is there an emergency flag set (Global Variables, etc.)?
3. Are there any Agents available in an overflow group?  Maybe we only want to queue to that group if there are Agents showing available, etc.
 
It would be ideal if we could simply have access to the same real-time data from ICM in a Studio app as we do from an ICM Routing Script, but I think even in the absence of this, if the ReqICMLabel could be made to work for some basic data capture and exchange to/from a *running* Call Services app, it could open up some nice application possibilities that wouldn't require a separate "real-time" DB connection or other API into ICM.
 
Thanks again for the great follow-up on this!!
 
 - Bill

Great post Brian!
 
It's almost frustrating that it was that easy!  I almost hate to admit that I probably spent 2 hours or more at a customer site trying to get this to work a couple months back!!
 
Anyway - thank you for this information!!  And you hit it right on - it would seem like this is sort of a "so what?" feature, but there's a lot that can be done with it.  It is actually, in some ways, more powerful than the standard interface of ICM/CVP with Call Services, since that is limited to ONLY the ToExtVXML ECC array with 5 elements.  With the ReqICMLabel, you can send all of that AND 10 Call Variables AND the "caller_input" ECC.
 
Cisco needs to figure out an interface more like this for the ICM-to-Call Services direction...!
 
 - Bill

Unfortunately, this is not possible - it is the limitation with the ReqICMLabel step.  It is not necessarily intended to be used with UCCE/ICM and CVP in Comprehensive mode.  When you execute this step, it creates a new "call object" and record in the ICM system, so there will be no correlation between the RCK of the ReqICMLabel call and the original call that invoked the Studio application that contains it.  (Hope that makes sense).
 
Basically, the ReqICMLabel call has no relation to any other call.  It's usefulness, in my humble opinion, is largely in the ability to gather real-time and environmental information from the ICM without having to do the standard back-and-forth between ICM and CVP/Call Services.
 
 - Bill

Brian,
 
I am working on a similar situation where I need to get data passed to ICM in a Comprehensive deployment. I've got everything set up as describe in your post. But unfortunately I continue to get an error on the ReqICMLabel piece. 
 
I get:
ReqICMLabel_01,custom,doDecision,- The callGuid or DNIS is null.
 
From what I've read in these post and others it sounds like it should be taking the DNIS of the CallData shown in the start of the activity logs. As in your case I am getting "NA" as the DNIS, the log shows "start,dnis,NA".
 

start,newcall,
start,ani,NA
start,areacode,NA
start,exchange,NA
start,dnis,NA
start,uui,NA
start,iidigits,NA

 
Was there another step that need to be done to assign the DNIS to "NA" for the ReqICMLabel? Or is the dnis used for the ReqICMLabel automatically populated with the start dnis?
 
Thanks,
Nick