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

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

Intermittent call drops

Symptom:

Slp_servreg process causes high cpu utilization on a Unified Communications Manager server.

Conditions:

Problem is observed for IBM model servers only.

This particular defect is applicable to UCM ver 7.x only.

Workaround:

From the command line interface, issue the “utils snmp hardware-agents restart” command. This should resolve the issue. If not, a server reboot may be necessary.

Bug ID:  CSCte21646

CM to CUE Voicemail problem

scenario #
CM -> Gatekeeper -> CME -> CUE

Problem
When CUCM user calls CME User and reaches voicemail, the call fails. they get a fast busy tone.

I had a look to see whether it was transcoding, but it wasnt

CME#sh scc connections

Total number of active session(s) 0, and connection(s) 0
CME#

i came to the realisation that the incoming dial-peer was negotiating a codec,

!
dial-peer voice 2300 voip
translation-profile incoming in
voice-class codec 2
incoming called-number .

voice class codec 2
codec preference 1 g729r8
codec preference 2 g711ulaw

in this case it negotiated inbound to g.729.

Since CUE is g711, here it is supposed to invoke a transcoder, but it wasnt

when i removed the voice-class codec call was successful

dial-peer voice 2300 voip
no voice-class codec 2

In summary, i dont know if this is a bug or something, but once the codec has been “negotiated” the CME fails to invoke the transcoder. By removing the codec negotiation, the transcoder was invoked and call was successful

CME#sh scc conn
sess_id    conn_id      stype mode     codec   sport rport ripaddr

1          2            xcode sendrecv g711u   17806 2000  10.10.1.254
1          1            xcode sendrecv g729    18138 2000  10.10.1.254

Total number of active session(s) 1, and connection(s) 2