Keep CallVariables through Transfer/Label to another DN

[FabianSchmidt]

Hello everybody,

I have an issue keeping CallVariables.

Scenario1:

CTIOS Agent gets a Call with CallVariable1 = "test" -> Initiates a SingleStep or Consult Transfer to another Agent (directly to the Extension) -> Agent#2 can see CallVariable1 = "test".

Scenario2:

CTIOS Agent gets a Call with CallVariable1 = "test" -> Initiates a SingleStep or Consult Transfer to another DN which results in an ICM Script. Now the Variables are empty, even if i see them in the new initiated call in CTIOS Desktop.

I fear that there is no possibility to keep these variables through simple transfers without AgentToAgent Nodes or something? Is ScriptEditor deleting these vars when a new call hits, and if yes, why?

Background is, that a customer would like to keep the information if someone heard a welcome announcement before he got transferedfrom an agent to another DN. They do not want to transfer to a seperate DN or smth like that.

Thanks for your ideas and help!

Fabian

[geoff]

Does the call originally arrive at Call Manager and you do a translation route to the IVR?

If you come in on the IVR initially, running another ICM script from the CUCM routing client DN will not preserve call context without a trans route - its on another peripheral.

Regards,

Geoff

[FabianSchmidt]

Hi Geoff,

The Callflow is CVP Comprehensive, so:

Gateway -> CUPS -> CVP -> ICM-> Agent

This Agent then Transfers to another DN which the CUCM routes to the CUPS-Trunk via Route-Pattern.

The DN's are all on the same peripheral. Should i send the call to the Gateway instead of CUPS on transfer?

EDIT: At the moment im looking at previous threads via the search word "call context".. you have answered this already for CVP Warm Transfer i guess. Looking at those Threads:

https://supportforums.cisco.com/message/3181653

https://supportforums.cisco.com/message/3137294

Thanks for your help!

Fabian

[FabianSchmidt]

So...

Keeping the Variables when the Agent makes the transfer is very simple. I just have to create a Dialed Number on the CUCM Routing Client instead of a Route Pattern on CUCM... Then it works fine for single-step transfer.

Now i have two problems left... warm-transfer did not work, because the new call gets a busy and fails after about 2-3 seconds. Then i configured your list of things from the other threads and now variable-passing and warm-transfer both work fine. But the 2x S2VRU Nodes both fail and i cannot play announcements. So i must have forgotten something here?

Thanks,

Fabian

[geoff]

The first Send To VRU node will return to the CUCM routing client the transfer label configured in the Network VRU on that PIM. Call Manager will do something with it. This is a route pattern in CUCM to find a CVP Call Server.

The second Send To VRU node will return to the CVP routing client the transfer label configured in the Network VRU on that PIM. This is your pattern to get to the Gateway. CVP needs a route to the Gateway.

If you were using Send to Originator exclusively (branch office deployment), you may not have a route on the IVR transfer label to find a gateway - you did not need it. So you need to add a static route on that pattern (make sure you use a wild card to allow for the correlation ID) to your Proxy (or to the Calll Server, if not using a Proxy). Be aware you should also add the ring back and error routes.

Regards,

Geoff

[FabianSchmidt]

Im using an UCCE/CVP 8 enviroment if that matters?

The first Send To VRU node will return to the CUCM routing client the  transfer label configured in the Network VRU on that PIM. Call Manager  will do something with it. This is a route pattern in CUCM to find a CVP  Call Server.

According to your steps i did the following:

3. PG Explorer - CUCM PIM Advanced - Network VRU - NONE

So how does the SendToVRU Node know where to send the 8222222222* label? Is it because the labels on the CVP-VRU are configured for the same customer as the DN?

When i do warm or single step transfer, both SendToVRU Nodes still fail. In CTIOS-Desktop i see that the DialedNumber is set to 8222222222+CID so it gets send by the 1st SendToVRU Node but never returns to ICM Script? The RoutePattern (not SIP Route Pattern) is configured to send it to the CUPS Trunk, where a static route to CallServer1 is configured. So it should return properly, but doesnt

Thanks for your help,

Fabian

