Debugging VOIP with Shikha Sharma #CiscoKid

In CDR, it is the most common issue in CDR. We get errors like below- "30023: Data is not available for the date range selected. Data is available only from Dec, 2009 to Jan 2, 2010" "10021 no matching record" Customer panics here and opens TAC case to resolve it. Here I will give you some tips and tricks on how to resolve it quick. First, check if there are any files in the processed folder. Obviously, there won't be any and you would see the following error- "no file was found to show" However, you have checked that files are present in CDR repository, in preserve and car folder. In such a scenario, first get the output of- run sql select * from car:tbl_system_preferences CDR_MAX_DATE              09/16/2010   -> this part is most important as it shows that CAR has data till Sep16                    ...

I hope by the end of this read, it provides you a good knowhow on CDR. What is CDR? CDR is call detail record generated after every call- incoming / outgoing / missed. CDR provides the data about original calling number, original called number, date and time when the call started, time when the call was connected , date and time when the call ended and redirected number. What is CMR? CMR is call management records also generated after every call. CMR provides the information about the jitter, lost packets, the amount of data sent and received during the call, and latency. How to enable CDR and CMR on CUCM server? In order to turn on the CDR, set ' enable CDR flag ' and ' CDR Log Calls with Zero Duration ' to true in the service parameter on the all call processing nodes. In order to turn on the CMR, enable ' call diagnostics ' in the service parameter on the call processing nodes. What are flat files? Flat files are the files which contain call inf...

I have see such kind of error only in one scenario when we need to upload the license for CUPC client on CUCM running on UCS appliance. Why we get this error message :- It's only because Call Manager doesn't understand UPC*.lic file format. For CUCM, CUPC is another endpoint and another phone unit. Hence, it needs the same file format as we use for phone unit DLUs which is CCM*.lic file format. How to resolve it :- Cisco Licensing Team should provide you the license file with CCM*.lic format for UPC client. Snippet of correct license file for UPC - INCREMENT PHONE_UNIT cisco 8.0 permanent uncounted \     VENDOR_STRING=<Count>300</Count><OrigMacId> XXXXXXXXXXXX </OrigMacId><LicMac> XXXXXXXXXXXX </LicMacId><LicFileVersion>2.0</LicFileVersion> \     HOSTID=HOSTNAME= XXXXXXXXXXXX OVERDRAFT=15 \     NOTICE="<LicFileID> licensefilename </LicFileID><LicLineID>1</Li...

Audio issues are nasty, especially when they are sporadic. In such scenarios, it is important to isolate if we are facing issues on inbound calls or outbound calls and collect detailed CM traces with Sip messages enabled. In the CM traces, all we have to look is the session description protocol (SDP) information. Through CM traces, we can understand if we are sending early offer or delayed offer. (In early offer, we send SDP information alongwith Invite message, the opposite happens in delayed offer.) Below is the snippet of such a scenario- Content-Type: application/sdp v=0 o=CiscoSystemsCCM-SIP 2000 1 IN IP4 <ip address> s=SIP Call c=IN IP4 <ip address> t=0 0 m=audio 25494 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=ptime:20 *a=inactive* a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 Another sample of SDP in such a scenario- v=0 o=CiscoSystemsCCM-SIP 2000 1 IN IP4 <ip address> s=SIP Call c=IN IP4 <ip address> t=0 0 m=audio 18800 RTP/AVP 8 101 a=rtpmap:8...

In the IPT world, IP phones are bound to reset. Sometimes, after firmware upgrade we force phones to reset and other times, due to reboot of the CM server during maintenance window. However, unexpected ip phone reset is a problem. In order to troubleshoot any issue, it is most important to isolate the problem into parts. In an issue of IP phone reset, it is important to collect evidences like-     Is there any error appear on the IP phone screen when it resets?     How many times have phone reset?     How many phones are affected with this behavior?     Is it a progressive issue?     Did we make any changes on UC which might lead to this behavior?     What firmware are affected phones running as compared to working ones?     Are all affected phones connected to the same switch? Unless its not a buggy behavior of phone's firmware, we should check the application logs under s...

Gone are the days, when Cisco only used to manufacture 79XX phone models varying from generation to generation. 7906G, 7911G be one of the first generation phone model to 7965G, 7975G be third generation phones. If you are unfamiliar with this terminology, generation word is used to highlight features, design and model structure of ip phones. Now, you know why third generation IP phones are better than first generation phones ;) Now, Cisco has recently launched new ranges of IP phones, may be because of business requirement and demand in the market. Some of which are 69XX, 39XX , 89XX and 99XX and yes, the outlook is more enhanced and feature savvy. However, since the launch is recent, CTAC and DE has observed some defects on these models which is dependent on their firmwares. In other words, the issue is phone centric and not on CUCM version. I would be discussing couple of defects which I came across while working on 69XX series phones. # The first defect is observed while usi...

It is one of most common issues with backups, it stuck at backing up CCMDB component for an hour or so. And suddenly, we receive error message. Where to look for the error- It is good to visit RTMT and check recent alerts or may be application logs in syslog veiwer to check the error message. You will see a message like below- Error message: CiscoDRFFailure Reason : DRF was unable to backup component CCMDB.Error : Please check the component logs for further details. Why backup was stuck at CCMDB- We get such an error mainly due to CDR entries in the database, which makes the DB too large to backup. If you take a look at the CCM DB component logs, you would be seeing similar messages like below- /var/log/active/cm/cdr_repository/preserve/20091230/cmr_Cluster-C_03_2009123 00317_1559 /var/log/active/cm/cdr_repository/preserve/20091230/cdr_Cluster-C_09_2009123 00317_1562 /bin/tar: -: Wrote only 4096 of 10240 bytes /bin/tar: Error is not recoverable: exiting now CCMDB Backup faile...

If you have read my previous post , you would understand why LA and MA services are important for such a scenario and no component has backed-up, rather you get the above error message. Symptoms -   All Disaster Recovery Framework (DRF) services are down, and no new devices, schedules, or statuses can be viewed from the DRF console. Also, when you access the DRF admin pages, the above error message is received. Affected CM releases 6.1.5 and later. Resolution In order to resolve it, first, verify if the Certificate Serial Number in the keystore of Publisher is present in the Truststore of all Subscribers. Complete these steps: Log on to CUCM OS Administration page of Publisher server of the cluster setup. Choose Security > Certificate Management . The Certificate List window displays. You can use the Find controls in order to filter the certificate. Click on the ipsec.pem file and check the serial number of the certificate. Log on to CUCM OS Admin...

End-of-Life Milestones and Dates for the Cisco MCS H2, I2, H3, and I3 Media Convergence Servers with Unified Communications Manager.   Reference Link.

End Of Sale / End Of Life Announcement of CM versions 4.2, 4.3, 5.1, 5.0, 6.0, 6.1, 7.0, 7.1 and 8.0 respectively.   Reference Link.