Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 

Dropped Call Troubleshooting in CUCM

 

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:

  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

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

 
Version history
Revision #:
2 of 2
Last update:
‎08-28-2017 02:44 AM
Updated by:
 
Labels (1)
Contributors
Comments
New Member

What???

New Member

Excellent doc, thanks for your contribution!

Maybe worth mentioning:

1. the syntax is slightly different in 8.6: "run sql car select count(*) as count,origdevicename from tbl_billing_data etcetc."

2. Don't forget the table "tbl_billing_error" - some connection problems might also hide in there

New Member

Thanks for this great document. I am using cucm 8.0 in my lab to verify this procedure so I can use to troublehoot an issue I'm working on, but I realised that my tbl_billing_data is empty, no rows, and tbl_billing_error surprisingly has similar information to accomplish this task. Is there a particular reason why my tbl_billing_data is not being populated? Will appreciate your response on this.  Thanks.

Cisco Employee

tbl_billing_data can be empty for several reasons: * cdrs are not enabled via ccm service paramenter * car is disabled and not attempting to import CDRs * car import of CDRs is failing * all records are importing into tbl_billing_error  For more information on CAR see: http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/service/8_0_1/car/carcdru.html