ICM Scripting. value on variable Call.RoutingClient

[sidney.orret]

Scenario:

- UCCE 8.5 with CVP 8.5 - Type 10 NVRU

-  Call initiated from a IP Phone dialing a CTI RP.

-  CUCM is the routing client of the original call.

-  UCCE script launch.

-  Eventually the call hits a SendToVRU node.

- At this time the NVRU label is sent back to CUCM. CUCM then sends the call to the CVP Call Server, and the routing client changes to be the CVP Call Server.

- Afterward the call re-enters the UCCE script and I would expect variable Call.RoutingClient to contain the name of the CVP Call Server but still holds the name of the CUCM routing client.

- Curiously the value of Call.RoutingClientId changes to the dbid (RCID) of the corresponding CVP Call Server routing client, which is normal because the RCID is used by the router to send the labels to the right routing client.

Thus, I am curious why the disconnect between Call.RoutingClient and Call.RoutingClientID on CUCM originated calls after the routing client changes from CUCM to CVP Call Server.

Which value should I expect on variable Call.RoutingClient? The original routing client, or the current routing client?

[Kris Lambrechts]

Interesting observation, and not exactly something that I see clearly defined in the documentation. I would assume the 'current routing client ID' to be the most logical value. Or at the very least you'd expect the content of

Call.RoutingClient and Call.RoutingClientId to be consistent, i.e. either both from the CUCM RC or both from the CVP RC.

I think this can be considered a defect or at the very least worth a review of a developer to verify what the functional specifications say and how the Router is currently working. You may want to open a TAC Service Request to have this investigated further.

Regards,

Kris

[Chad Stachowicz]

I am just thinking as a logical person and a programmer, but it would seem to me it would makes sense to have the Original Routing Client and the Current Routing Client both stored, let say for example you havea  very large environment and you want to know which of 6 CUCM clusters it originated from in order to provide the best media server treatment.

I imagine this is working as expected, original in one, and current in the other.

Chad

[Kris Lambrechts]

Hey Chad,

In such enviorments you'd indeed want to know where the caller is physically located to provide on-site VXML treatment. However, the bigger issue there is the RTP streams between the caller's phone and the VXML gateway he's on. This is not determined by your script at all but requires the implementation of signaling digits. The choice of a mediaserver could indeed matter somewhat, but I'd think that by pointing to a DNS name and resolving it to the most appropriate mediaserver relative to each  VXML gateway is more consistent.

Anyway, it all depends a bit on what your network architecture looks like and in some designs you'd possibly want to use these scripting fields as you said. I just wanted to point out that there are more scalabable ways of providing VRU teatment at the edge.

Cheers,

Kris

[sidney.orret]

The way I see it, the originating CUCM is a factor to determine which CVP Call Server will handle the call. After that, which VXML GW, VXML Server or media server decisions are made based on the location of the CVP Call Server and no so much the CUCM. To ensure that the closest VXML GW is use you need to use either different Network VRU labels for the CVP Call Server routing clients, or other mechanisms. CUCM will decide only which CVP Call Server the call connects in first place, and after that all decisions are off CUCM realm.

Below is a more detailed description of what I am trying to accomplish.

When the originating party dials the CUCM Route Point that triggers and associated ICM script. Eventually the script reaches the SendToVRU node and sends the label defined for the CUCM peripheral on the Network VRU. That  is a first transfer to a CVP Call Server and CUCM will handle it because at this time CUCM is still the routing client.

When CUCM receives the label a decision is made either by CUCM route patterns with static routes (this is my case), SIP Proxy or H.323 GK, to which CVP Call Server to send the call.  If you have different CUCM clusters you can have different labels and make different decision (the Bangalore cluster send calls to CVP Call Servers in Bangalore, the London cluster uses CVP Call Server in London, and so on). If you have only one cluster serving agents all over the planet I don't think there is much room to fine control the CVP Call Server decision based on the actual location of the agent's phone that is what really matters.

Anyway. when the call is connected to the CVP Call Server the routing client functions are passed to the CVP Call Server and CUCM is at that time totally out of the picture as far as routing decisions go.  

