Assumptions
Examples provided here are taken from CUCM 6.1(3) but the concepts are applicable to all versions 5.x-7.x. Same concept may be used in 4.x but must use the cdr database rather than car database.
Prerequisites
- CCM Service parameter "CDR Enabled" or "Call Detail Records Enabled" must be set to "Enabled" on all nodes running the ccm process.
- CCM Service parameter "CDR Log Calls with Zero Duration" may affect output as well. Calls that are disconnected for abnormal reasons should be logged regardless of this configuration but some interaction may still apply.
- CDR Analysis and Reporting, or CAR, services must be enabled under service activation
- CAR must have continuous loading enabled to view records from the current day. Otherwise CAR defaults to loading once per day so only calls from the previous day will be available for reporting.
Concept
When a call is disconnected the disconnecting party may provide a reason code. Most telephony components do provide valid relatively accurate disconnect cause codes. Analyzing those cause codes is an effective way of aggregating call failures.
For more information on cause codes see: CDR Cause Codes
Limitations
There are really 2 limitations to this approach:
- There are some abnormal conditions that cause a call to disconnect with a cause of Normal Call Clearing (16) or No Error (0). Troubleshooting these conditions requires ample and accurate information from users. The CUCM QRT feature may help to collect information from users and identify those calls.
- Calls may be disconnected by Normal Call Clearing or No Error due to user or application error. Examples include the handset bouncing in the handset cradle and disconnecting the call. This is also frequently observed where CTI applications such as IPCC are used to remotely control phones. The CTI application can send a CTIDisconnectRequest that causes the call to clear. This is either an application or user error but unfortunately the caused code recorded in CDR is Normal Call Clearing
Execution
1. ssh to the publisher in the CUCM cluster
2. identify the most common cause codes. The cause may be from the originating or destination side so 2 queries must be used:
admin:run sql select count(*) as count,origcause_value from car:tbl_billing_data where origcause_value not in (0,16,126,128,393216,458752) group by origcause_value order by count asc
count origcause_value
===== ===============
3 47
admin:run sql select count(*) as count,destcause_value from car:tbl_billing_data where destcause_value not in (0,16,126,128,393216,458752) group by destcause_value order by count asc
count destcause_value
===== ===============
admin:
See CDR Cause Codes for further information on cause code values.
3. Next identify the endpoints involved. For origcause_value entries focus on origdevicename. For destcause_value entries focus on destdevicename or finalcalledpartynumber.
admin:run sql select count(*) as count,origdevicename from car:tbl_billing_data where origcause_value = 47 group by origdevicename order by count asc
count origdevicename
===== ===============
1 10.10.20.1
2 10.10.30.1
In this case cause code 47 is usually a media failure. This is commonly caused by codec mismatch on the VOIP leg.
4. To get additional details about specific dropped calls:
admin:run sql select datetimeorigination,callingpartynumber,origdevicename,destdevicename,finalcalledpartynumber,orignodeid,origlegcallidentifier,destnodeid,destlegidentifier from car:tbl_billing_data where origcause_value=47 and origdevicename='10.10.30.1'
datetimeorigination callingpartynumber origdevicename destdevicename finalcalledpartynumber orignodeid origlegcallidentifier destnodeid destlegidentifier
=================== ================== =============== =============== ====================== ========== ===================== ========== =================
1235491890 5551017 10.10.30.1 SEP005060015B6A 5551012 2 41095249 2 41095250
1235492075 5551017 10.10.30.1 VCB0003D6006DFC b00205901001 2 41095249 2 41095255
This provides all information necessary to review configuration. If the problem cannot be identified from configuration this also provides information to locate calls in debugs or traces:
- datetimeorigination identifies the time the call started based on the GMT time zone in epoch format. For easy conversion see Online Conversion
- nodeid identifies which CUCM node processed the call
- legidentifier can be used to find calls in SDI or SDL traces
Informix can convert epoch to human readable dates. Change the *(5+0) to adjust for local time zone and cst/cdt etc.
-- Time Zone: 4=Eastern 5=Central 6=Mountain 7=Pacific
-- Season: 0=Summer 1=Winter
run sql select first 1 callingpartynumber calling, originalcalledpartynumber origcalled, finalcalledpartynumber finalcalled, origcause_value orig, destcause_value dest,DBINFO('utc_to_datetime',datetimeorigination-(3600*(5+0))) origination, datetimeorigination from car:tbl_billing_data order by datetimeorigination desc
calling origcalled finalcalled orig dest origination
========== ========== =========== ==== ==== =====================
5551212 5551300 5551300 16 0 2009-04-06 08:00:44.0
Further Information
IBM Informix SQL Syntax
Contributors
Wes Sisk