[geoff]

So how does the SendToVRU Node know where to send the 8222222222* label? Is it because the labels on the CVP-VRU are configured for the same customer as the DN?

Exactly. Send To VRU returns a label to the Routing Client that matches the customer on the Dialed Number that launched the script (DN-> Call Type -> Scheduled Script) and pauses the script.

So 8222222222+corr id is returned to Call Manager through the CUCM PG, and Call Manager uses that to find a Call Server through a route pattern to CUPS and then to a Call Server. It comes in on the Call Server, and instead of acting like a NEW CALL it uses the Correlation ID to find the script that was paused.

Then it moves to the next node in your script. If the first Send To VRU is failing, you must find the problem in your setup.

Regards,

Geoff

[Kris Lambrechts]

Hey guys,

Fabian, as to how does it know which Network VRU to use : this is derived from your ICM Instance. (if this is a single customer system you can define it in the System Settings too). But since you already see 822222* on your phone display that part should be fine. Next you'll want to check your call routing for that label, it seems that's the failing part.

Your call seems to get lost somewhere between CUCM trying to call 82222* and the Router getting notified of that call leg arriving at the CVP Call Server. The easiest places to troubleshoot this :

• Using 'utils network capture' on the CUPS so you can nicely see the SIP traffic going in and out, here it's vital to make sure that the call is sent to Call Server first and your CUPS doesn't try to route it straight to a VXML gateway, picking different Network VRU Labels for the CUCM and CVP Routing Client makes this job easier / more logical;
• VRU PIM logs : do you see a NEW_CALL notification for 8222222 with the correct Correlation ID ?

[FabianSchmidt]

Hey,

what i see is attached, im a bit confused by the 8888888888 which is my VRU CVP Label which comes back. The Call arrives with 82222222 and the right Correlation ID at CVP -> PIM so there must be something wrong with finding the paused script?

I have only one SendToVRU Node in the Script (tested also with 2) followed by an IF Node to test if the Var2 is still the same and two exits 91919191 or 92929292... So Why does it send the 8888888888 if there is only one SendToVRU Node which already sent 82222222, there is only one call counted in monitor mode in the script.

The Call Transfer itself works fine for getting an Agent, but palying Announcements  to the caller (not agent) and this SendToVRU is the issue here.

Thanks,

Fabian

[geoff · Accepted solution]

The script will execute an implicit Send To VRU on the first Run External Script or Queue to Skill Group it encounters.

Even if you don't specifically have one, it will execute one and fail in your Run External Script.

A Run External Script could fail for other reasons (like the WAV file being incorrectly named), and that's why I prefer to insert the explicit Send To VRU. If you put the second Send To VRU in place, and you see it fail in that node, you know where the problem lies.

Since 8888888888+cor id is being returned to CVP, you must have a static route in CUPS to push this call to the gateway to start the bootstrap. Do you have that?

REgards,

Geoff

[FabianSchmidt]

Hey,

The Problem was solved with Kris Lambrechts via TAC Case.

SIP Header-Passing was not configured on the gateway, so the 8888888888* Label which arrives on the Gateway from the static CUPS Route was not returned to the CallServer because the gateway didn't know the IP.

For normal Calsl we did not notice this, because there the 8888888888* comes via SendToOriginator directly from the CallServer!

Thanks for all your Help Geoff and Kris, i hope someone with simmilar Problems can find also use of this.

Fabian

[geoff · Accepted solution]

That's correct.

In the "voice service sip" section of the ingress gateway, you should have something like this:

!

voice service voip

signaling forward unconditional

fax protocol t38 ls-redundancy 0 hs-redundancy 0 fallback none

modem passthrough none codec g729r8 pre-ietf

sip

  min-se  360

  header-passing

!

and in the "voice service sip" section of the VXML gateway you should have something like this:

!

voice service voip

allow-connections h323 to h323

signaling forward unconditional

h323

modem passthrough none codec g729r8 pre-ietf

sip

  min-se  360

  header-passing

!

If you have a combined gateway (as you have) then essentially you have a combination.

This is shown in a document Cisco published - attached.

Regards,

Geoff