The call re-enters the ICM Script now with a CVP Call Server being the routing client, and the CVP Call Server Routing Client Network VRU label is sent this time to the CVP Call Server looking for a VXML GW. That is a second transfers that is performed behind the scenes and is not expliticly seen on the ICM script.

All the above works just fine.

The challenge I am having is that I am using CVP Combos (VXML and CVP Call Server together) and I want to use the VXML Server that is co-resident with the CVP Call Server handling the call.  Obviously I don't have a SIP proxy or a CSS on the solution.

To achieve that I have created ip host entries on the VXML GW to match the CVP Call Server routing client. For example if my CVP Call Server routing client name is CVP01 I have the following entries on the VXML GW

ip host CPV01 10.0.0.1

ip host CVP01-backup 10.0.0.2

and on my ICM script I  want to use variable {Call.RoutingClient} to create the VXML Server url that goes in the microapp.media_server variable.

That achieves two purposes,  first that I always use the co-resident VXML server to service the call, and second provides a basic redundancy through the CVP IVR -backup mechanism.

It works just fine on the inbound calls because the value on Call.RoutingClient is correct, referring to the name of the routing client for the CVP Call Server handling the call.

The problem is that for the CUCM originated calls, even if the routing client changed to be one of the CVP Call Servers, the value on the variable Call.RoutingClient still refers to the CUCM routing client name.

Again, variable Call.RoutingClientID value is always correct. The issue is with the value on the Call.RoutingClient.

I would assume that both should be consistent, and they are not at this time. There are workarounds but there are not as clean as I would like.

The cleanest workaround I have come up with is to define ip host entries on the VXML GW to  match the CUCM routing client name, but I think that is confussing for  anyone reading the GW configuration that will wonder why the reference  to CUCM.

So far at this time on the ICM script I have a bunch of IF Nodes to check the Call.RoutingClientID and then create the right VXML Server URI based on the the related name, but all is just to account for the fact that calls originated by CUCM have the wrong value on the Call.RoutingClient variable. All this I believe can be avoided if the values on the variables were consistent.

I would like to hear some opinions from Cisco developers on this matter.

[Chuck Smith]

Just so I am understanding correctly. You are saying that call.RoutingClient will always show the UCM RC when the call originates on a CTI Route Point but call.RoutingClientID will reflect the CVP server that the call was sent to in the send to VRU step? In my case it appears that call.RoutingClient and call.RoutingClientID are both sticking to the UCM RC even after the Send to VRU. I am on UCCE 8.5.3. What version of UCCE are you running Sidney?

[dalebeachwood]

I see the same results on UCCE 8.5.3 as dzam above. When the call is originated from a CTI Route Point, Call.RoutingClient and Call.RoutingClientID remian the CUCM RC even after a Send toVRU node or after returning from a VXML server Call Studio application.

Call.user,cvp_server_info contains the IP address of the CVP server can be used to send calls to the VXML server on the same CVP call server (concatenate("http://",call.user.cvp_server_info,":7000/CVP") but only for new calls that come to ICM directly trhrough CVP. It is never populated for calls that originate from a CTI-RP, even after a Send to VRU node.

We send all calls to ICM via CTI-RPs for scripts that will queue and where there may be agent transfers. For standard microapps scripts we use a hostname in the user.microapp_media_server variable and have "hostname" and "hostname-backup" hostname entries on the VXML gateways. This works fine and provides redundancy to two of four CVP/VXML/Media servers.

However, since we do not have ACE or CSS, and call.user.cvp_server_info is not populated for CTI-RP calls and Call.RoutingClient and CallRoutingClientID are only populated with the original CUCM RC I do not see a way to provide redundancy for microapp_media_server for CTI-RP originated calls and would welcome any input.

[Riasat Ali]

Thanks for everyone. Can anyone help to step down configurations for call back to IVR in presence of UCCE 8.5.2, ACE, CUSP and CVP (Call+VXML server) co-located on single server. Thanks