UCCX Contact Dispostion 1?

[Falco_Lombardi]

Been working with TAC and investigating an issue where we run the Detailed Call by CSQ Agent Report and we see the Contact Disposition is 1.

I cannot replicate this issue myself it seems almost random. I know Contact Disposition 1 means Abandoned. I've tried hanging up the call every step of the way but cannot replicate this issue myself. If you run the report for the month you'll see a couple of 1's. Not certain what is causing this. Had TAC look through our UCCX Script to verify it was correct.

What specifically can cause a Contact Disposition of 1?

Cisco Unified CCX Administration System version: 11.6.2.10000-38

Cisco Unified CM Administration System version: 11.5.1.12900-21

Attached the report showing this issue.

[Anthony Holloway]

It looks like the number one offending application in that report as far as abandons go is BHRS_MAT. Would it be possible for your to post the full script here, or could you at least do a Ctrl+F to find the step called Set Contact Info?

Also, for your benefit and others, all calls start off as a disposition of 1, essentially. Then it is changed to another value, depending on what the outcome of the call was. E.g., Agent answers = 2 for Handled.

Therefore, if you're getting 1's in your report, it simply means, nothing happened to mark the call as handled, before the call ended. There's only two ways that can happen:

1) Select Resource step successfully connects the caller to an Agent
2) Set Contact Info step marks the call as Handled

Also, you're getting quite a few ~15 mark abandons in your CSA_CFRE_Callback app. This is likely due to a max steps being executed error event. You can see if that's the case by running the following command on the CLI of your UCCX master node:

file search activelog uccx/log/MIVR "maxexecutedstepsexceeded" ignorecase

[Falco_Lombardi]

I've attached the two scripts, the one labeled CSA_CFRE is the one site complaining.

[Anthony Holloway]

At first look, it looks like you are marking every call as handled. Then that begs the question: If you don't care to know the difference between the different dispositions, why even look at the metric at all? Just remove it from the report.

[Falco_Lombardi]

The issue started when the customer ran the report themselves and from the definition thought a 1 meant the call is failing somewhere. If a 1 doesn't imply that calls are failing we can report that back to the customer which would be great. From my testing, being unable to replicate this issue myself was the reason I asked about this originally.

[Anthony Holloway]

Correct, a disposition of a 1 does not mean a failure occurred. It's simply a classification of what happened to the call. Dispositions 4 - 98 are bad and need to be investigated as soon as possible. You have 23 of those in your report. You will need to run a different report, the Aborted Rejected report to get the reason and a few other details. Though, this report on its own wont be enough, and you'll likely need to pull logs to fix the issues.

[Falco_Lombardi]

I had increased the max steps from 1000 to 1500 because that was the issue sometime ago. I ran the command in the CLI and nothing returned so it looks like that isn't the issue this time which is great.

I have the calls marked as handled in the CSA_CFRE Script I attached earlier. Perhaps it needs to be located to another place in the script?

[Anthony Holloway]

Oh I see, ok, well, I suppose it could be failing for other reasons then.

I would need to see the steps executed for one of the calls marked as a 1.

Could you following the process outlined here for one of the calls marked as a 1, and then paste the output? It will likely have to be a recent call, else the logs might have already rotated.

https://community.cisco.com/t5/collaboration-voice-and-video/uccx-viewing-executed-script-steps-via-cli/ta-p/3162231

[Falco_Lombardi]

Thank you for this. Going to look at it now and let you know the findings.

[Falco_Lombardi]

Attached are the steps generated by the CLI.

[Anthony Holloway]

The sample data set you provided is for one call to the Application BHRS_MAT_Test, which runs the script CSA_CFRE_10-25-19_TEST.aef.

Since the report you listed earlier had this app in it, but with only 1 instance of the disposition 1, I'm not sure how valuable this will be.  Also, I see that this app is using a different script than the two you submitted, and so I have no idea what differences may exist.

Also, I can see that this log is not 100% conclusive of the call, as the log output stops after 787 steps (750 of them was just the looping waiting for a callback agent to pick up).

Your callback waiting loop is 3 steps and 7 seconds long.  If it takes you 30 steps to get to it, and you set your max executed steps to 1500, then 1500 max steps / 3 looped steps = 500 loops * 7 second = 58 minutes of hold time before the script aborts.

The logs only show 22 minutes of this particular call.  I'm not sure why that is, since you clearly captured the start of the call, and I don't think you did anything to not capture the end of it.

Not much else to say about this one.

[Falco_Lombardi]

I take that back. Attached is the output from the max steps. The odd thing is I increased it to 1500 but it still shows 1000 in the logs.

[Falco_Lombardi]

From the logs now, taking a second look at it, these generated before I made the 1000 to 1500 change.

[Anthony Holloway]

You have to restart the CCX Engine service (or the whole server) in order for that value to take affect.