Cisco CUCM check database replication via CLI basics

Cisco has made reviewing CUCM server replication on newer versions pretty easy via the GUI. Choose Cisco Unified Reporting in the upper right, log in and choose System Reports | Unified CM Database Status and then choose Generate a new report.

You can also look for 2s in RTMT if that is available.

Sometimes the CLI is the only way to go, and I never remember the exact commands.

Check the DB replication status on all Cisco Unified Communications Manager nodes in the cluster to ensure that all servers are replicating database changes successfully. You can check by using either RTMT or a CLI command.

via CLI:
show perf query class "Number of Replicates Created and State of Replication"

– 0—Replication Not Started. Either no subscribers exist, or the Database Layer Monitor service has not been running since the subscriber was installed.
– 1—Replicates have been created, but their count is incorrect.
– 2—Replication is good.
– 3—Replication is bad in the cluster.
– 4—Replication setup did not succeed.

Just as an aside, there's another CLI command I like, where validate_network is not available via the question mark.  To check network connectivity and DNS server configuration, enter the CLI command below:
utils diagnose module validate_network

Upgrades are prohibited during License Grace Period and licexpiry.txt location

You might sometime find yourself in the position where you need to manipulate files on Cisco CUCM, such as the licexpiry.txt file. Some background on that particular situation can be found here: https://supportforums.cisco.com/message/3923028#3923028

This is something you need to have TAC assist with, as they have methods to generate temporary root access to the Linux OS and these files can't be accessed via the normal platform administration CLI commands.

You may also realize there are plenty of documented methods to gain root access on a Cisco CUCM server yourself, but my favorite, in that it includes good screen shots and Vi text editing keystrokes help can be found here: http://htluo.blogspot.com/2011/08/root-access-on-cucm-and-other-uc.html

Of course, you shouldn't do this.  It's unsupported by Cisco, Cisco TAC, likely voids warranties and service contracts, could be illegal, and who knows what else.  Don't do it.

When Cisco TAC is assisting you, you might find some of the documentation associated with removing the licexpiry.txt file is incorrect.

So...

To find the actual location of the file, you Cisco TAC could run:

find / -iname licexpiry.txt

This should return the real location of the file, something like:

/usr/local/platform/conf/licexpiry.txt

With that information, to remove the file you can run:

cd /usr/local/platform/conf
rm licexpiry.txt

Good luck, maniacs.

Edit 9/30/2013: see http://webmaxtor.blogspot.com/2013/09/upgrades-are-prohibited-during-license.html for some additional information on gaining access to the CUCM file system.

Convert WAV to 8 bit, 8 KHz u-Law format, version 2

So you have a wonderful new recording you would like to upload to Cisco UCCX (or IPCC, Unity Connection, Unity Express, or whatever) and know that it needs to be in a 8bit, 8KHz, u-Law format.

How do you convert it?

In Windows XP, the Sound Recorder application would allow you to simply change the format by opening it, choosing to save it and then selecting Change in the dialog box. The correct format there is Format: CCITT u-Law and Attributes: 8.000 khz, 8 Bit, Mono.

Now that Microsoft has apparently sucked the life out of Sound Recorder in Windows 7, my next preference is using Audacity.  Unfortunately Audacity, while extremely feature rich, can be a bit overkill for this purpose.

If you are so inclined, you can find my original post regarding how to convert files in Audacity here: http://webmaxtor.blogspot.com/2012/05/convert-wav-to-8-bit-8-khz-u-law-format.html

My new preference is using the Windows XP version of Sound Recorder on Windows 7.

What?! How, you say?

The first step is to find an XP machine that you can steal files from. You can find the Sound Recorder executable on a typical XP machine at C:\WINDOWS\system32\sndrec32.exe.  Copy that file and move it to your Win 7 machine's C:\WINDOWS\system32 folder.

Edit 09/14/2015:  You can find a copy of the 32 bit Sound Recorder application from Windows XP by searching for sndrec32.zip here: https://sites.google.com/site/raymaslanka/

Now, running that executable may pop an error indicating "There was an error updating the registry".

Here I suggest you:

• Close the message box.
• Close the Sound Recorder application.
• Right click the sndrec32.exe and choose "Run as Administrator".
• The XP version of Sound Recorder should run without issue.
• Close the application and simply run or open it again, not as an administrator.

If it runs successfully, you should be all set.

To make life easy, now:

• Right click sndrec32.exe and choose Send to | Desktop (create Shortcut)
• Rename the short cut as Sound Recorder XP, or something similar.
• Drag that short cut to the Windows start bubble, over All Programs, over Accessories and wait for the accessories list to expand.  
• Then drop it in the list of accessories.

You should then be able to search for, find and run the Sound Recorder XP application with the CCITT u-Law options, as well as the newer version if you'd like.

