The Call Detail Records (CDR) and Call Measurement Records (CMR, also referred as “Call Diagnostics Records”) offer details for each phone call passing by the Cisco Unified Communications Manager (CUCM). In CUCM CDR CMR records are disabled by default, so that you have to enable them manually.
You can enable CDR and CMR in CUCM by following steps below:
How to Enable Call Detail Record (CDR) on CUCM:
Login to administration page on Publisher CUCM. Click System -> Service Parameters menu.
2. Then select your server which has callmanager service enabled and then select Cisco CallManager (Active)
3. On System section find CDR Enabled Flag Parameter and set to True. If you’d like to see calls with zero duration, find CDR Log Calls with Zero Duration Flag (just below the CDR Enabled Flag)and set to True.
4. Do this for each CUCM Server if you have more than one server that has Callmanager service enabled.
How to Enable Call Measurement (CMR) on CUCM:
On the same Service Parameter menu, go up and click Advanced.
2. Find the Clusterwide Parameters section, and change Call Diagnostics Enabled Parameter from Disabled to which option you wish.
Note: Since CMR parameter is in Clusterwide Parameters, you don’t need to enable this on each server.
Sometimes when you go through RTMT logs on a Cisco Unified Communicatios Manager (CUCM), you can see a critical warning of “LogPartitionLowWaterMarkExceeded“. This happens when free space in CUCM common partition becomes low.
In most cases this problem doesn’t affect the whole system to function, but the low space on disk may cause problems if you want to do some installation (eg. device pack) or upgrades.
CUCM common partition is also called as log partition and is mostly filled with CDRs, CUCM traces and phone firmware files from TFTP server. LogPartitionLowWaterMarkExceeded alarm is occured when the log partition disk space percentage reaches the “Low WaterMark” treshold. You can take this alarm as an early notification to clean up the disk space. CUCM doesn’t have such kind of automated cleanup process until the “High WaterMark” value is reached.
What Should I Do To Clean CUCM Common Partition?
To clean up and free some space in the common partition, you can do the following:
Change the threshold values of LogPartitionLowWaterMarkExceeded to 50% and LogPartitionHighWaterMarkExceeded to 60%, and then restart “Cisco Log Partition Monitoring Tool” service and after couple of hours you should see that the used space is decreased.
Delete unused log by using RTMT Trace/Log Central to collect logs/traces with “Delete Collected Log Files from Server” option.(this is for both active and inactive partitions). Select relateive range as 8-9 years to delete all unused logs.
Delete the old unused phone firmware files from the TFTP server.
Use CUCM script called ciscocm.free_common_space_v1.1.cop.sgn (you can find & download it in cisco.com) that deletes all files from the inactive common partition. But please be informed that after using this script, you won’t be able to switch to previous CUCM version.
If you want to reduce the CUCM common partition usage, you can do the following:
Deactivate Detail/Debug trace level.
Reduce the number of trace files to be stored.
For CDR: reduce the High Water Mark, reduce the occupied disk space, and reduce the number of days to store CDRs.
Initial Information About CUCM 14 & IP Phones That Won’t Be Supported
After version 12, CUCM will jump 13 for suchreasons, and will probably appear as 14 early next year. In version 14, as in the 11.5 and 12 versions, some IP phones will not be supported either.
IP Phone Models Won’t Be Supported in CUCM 14
With the CUCM version 14, some IP phone models that have been in the market for many years will no longer be available. The following list includes models that will not be supported:
Cisco Unified IP Phone 3911, 3951
Cisco Unified IP Phone 6911, 6921, 6941, 6945, 6961
If you are using any of these phone models, CUCM will block registration for these phones after upgrading to CUCM version 14. If the IP phone stays on, it will create unnecessary network traffic as well as load the CallManager service as the phone will try to register itself again and again.
Reasons For Not Supporting These Phones
Apparently Cisco will only use the 7800 and 8800 series telephones at the end of the day, and the reasons for this are explained in four subheadings:
Security – Because older phone models cannot receive critical software updates, to protect users as new security issues arise.
New Features and Applications – Since some phone models have been introduced many years ago (eg, 7900 series was introduced in early 2000’s), the older processors and hardware in these phone models creates a number of problems in implementing new applications and security features, so that the user experience can not be maximized.
Sustainability – To ensure sustainability because older phones no longer have development support or regression tests.
End-of-Life Products – The phone models listed above have made end-of-sale and end-of-life announcements in the past. These phone models will expire when the CUCM 14 is launched.
If you have a plan to upgrade to CUCM 14 and you have older model phones that is no longer supported, Cisco offers the following advice:
Identify unsupported phones and schedule your upgrade to version 14 on time.
Take advantage of competitive trading programs (Trade-in, Cisco Capital, etc.) or work with Cisco teams to cost-effectively renew the phones.
Consider the strategy of migrating to software-based end devices like using Jabber.
Talk with Cisco partners about switching to 7800 and 8800 series IP phones which are supported.
You can find the Field Notice on Cisco.com by clicking this link.
Hello, in this article you can find the configuration steps to change the CUCM IP address and hostname.
CUCM Changing IP Address & Hostname
Note 1: Before you start, if you plan to change the hostname, make sure that the corresponding DNS records are also updated. Otherwise you may experience communication problems.
Note 2: If you are going to change the IP addresses or hostnames of all nodes on a CUCM cluster, start from Publisher first. And then change the Subscribers individually.
After these warnings, now we can start:
1. Connect to CUCM OS Admin CLI via SSH and use the following command to change the hostname:
admin:set network hostname
ctrl-c: To quit the input.
*** W A R N I N G ***
Do not close this window without first canceling the command.
This command will automatically restart system services.
The command should not be issued during normal operating
hours.
=======================================================
Note: Please verify that the new hostname is a unique
name across the cluster and, if DNS services are
utilized, any DNS configuration is completed
before proceeding.
=======================================================
Security Warning : This operation will regenerate
all CUCM Certificates including any third party
signed Certificates that have been uploaded.
Note: For hostname changes, if your CUCM or cluster uses certificates that are signed by a CA, you will need to sign these certificates again according to the new hostname and upload them to the CUCM. If self-signed certificates are used, this process will be renewed automatically and your endpoints will be reset to receive the new ITL file.
2. Enter the hostname after reading the warnings:
Enter the hostname:: cucm
3. If you want to change the IP address, subnet mask and default gateway, enter the relevant information followed by yes:
Would you like to change the network ip address at this time [yes]:: yes
Warning: Do not close this window until command finishes.
ctrl-c: To quit the input.
*** W A R N I N G ***
=======================================================
Note: Please verify that the new ip address is unique
across the cluster.
=======================================================
Enter the ip address:: 192.168.0.137
Enter the ip subnet mask:: 255.255.255.0
Enter the ip address of the gateway:: 192.168.0.1
4. The information you entered will be displayed on the screen. If all are true, you can start the change process by typing yes:
Hostname: cucm
IP Address: 192.168.0.137
IP Subnet Mask: 255.255.255.0
Gateway: 192.168.0.1
Do you want to continue [yes/no]? yes
calling 1 of 5 component notification script: ahostname_callback.sh
Info(0): Processnode query returned =
name
==========
bldr-vcm18
updating server table from:'oldHostname', to: 'newHostname'
Rows: 1
updating database, please wait 90 seconds
updating database, please wait 60 seconds
updating database, please wait 30 seconds
Going to trigger /usr/local/cm/bin/dbl updatefiles --remote=newHostname,oldHostname
calling 2 of 5 component notification script: clm_notify_hostname.sh notification
Verifying update across cluster nodes...
platformConfig.xml is up-to-date: bldr-vcm21
cluster update successfull
calling 3 of 5 component notification script: drf_notify_hostname_change.py
calling 4 of 5 component notification script: regenerate_all_certs.sh
calling 5 of 5 component notification script: update_idsenv.sh
calling 1 of 2 component notification script: ahostname_callback.sh
Info(0): Processnode query returned =
name
====
Going to trigger /usr/local/cm/bin/dbl updatefiles --remote=10.10.10.28,10.67.142.24
calling 2 of 2 component notification script: clm_notify_hostname.sh
Verifying update across cluster nodes...
Shutting down interface eth0:
If your CUCM or cluster is in mixed-mode, and you have done this with the CTL Client, run the CTL client again and update the CTL file. If you used tokenless CTL, run utils ctl update CTLFile from CLI to update the CTL file.
Hello everyone, in this article you can find out how to delete unused / unassigned internal directory numbers (DNs) defined on Cisco Unified Communications Manager (Callmanager, CUCM).
When a DN defined in CUCM is removed or updated from the device (eg phone), or when a phone is deleted, the corresponding DNs are not removed from the CallManager database. These DNs remain in the database as Unassigned DNs.
DNs that remain idle on the CUCM occasionally cause problems such as inability to forward calls and failed calls, and it seems that there is no cause at first glance , it usually takes a lot of time to fix the problem. In order to avoid these situations, the best thing to do is to delete the unused DNs from the system. You can do this by following the procedure below:
Note: In some cases, unused DNs can also be used to forward the call to voicemail or another destination (CAll Forward All). For this reason, you should check the DNs listed while you are doing this, just in case you do not have headaches in the future ?
1.Login to the CUCM Administration page and select Route Plan Report from Call Routing menu:
CUCM – Route Plan Report Menu
2. Select Unassigned DN from the Find menu and click Find:
Select “Unassigned DN” From Find Menu & Click Find
3. Click Select All to select all of the DNs listed and clik “Delete Selected”, then confirm the dialog box:
Select All Unused Extensions With “Select All”, Click “Delete” & Confirm
That is all. Extension numbers that are no longer used are deleted from the CUCM database. You can also follow this procedure in the following video:
