CUCM Device Packs

I was running a DX80 with a CE firmware load but the lab CUCM we had installed did not support the CE Version of code, when i first tried registering the endpoint to the CUCM it came up with the following error: Failed: 485 Ambigious / Device Type Mismatch,i had a look at CUCM to see if the device load was installed but only the “Cisco DX80” endpoint was available. This is the Android version of the DX which is not the same as the ‘Cisco TelePresence DX80’ you see on the web browser of the endpoint.

for this you need to install the relevant device pack to get the ball rolling and endpoint registered.

These notes are applicable on the following versions but tested for 10.5(2)

  • Unified CM 11.5(1)
  • Unified CM 11.0(1)
  • Unified CM 10.5(2)
  • Unified CM 9.1(2)

Step 1: Verify the CUCM Version you are running

From web browser > About

ccm version

you can also get this information from the web browser:

admin: show version active
Active Master Version: 10.5.2.10000-5

or

admin: show  status

Host Name         : cucm01
Date                      : Tue Aug 29, 2017 14:44:48
Time Zone          : British Summer Time (Europe/London)
Locale                   : en_US.UTF-8
Product Ver        : 10.5.2.10000-5
Unified OS Version : 6.0.0.0-2

Step 2: Download the Appropriate Device Pack

Install a the relevant device pack for the endpoint that you wish to configure on the CUCM, in this case the DX80 is not a ‘native endpoint in cucm as such a device pack will need to be installed:

Device Type Device Release Unified CM 11.5(1) Unified CM 11.0(1) Unified CM 10.5(2) Unified CM 9.1(2)
DX70 and DX80 Collaboration Endpoint Software 8.3 cmterm-devicepack11.5.1

April 4, 2017

cmterm-devicepack11.0.1

April 4, 2017

cmterm-devicepack10.5.2

April 4, 2017

cmterm-devicepack9.1.2

April 13, 2017

Collaboration Endpoint Software 8.3 cmterm-devicepack11.5.1

Nov 30, 2016

cmterm-devicepack11.0.1

Nov 30, 2016

cmterm-devicepack10.5.2

Nov 30, 2016

cmterm-devicepack9.1.2

Dec 27, 2016

Please note:

  • A valid cisco support contract will be needed
  • Device package compatibility matrix is located here

 

Step 3:  Upload Device pack to CUCM

3a) in OS Administration under  >  Software Upgrades > Installation/Upgrade > Chose the Remote File system where your device pack is located.

3b) verify MD5 hash with cisco.com downloads page where you installed the file from

Step 4: Restart TFTP Service

Control Center – Feature Services > Cisco Tftp > Restart

Step 5: Install Phone

now if you go to add new phone (device>phone) or go to device defaults (Device> Device Settings>Device Defaults) you will see the new device types:

Cisco TelePresence DX70
Cisco TelePresence DX80

 

Advertisements

Death to the phones of old

As of CUCM version 11.5 Cisco has finally removed support for the legacy phones, now when i say Legacy i mean really old phones.. i understand why theyve removed its support and have always been impressed on why they have had these in for so long. They make some really tough phones, I remember visiting a customer site with a really intense call center and phone usage. they had 7940’s IP phones whose key pad was completely worn out but the phones were just slogging away.the customer saw no need to replace the perfectly functioning IP Phones. I dont think this customer will be upset that Cisco has made this announcement because they are not affected

… but i will surely be 😦 i have a 12SP phone, one of the first IP Phones from the Selsius days that i managed to get from a friend @ cisco. i still use it from time to time but looks like i will be adding it to my museum with great regret .. if i decide to upgrade 😀

CX42n3EW8AAqBLn.jpg large

enough with the reminiscing, here are the affected IP phones:-

  • Cisco IP Phone 12 S
  • Cisco IP Phone 12 SP
  • Cisco IP Phone 12 SP+
  • Cisco IP Phone 30 SP+
  • Cisco IP Phone 30 VIP
  • Cisco Unified IP Phone 7902G
  • Cisco Unified IP Phone 7905G
  • Cisco Unified IP Phone 7910
  • Cisco Unified IP Phone 7910G
  • Cisco Unified IP Phone 7910+SW
  • Cisco Unified IP Phone 7910G+SW
  • Cisco Unified IP Phone 7912G
  • Cisco Unified Wireless IP Phone 7920
  • Cisco Unified IP Conference Station 7935

 

11.5 release notes

 

CUCM 7.1.3 upgrade -> 7.1.5 procedure

Upgrade Process for CUCM v7.1.3 -> 7.1.5

Step 1: go to Cisco.com and download the UCS files

UCSInstall_UCOS_7.1.5.10000-12.sgn.iso_part1of2
UCSInstall_UCOS_7.1.5.10000-12.sgn.iso_part2of2

Step 2: Once downloaded combine the files and burn the .ISO to CD
you can combine the fine in Windows via the c ommand prompt using teh following command:

