Updating call variables failing for the call type AGENT_INSIDE

[azizshaik]

Hi,

we ran in to a scenario where in we couldn't update the call variables for a call that the agent dialed out using our custom app.

below is the scenario where the update is failing

Agent places a call to a customer by calling the make_call api.

Customer gets the call and accepts the call and Agent and the customer are talking

Agent now wants to conference another agent to talk with the customer, when the agent initiates a conference, we send a call data update request first and once the call data update event succeeds, we then initiate the conference. in this case we get an error mentioned below

    <apiErrors>

      <apiError>

        <errorData>14</errorData>

        <errorMessage>E_CTI_PROTECTED_VARIABLE</errorMessage>

        <errorType>Call Variable is protected</errorType>

      </apiError>

    </apiErrors>

  </data>

  <event>put</event>

  <requestId>60af45ba-3041-47e6-8720-977bd214fa98</requestId>

  <source>/finesse/api/Dialog/2130872371</source>

</Update>

attached is the log of our app..

it works perfectly fine with a regular inbound call.

Can any one please help us out.

[dekwan · Accepted solution]

Hi Aziz,

From the Dialog - Update Call Variable Data documentation, an error of "Call Variable is protected" means that you are attempting to set call variables on a non-routed (direct) call. Setting call variables on a direct call is not allowed by CCE/CCX and hence the error.

Thanx,

Denise

[azizshaik]

Does that mean we cant update any call variables for a call that is initiated by the agent, we do see the update_data operation available to in the call actions.

[dekwan]

If an agent is making a routed call, then it works. If it is a direct call, then it won't.

There is no way for Finesse to differentiate between a routed and non-routed call when it is populating the allowable actions.

[azizshaik]

is there a way i can set call variables while trying to make a consult call, provided the original call is ICM routed.

that way i dont have to wait on getting the call data update event and i can just set the variable just while making the consult call..

[dekwan]

Hi Aziz,

According to documentation and my testing, it doesn't appear that you can set the call variables while making the consult call. That is an option for MAKE_CALL only.

Thanx,

Denise

[ryan.edwards]

Hi Denise,

We are running into this issue and I know this is an old thread, but this appears to still be the case and it's causing some internal problems. In CTIOS we do this today - set pv10 in the call variables before sending the consult call to a transfer VDN. We were expecting it to work the same way in Finesse, but it doesn't seem we can overwrite any of the call variables if they were set on MAKE_CALL.

Is there a reason this functionality exists in CTIOS but not Finesse?

[dekwan]

Hi Ryan,

Per documentation and my knowledge on the new features added/changed since my last reply, I believe that Finesse still doesn't allow setting the call variables during a consult call. I don't recall the reason behind it, but it is typically due to a limitation to the protocol/backend.

Thanx,

Denise

[ryan.edwards]

So is there no intention to modify this then on the books? It is existing functionality in CTIOS.

[dekwan]

Hi Ryan,

As of now, this isn't in the backlog, but I have sent this thread to the Finesse team to show the interest for this feature.

Thanx,

Denise

[David Pendleton]

Hi Denise,

I believe what I'm trying to do is similar to this thread.  I need to pass variable data with a call transferred via Consult.

The scenario is:

Callers go through and identification process in an ICM script, then after queuing, are delivered to Agent1.

Agent1 then uses Consult to transfer the caller to another queue which eventually delivers the caller to Agent2.

Within Consult, Agent1 has two ways to transfer the caller:

1. "warm transfer" - If Agent1 waits in the queue until Agent2 answers to click "Transfer", the call variables containing the caller identity are delivered to Finesse for Agent2

2. "cold? transfer" - If Agent1 doesn't wait for Agent2 to answer, but clicks "Transfer" while queued, leaving the caller to listen to the hold music, when Agent2 receives the call, the call variables delivered to Finesse for Agent2 are null.

The "cold transfer" is the approach most likely used since Agent1 likely won't wait on hold for Agent2 to answer.

Issue: How can the caller's identify information already in the dialogue's call variables be delivered to Agent2?

This issue was discussed in 2013 here: Pass variables between skillgroups on CTIOS Agent Desktop Solved: Pass variables between skillgroups on C... - Cisco Support Community where the solution is to always use a "warm transfer".

In my testing, warm transfer works, cold transfer doesn't.  The difference seems to be that the call variables are reset if Agent1 transfers while in queue vs transferring after leaving the queue when Agent2 answers.

We know the call variable data survives queuing to Agent2, since it is intact when delivered via warm transfer.

I am interested in why the call variable data it isn't delivered if Agent1 clicks transfer during queuing - and how we can get "cold transfers" to deliver the previously loaded call variables.

[dekwan]

Hi David,

Which version of Finesse are you using and is it a CCE deployment? I wasn't able to reproduce this issue using Finesse 11.0 with CCE, but maybe I am not performing the scenario correctly.

Can you provide the logs for the two scenarios along with the user information and timestamp?

Thanx,

Denise

[David Pendleton]

Hi Denise,

We're using UCCE 11.5.1 and Finesse 11.5.1.

I'm not sure which logs would help.  I see the call variables in the browser debugger with break points on the JavaScript.  Let me know what logs you'd like to see and I'll get them for you.

Test setup:

1. 2 agent phones, 1 caller phone

2. Two agents skilled to the queue in the test script.

3. Two phone numbers for calling the ICM test script.

4. ICM test script: create a ICM script that branches on DN. 

The 1st phone number ("outside" number), routes to nodes that set values in PVs (I call CVP application here to identify caller based on ANI) - but static values in PVs should recreate the issue.

Then check for LAA agent and then queue the call.

The 2nd phone number ("internal" number) routing should bypass the PV assignments and insert the call at the check for LAA agent.

5. Open two browsers: IE and Firefox and login as Agent1 and Agent2 in each respectively.

Test 1 - call vars flow through using warm transfer

6. Make Agent2 Not Ready

7. Make Agent1 Ready and from "caller" phone dial the 1st phone number.  When the call is delivered to Agent1, the call variables are available - use debugger and break points to see the call variables (var callVars = dialog.getMediaProperties()) or setup the layout to show the variables in Finesse desktop.

8. While on the call, make Agent1 pending Not Ready (so the call won't come right back to this agent)

9. Make Agent 2 Ready now

10. Click "Consult" and dial the 2nd "internal" phone number.

11 Wait for Agent2 to answer, then click Transfer, the PV vars will be delivered to Agent2

Test 2 - call vars are lost using queuing

12. Make Agent2 Not Ready now

13. Make Agent1 Ready and from the "caller" phone dial the 1st phone number.  Agent1 has call vars

14. Click "Consult" and dial the 2nd "internal" phone number.

15. While the call is in queue, click "Transfer".  The caller will be in queue until Agent2 goes Ready

16. Make Agent2 Ready, call is delivered, the call variables will be null.

If you're having different results, then I'll have some hope.

Thanks for looking at this.

[dekwan]

Hi,

I would need the Finesse webservices logs for the scenario. Please provide the user information and timestamp.

Thanx,

Denise

[David Pendleton]

Hi Denise,

I have two webservice logs for you.  The "Cold Transfer" log captures the sceanrio in which callvariables are not delivered to the second agent.  The "Warm Transfer" log captures the sceanrio where callvariables are delivered to the second agent.

In both sceanrios, the first agent to receive a call is 3141001, the second agent is 3141002 (both are named Jim Hammerstein).  Time stamp: WarmTransfer starts at 14:11, ColdTransfer starts at  13:55

Sceanrio recaps

Cold Transfer: Inbound caller is identified and their identify info is stored in call variables.  After queuing or directly, the caller is delivered to Agent1.  Agent1 can see the caller's identity information in Finesse gadget.  Agent1 uses Consult to dial an inbound queue script.  When Agent1 hears the "hold" music, he clicks Transfer.  Caller hears hold music until Agent2 goes ready.  When the caller is delivered to Agent2 caller's identity information in call variables is missing.

Warm Transfer: Same as Cold Transfer, but Agent1 waits until Agent2 answers.  Then Agent1 clicks Transfer.  Agent2 get's caller's identity information in call variables shown in gadget.

David