Sometimes it's nice to see which steps, a call executed, very quickly, without needing to recreate the call flow and performing a risky Reactive Debug session. Here are the steps to do so:
Step 1: Enable Engine Debugging
In order for this feature to work, you will need to enable ENG debugging under trace configuration within CCX Serviceability.
Step 2: SSH in to Master Node
You are free to use any SSH client you like. Keep in mind that this is the platform administrator account, and not the same one you use for RTMT or CCX Administration. Although, in many environments the username and password pair are the same for all of these accounts. It's common for this username to be one of: Administrator, administrator, osadministrator, or osadmin. Note the case on the first two.
Step 3: Find the implId
Start by running the following command to get the Implementation ID for the call, which we will use in the next step to find the Task ID. Replace the example phone number with your calling party number.
Find when the implId gets associated to the Task ID. Use the implId from the previous step, within this command, to find your Task ID. We'll then use the Task ID from this step, in the next step, to find all of the executed steps for this call.
trunc...MediaId:4654465/3 Task:42000000286 associated with Task ID: 42000000286...
Step 5: Find All Script Steps
Find all of the script steps your call executed by supplying your Task ID, from the previous step, in this command.
Note that Call Subflow borrows the same implId and Task ID, so you'll see Sub Flow step executing, an advantage over Reactive Debugging. (Hence the max executed step counter does not reset upon call subflow)
Also note that, a call which transfers from script to script will begin a new call, keep the same implId, but get a new Task ID, and therefore its own set of executed script steps. (Hence the max executed step counter resets upon transfer)
Say the script was holding a transfer extension in a variable. While you'll see the variable name in the above steps, you will not see the String value. So, to get the extension you actually transferred the caller to, use this step in addition to the above.
This is how you get the Agent User ID, name and extension who answered the call. So, tieing back into the above bonus step, there is a value in there that you'll need, which is the "session=" number. Let's pretend the number was 53000095261.
Hello all, So we have a specific use case at the moment which is fairly unique and am probably out of my depth. Our employees are contacting there clients using there personal devices (covid) and masking the number to get some anonymity. However mana...
I want to change my CUCM 12.5 cluster to mixed mode. Cisco Doc says we need to have " Export-controlled Functionalityallowed" in the token when we generate from smart account. I can see no such option in my smart account. How can I get it?
Hi All, We are getting outbound international calls failed with dest cause code 127, when made via Jabber (12.7) while deskphone (majorly 7965) and CIPC calls are getting matured properly. Call Flow: Jabber > CUCM > SIP Trunk > ISP (SBC...
On our one of the client-side, all the users faced a call transfer issue over a weekend.Now this reflects in the call reporting as well.The reports below details given that, calls to operator queues on 5/30/2020 from 12:00A Saturday to 12:00A Sunday....
Hi there, sorry if this has been answered I was not able to find exactly what I was looking for. We have a single CUCM cluster on version 12.5 with the servers defined by FQDN in system > server.7800 and 8800 phones. I was curious if we have ...