COPY /B UCSInstall_UCOS_7.1.5.10000-12.sgn.iso_part1of2+UCSInstall_UCOS_7.1.5.10000-12.sgn.iso_part2of2 UCSInstall_UCOS_7.1.5.10000-12.sgn.iso

Step 3: Verify the Checksum Value

64fa77e1ec9c9ede6f4066e36b631954 UCSInstall_UCOS_7.1.5.10000-12.sgn.iso

Step 4: insert the Disk to the local server where you wish to install the upgrade and navigate to Upgrades > Install/Upgrade.
The Software Installation/Upgrade window displays.
From the Source list, choose DVD.
Enter a slash (/) in the Directory field.
Press Next to continue

or utils system upgrade from the CLI

Step 5: you have the option to “reboot to upgraded partition” or “Do not reboot after upgrade.” select the latter and next

You can check the installation status on the CLI:

Step 6: When installation is completed, select Finish

Step 7: To Upgrade choose: Settings > Version; then, click Switch Version.
The system restarts and runs the upgraded software

or Via the CLI:

utils system switch-version

Perform Upgrade on the Publisher first then subsequent subscriber nodes. Finally perform a DBreplication repair on the publisher

utils dbreplication reset all

Continue reading

Cluster Manager service connectivity test

Dec  10 12:04:54 AXD-SUB1 local7 6 : 2432: Dec 10 12:04:54.257 UTC :  %CCM_CLUSTERMANAGER-CLUSTERMANAGER-6-CLM_PeerState: Current ClusterMgr session state. Node’s Name or IP:AXD-PUB Node’s State:POLICY_INJECTED App ID:Cisco Cluster Manager Cluster ID: Node ID:AXD-SUB1

noticed the above notification in the CUCM syslog every few minutes. This is a connectivity test performed by the CUCM cluster manager service to the Publisher . This is a unecessary alert as there is no policy state change.

This can only be stopped by a TAC Engineer, the process is as follows:

1) Create a TAC user account

admin:utils remote_account enable
admin:utils remote_account create ciscotac 30

2) on the Subscriber stop the Cluster Manager Service

admin:utils service stop Cluster Manager
Service Stopped
Cluster Manager [STOPPED]

3) Cisco TAC will apply the following command in root to disable cluster manager notification:-

[root@AXD-SUB1 ~]# /usr/local/platform/bin/clm/clm_ctl set clm_network_test_timer 0

4) restart the service cluster manager service

admin:utils service start Cluster Manager
Service Started
Cluster Manager [STARTED]

This Service may cause drop outs on the phone system, and best done out of hours. It takes a few minutes (more like seconds) to complete. Continue reading

Extracting the MoH file from CUCM

something i noticed while looking through the DRF was the location of the MoH files,

====================================
Server        : BMML-PUB
Feature       : CCM
Component     : MOH
Time Completed: 2011-12-01-09-37-57
Result Code   : 0
Result String : SUCCESS
===================================

moh_do_backup.py: Backing up the MOH files
/usr/local/cm/sftp/mohprep/CiscoMOHSourceReport.xml
/usr/local/cm/sftp/mohprep/SampleAudioSource.alaw.wav
/usr/local/cm/sftp/mohprep/SampleAudioSource.g729.wav Continue reading

Bouncy Castle .. All childs play

i was having a look through the DRF log files into why they failed, and noticed Bouncy Castle service inserted to the security paameters, amused by the name, i googled it….. nothing special, its just a bunch of API’s used in cryptography and used by Java and C#

2011-12-02 09:45:45,472 DEBUG [main] – drfNetSSLManager: initSecurityProvider:  Bouncy castle provider inserted into list of Security Providers
2011-12-02 09:45:45,472 DEBUG [main] – drfNetSSLManager: initSecurityProvider:   Installed Provider After adding Bouncy Castle BC
2011-12-02 09:45:45,472 DEBUG [main] – drfNetSSLManager: initSecurityProvider:   Installed Provider After adding Bouncy Castle SUN

more info on Bouncy Castle  http://en.wikipedia.org/wiki/Bouncy_Castle_(cryptography)

accessing the Core dump File

This section forms part of my diagnosis on a failed subscriber and the identification onto why it failed, The CUCM creates a core dump file when it experiences a fault.

This can be found on the RTMT Alert central and the Application Event log:-

 Nov 30 00:19:35 BMML-SUB1 local7 2 : 0: Nov 30 00:19:35.810 UTC :  %CCM_LPM-LPMTCT-2-CoreDumpFileFound: The new core dump file(s) have been found in the system. TotalCoresFound:1 CoreDetails:The following lists up to 6 cores dumped by corresponding applications. Core1:Cisco CallManager (core.2951.6.ccm.1322612299) App ID:Cisco Log Partition Monitoring Tool Cluster ID: Node ID:BMML-SUB1 Continue reading