06-10-2009 12:59 AM - edited 03-12-2019 08:08 AM
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.
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. 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:
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
What???
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
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.
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: