IPT Buzz

OK, so I upgraded from CUCM 8.6(2) to CUCM 8.6(2a) tonight.  No problems.  Tried doing the same thing with UCXN, but failed with the following entries in the log: 10/11/2011 19:32:43 upgrade_manager.sh| Check if the upgrade is allowed | 10/11/2011 19:32:43 upgrade_manager.sh| Validate hardware for the upgrade | 10/11/2011 19:32:43 upgrade_manager.sh| Hardware is supported for the upgrade | 10/11/2011 19:32:49 upgrade_manager.sh| Validate hardware for "connection" deployment | 10/11/2011 19:32:50 upgrade_manager.sh|File:/common/download/8.6.2.20000-2/upgrade_manager.sh:1048, Function: validate_upgrade_allowed(), This server is not supported for use with the version of "connection" that you are trying to install. For information on supported servers, see the applicable version of the "connection" Supported Platforms List at http://www.cisco.com/en/US/products/ps6509/products_data_sheets_list.html| Seems weird that the hardware is supported for th...

I came across this error the other day on a new UCCX 8 install.  You call into any of the triggers, but disconnects immediately.  Doing a reactive debug shows that it fails on the Accept step in the script with the following error: Contact ID:x, Channel ID:y, Contact is in Terminated/Connected state. You will notice that x and y will change based on your call attempts.  I tried upgrading to 8.5(1)SU1 and 8.5(1)SU2, but didn't help. Also, in the trace files that you can grab via RTMT, you will see the following entry: 4323: Oct 01 10:25:12.495 CDT %MIVR-SS_TEL-7-UNK:CallID:4 MediaId:5937/2 Task:17000000003, CallCtlConnFailed, Inbound call, callctl cause:107, [6612:PT_Internal:1/(P1-jtapi_1) GCID=(2,4323)->ACTIVE]->FAILED Now, ask anyone else, any you will most likely be told that it is a codec issue 99% of the time with a callctl cause of 107.  That is true.  But, in this case, it is not. The fix is to create a new Media Termination...

If you are like me, then you probably have some type of home lab running the UC products such as CUCM, UCXN, CUPS, UCCX, etc, in either VMware Workstation or ESXi.  I have seen an issue on CUCM, but now almost everytime after I reboot UCCX 8.x and higher, I can't ping to or from the UCCX server.  From the CLI of the UCCX server, I can only ping it's eth0 address and can't ping anything else.  From other devices, I can't ping UCCX.  Rebooting doesn't help.  The only way I can get network connectivity is to run the set network status eth0 down command followed by the set network status eth0 up  command.  After a few seconds, everything works just fine. Anyone know how to get around this without having to take the eth0 interface down and up? ***ADDED ON 10/16/2011*** I had the same issue on CUPS when I upgraded to CUPS 8.6.1.10000-34.  I would lose network connectivity to the CUPS server in the VM.  From the console, I could the address ...

If you have a UCS chassis where the VMs go offline and you can't access the VMs with vSphere, you may have to reboot the chassis via the IMC web interface.  But, when you reboot it and watch it via the IP KVM console, this is what you don't want to see: LSI MegaRAID SAS-MFI BIOS Version 3.20.00 (Build November 19, 2010) Copyright(c) 2010 LSI Corporation HA -0 (Bus 14 Dev 0) LSI MegaRAID SAS 9261-8i FW package: 12.12.0-0038 Multibit ECC errors were detected on the RAID controller. The DIMM on the controller needs replacement. Please contact technical support to resolve this issue. If you continue, data corruption can occur. Press 'X' to continue or else power off the system and replace the DIMM module and reboot. If you have replaced the DIMM press 'X' to continue. OK, so get TAC on the phone and have them send you the replacement controller.  Hopefully, you have 4 hour response.  Here is the link to replace the RAID controller in the...

I ran into an issue recently running UCCX, although this has also happened to me on CUCM as well.  Let me make it known that these are running in VMware Workstation in a home lab.  In my recent attempt, I upgraded UCCX 8.5(1)SU1 to UCCX 8.5(1)SU2.  After the upgrade, I tried to perform a switch version from the OS Administration GUI.  But, watching from the CLI, nothing was happening.  So, I tried to switch it from the CLI with the utils system switch-version  command, but got the following output: admin: utils system switch-version Active Master Version: 8.5.1.11001-35 Inactive Master Version: 8.5.1.11002-22 If you are switching to an earlier release, you must run: utils dbreplication reset all from the publisher after all the nodes are switched over. Modified configurations will not be migrated in case you are downgrading this server to an earlier release level Do you really want to switch between versions ? Enter (yes/no)? yes ...