Debugging VOIP with Shikha Sharma #CiscoKid

Its good to write again. Had to take a break in between but it got longer than I thought. Anyways, getting back to our query of the day, I think it would be helpful for many engineers while dealing with this piece of information. I faffed on google too but there was no information on how to check hardware model from windows call manager as nobody was at site While clutching at the straws, I was browsing regedit and it came across. Here is the path- HKEY_LOCAL_MACHINE > Software > Cisco Systems > Model- Hardware. I hope it will help you too.

Primarily, such issues are the cause of configuration negligence. Below is what we need to make sure to make it work- 1. Make sure that phone and gateways have right MRGL. 2. MRGL should contain required MOH server resources. 3. Make sure that MOH servers are registered with respective CUCM nodes. 4. MOH files need to be uploaded on all IPVMSA servers. 5. The format of the MOH file should be .raw, for linux platforms. If you started facing this issue all of a sudden, then IPVMSA might got stuck and you need to restart IPVMSA service on all nodes. Please make sure to take IPVMSA and CUCM traces on the detailed level in order to find out RCA of the issue.

Understanding sample code yellow alert- Oct 3 01:00:10, cms01, Error, Cisco CallManager, ccm: 147896: Oct 03 05:00:10.616 UTC : %CCM_CALLMANAGER-CALLMANAGER-3-CodeYellowEntry: CodeYellowEntry Expected Average Delay:362 Entry Latency:20 Exit Latency:8 Sample Size:10 Total Code Yellow Entry:14 High Priority Queue Depth:2 Normal Priority Queue Depth:12 Low Priority Queue Depth:70 Cluster ID:StandAloneCluster Node ID:cms01, 3652 The above alert is about code yellow entry, it shows the time when server enters code yellow state. There are no specifications to note at this alert, CM enters code yellow when it achieves the mentioned conditions for code yellow state as mentioned in service parameters. Oct 3 01:00:12, cms01, Error, Cisco CallManager, ccm: 147897: Oct 03 05:00:12.268 UTC : %CCM_CALLMANAGER-CALLMANAGER-3-CodeYellowExit: CodeYellowExit Expected Average Delay:0 Entry Latency:20 Exit Latency:8 Sample Size:10 Time Spent in Code Yellow:2 Number of Calls Rejected Due to C

Here is the link to download webex connect- http://download.webexconnect.com/connect/webexconnect.exe

Here is the link from where you can download webex recording player- http://www.webex.com/play-webex-recording.html Hope it helps!

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                               Now, pull the CAR scheduler traces and check why CAR was not loading the data after 16th. Generally there is a bad CDR

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</LicLineID> \     <PAK>&

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 syslog viewer in RTMT to understand the reason code of the phone reset. You would see an RTMT messa

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 Administr

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.