TaDa.

Calls from Cisco 9971 / video phones fail

As video enabled phones become more prevalent on users' networks and audio and video enabled devices continue to converge and ride on the same facilities, I imagine this will become a more common problem, but it's the first time I've bumped into it.

The symptom was a user testing new 9971 video phones found they could dial throughout the Cisco CUCM enterprise, and the video feature was attractive.   They then found that they were unable to call from the 9971 phones to the Avaya PBX phones they were migrating away from.  Other 7900 and 6900 series phones could call the Avaya phones without issue.  The facility between the Cisco CUCM and Avaya PBX was an H.323 gateway supporting a single PRI.

Ultimately the issue was that the ISDN Q.931 SETUP message from Cisco indicated the Transfer Capability was Unrestricted Digital, and the Avay PBX was rejecting the call.

The fix was to add bearer-cap speech to the voice port configuration on the H.323 gateway.

An example of the failed call using debug isdn q31 where Transfer Capability = Unrestricted Digital is the offending message is:

Jul 11 15:14:20.163: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x0 0x0, Calling num 3990
Jul 11 15:14:20.163: ISDN Se0/0/0:23 Q931: Sending SETUP  callref = 0x115D callID = 0x90E9 switch = primary-ni interface = User
Jul 11 15:14:20.163: ISDN Se0/0/0:23 Q931: TX - > SETUP pd = 8  callref = 0x115D
Bearer Capability i = 0x8890
Standard = CCITT
Transfer Capability = Unrestricted Digital
Transfer Mode = Circuit
Transfer Rate = 64 kbit/s
Channel ID i = 0xA98387
Exclusive, Channel 7
Calling Party Number i = 0x0081, '3990'
Plan:Unknown, Type:Unknown
Called Party Number i = 0x80, '7121'
Plan:Unknown, Type:Unknown
Jul 11 15:14:20.191: ISDN Se0/0/0:23 Q931: RX < - CALL_PROC pd = 8  callref = 0x915D
Channel ID i = 0xA98387
Exclusive, Channel 7
Jul 11 15:14:20.195: ISDN Se0/0/0:23 Q931: RX < - DISCONNECT pd = 8  callref = 0x915D
Cause i = 0x81D8 - Incompatible destination
Jul 11 15:14:20.195: ISDN Se0/0/0:23 Q931: TX - > RELEASE pd = 8  callref = 0x115D
Jul 11 15:14:20.227: ISDN Se0/0/0:23 Q931: RX < - RELEASE_COMP pd = 8  callref = 0x915D

An example of a successful call at the same site over the same circuit with a Transfer Capability = Speech is here:

Jul 11 15:13:02.743: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0xD is 0x0 0x0, Calling num 7510
Jul 11 15:13:02.743: ISDN Se0/0/0:23 Q931: Sending SETUP  callref = 0x1157 callID = 0x90E3 switch = primary-ni interface = User 
Jul 11 15:13:02.743: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref = 0x1157 
Bearer Capability i = 0x8090A2 
Standard = CCITT 
Transfer Capability = Speech  
Transfer Mode = Circuit 
Transfer Rate = 64 kbit/s 
Channel ID i = 0xA98382 
Exclusive, Channel 2 
Calling Party Number i = 0x0081, '7510' 
Plan:Unknown, Type:Unknown 
Called Party Number i = 0x80, '3427' 
Plan:Unknown, Type:Unknown
Jul 11 15:13:02.767: ISDN Se0/0/0:23 Q931: RX < - CALL_PROC pd = 8  callref = 0x9157
Channel ID i = 0xA98382 
Exclusive, Channel 2
Jul 11 15:13:02.775: ISDN Se0/0/0:23 Q931: RX < - ALERTING pd = 8  callref = 0x9157
Progress Ind i = 0x8188 - In-band info or appropriate now available 
Jul 11 15:13:10.475: ISDN Se0/0/0:23 Q931: RX < - CONNECT pd = 8  callref = 0x9157
Progress Ind i = 0x8182 - Destination address is non-ISDN  
Connected Number i = 0xA1, '3427' 
Locking Shift to Codeset 6 
Codeset 6 IE 0x28  i = 'LAB FAX'
Jul 11 15:13:10.475: %ISDN-6-CONNECT: Interface Serial0/0/0:1 is now connected to 3427 N/A

The change in the configuration to correct the issue was:

2901-VGW(config)#
2901-VGW(config)#voice-port 0/0/0:23
2901-VGW(config-voiceport)#bearer-cap ?
  3100hz   enable 3100hz
  speech   enable speech
2901-VGW(config-voiceport)#bearer-cap speech
2901-VGW(config-voiceport)#

No configuration change in Cisco CUCM was necessary and the voice-port did not need to be reset.

Further information and detail can be found here:
http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a0080569b65.shtml