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,Several of my customers wants to provide the ability to include PIN in SIP URI to facilitate the connection to meeting from video endpoint. There are various scenarios where this feature will be helpful.The format would be: xxxxx@domain,,PIN# (e.g.:...
All, I have recently upgrade my ccx from 10.6 to 12.5 I am struggling with the licensing portion. We do have a valid SWSS for CCX-U-EHA10-125K9= and generated the license, but albeit the traditional license file, but on CCX side, I have chosen smart licen...
Hello, I have a VCSE cluster running on VMs that is currently on X7.2.3 and needs to be upgraded. The plan is to upgrade to X12 in the least possible stages. According to Cisco clustering docs, it s OK to upgrade from X8.6 or above to X12...
I have just installed a new CIMP server on my existing CUCM. I have not set up any SRV records just yet but am wanting to sign in a couple users first. The CUCM is on a different domain than my CIMP but I have updated the default SIP Proxy ser...
I'm looking at an issue where I have 2 phones that have BLF configured. If Ext 1234 is on the line user 5678 is able to see them on a call. That works as expected. But if user 5678 takes a call and then sends that call to a Hunt Group th...