Posted by: Mudassir Ali | June 11, 2010

Dropped Call Troubleshooting in CUCM

Dropped Call Troubleshooting in CUCM


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.

For more information on cause codes see: CDR Cause Codes


There are really 2 limitations to this approach:

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

2. 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
===== ===============

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
===== ===============

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=''
datetimeorigination callingpartynumber origdevicename destdevicename finalcalledpartynumber orignodeid origlegcallidentifier destnodeid destlegidentifier
=================== ================== =============== =============== ====================== ========== ===================== ========== =================
1235491890 5551017 SEP005060015B6A 5551012 2 41095249 2 41095250
1235492075 5551017 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.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: