Troubleshooting Erroneous Call Flows and Toll Fraud in Cisco Unity and UCCX
Your company is a Cisco Unified Communications environment and you are trying to identify an inbound call flow in order to diagnose an issue with hard facts. You ask yourself: “How can I find the call flow that is being accessed at the time of my issue?” This guide will help you diagnose two use cases:
- Erroneous call flows in Cisco Unity
- Toll Fraud.
Although we are focusing on these two particular cases these solutions can be used to diagnose a variety of issues .
PROBLEM
You are unable to figure out what the inbound caller is dialing before and after they access your system (Unity, UCCX).
SOLUTION 1
Identifying the Unity call flow which was sending a customer to the incorrect destination.
Simply download the traces from call manager and search for the “KeyPadButton=”. This trace is advantageous for identifying a single call with a good idea of the time frame in which it occurred.
45883909.001 |10:26:12.047 |AppInfo |StationD: (0000053) KeypadButton KeyPadButton=4(Four).
45883939.001 |10:26:13.798 |AppInfo |StationD: (0000053) KeypadButton KeyPadButton=0(Zero).
In this case, we know that the user dialed 4 before accessing the receptionist, we can now go into the Cisco Unity call flow to check what object the caller input of 4 represents.
SOLUTION 2
Identify the call flow that was used for Toll Fraud.
Collect the output of the “debug voip ccapi inout” command on the gateway. Search for the desired keyword “Relaying Digit”.
This particular debug is not too intensive, so you can leave it running to collect the data at a later time from the logs, however, this trace is advantageous for an issue that can be viewed in real time and which is constantly occurring.
2103134: May 2 23:16:57.196: //3500648/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_begin:
Consume mask is not set. Relaying Digit * to dstCallId 0x356A69
2103135: May 2 23:16:57.196: //3500648/xxxxxxxxxxxx/CCAPI/cc_relay_digit_begin_for_3way_conference:
Check DTMF relay digit begin for 3way conf
2103136: May 2 23:16:57.288: //3500648/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_end:
Consume mask is not set. Relaying Digit * to dstCallId 0x356A69
2103138: May 2 23:17:00.396: //3500648/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_begin:
Consume mask is not set. Relaying Digit 1 to dstCallId 0x356A69
2103139: May 2 23:17:00.396: //3500648/xxxxxxxxxxxx/CCAPI/cc_relay_digit_begin_for_3way_conference:
Check DTMF relay digit begin for 3way conf
2103140: May 2 23:17:00.488: //3500648/xxxxxxxxxxxx/CCAPI/cc_api_call_digit_end:
Consume mask is not set. Relaying Digit 1 to dstCallId 0x356A69
2103141: May 2 23:17:00.488: //3500648/xxxxxxxxxxxx/CCAPI/cc_relay_digit_end_for_3way_conference:
Check DTMF relay digit end for 3way conf
In this case, we were able to identify that the attacker was dialing *1 as the first digit of the extension , which was enabling them to sign into the voicemail box of a user and allowing them to modify the transfer rules.
USEFUL TIPS:
- When reviewing these traces be sure to note the time when the first entry was keyed in with regards to the time at which the transfer to Cisco Unity or UCCX occurred. If the caller waited too long, they could have ended up in another prompt.
- Once you have identified your call, you can quickly find the remainder of the caller input in the trace file by identifying the call ID or device ID. It is very useful to highlight this information as seen above using a program like notepad++.
Want to learn more about how we can help you with your Cisco Unified Communications needs, reach out and we will give you a call.
Ready to take your unified communications from headache to hassle-free?
No throwing darts at proposals or contracts. No battling through the back-end. No nonsense, no run-around.