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.
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.
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.
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
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:
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:
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