- CTI Port not registering GetAvailWave() returned WAVELIST_NOT_ASSIGNED, Fixed CSCtw79059 - Symptom:
CTI Ports not registering. Seeing the following errors in the TSP traces
06115: 16:09:02.692 | CSelsiusTSPWaveList::GetAvailWave() *ERROR* No wave available
06117: 16:09:02.692 | CSelsiusTSPDevice::ReserveMediaChannel() addr. mode [0] *ERROR* GetAvailWave() returned WAVELIST_NOT_ASSIGNED
Conditions: CUCM 8.6.2.20000-2 with TSP version 8.6(2.2) on Windows 2008 Service Pack 2 32 -bit
Workaround: None - CM 8.6.2 Upgrade Failing Due to NTP Reachability, Fixed CSCtt18005 - Symptom:
During upgrade to CM version 8.6.2, we observe the following error with respect to NTP reachability:
09/27/2011 19:37:01 ntp_one_shot.sh|NTP servers list: 10.127.0.1 10.227.0.1 10.127.0.54|
Conditions: Perform upgrade to CM 8.6.2.10000-30 while NTP references are defined and unreachable.
Workaround: Remove configured NTP references before performing 8.6.2 upgrade attempt. - IOS : Dspfarm/Transcoder SCCP session gets hung for non supported codec, Open CSCtx35461 - <B>Symptom:</B> VoIP calls requiring transcoding not completing. Sh sccp connection shows hung sessions. <B>Conditions:</B> Transcoder under CUCM control. <B>Workaround:</B> Issue shut/no shut under dspfarm profile to clear sccp session. ***NOTE: THIS WILL DROP ALL ACTIVE CALLS THRU THE TRANSCODER AS WELL. Example: c2951(config)#dspfarm profile 1 c2951(config-dspfarm-profile)#shut Disabling profile will disconnect active TRANSCODING calls, do you want to continue ? [yes/no]yes c2951(config-dspfarm-profile)#no shut
- ITA+CAT:Mobile extension cannot be changed, Fixed CSCts10309 - Symptom:
User not able to save Alternate Number through Cisco Unified CM User Options.
Conditions: Browser locale set to German, Catalan, or Italian.
Workaround: Change browser locale to English. - Phone services do not work, select service displayed on the phone, Terminated CSCtx59395 - Symptom:
Selecting any of the built in phone services (Missed Calls, Received Calls, Placed Calls, Personal Directory, Corporate Directory, Intercom Calls, or Voicemail) the phone displays "Select a Service" after the service has been selected.
Conditions: To verify this problem, enter the service URL into a browser: https://:8443/ccmcip/xmldirectory.jsp (View page source from the browser since the browser doesn't understand the phone specific tags, to see something like the following) Select a directory tag, this bug is not the problem. The following phone models will not be able to access the default phone services, 7941/7961/7942/7962/7945/7965/8941/8961/8945/9951/9971 running firmware version 9.x or later. CIPC and 7940/60 phones will be able to access the problem services correctly because they do not support HTTPS phone services. CIPC and 7940/7960 phones or phones running firmware versions earlier than 9.x will access the non secure URL which should be populated with "application:Cisco/ ". To further validate this bug go to the CCMAdmin page under Device > Device Settings > Phone Services, and select any of the built in phone services. NULL is seen for the Secure-Service URL field in this case.
Workaround: The cause is unknown at this time, please contact Cisco TAC so the information required find the cause can be collected. After contacting Cisco TAC and the correct data has been collected to try and identify the cause of this issue, manually delete the "NULL" entry for each phone service Secure-Service URL under Device > Device Settings > Phone Services. This will allow phones to access the default phone services again. - Tomcat - unusually large number of active sessions error, CSCtl63367 - Symptom:
When running "utils diagnose test" on 8.5.1.11002-1, I see:
test - tomcat_sessions : Failed - The following web applications have an unusually large number of active sessions: ==>query . Please collect all of the Tomcat logs for root cause analysis: file get activelog tomcat/logs/*
No other symptoms were noticed.
Conditions: Normal conditions
Workaround: None known. However, this is a false positive and can be safely ignored, If the message indicated an actual Cisco webapp instead of " ==>query" then action would be required. - CUCM 8.6 Tomcat OOM with "com.rsa.sslj.x.cu" suspect under high AXL Load, Open CSCtw63984 - Symptom:
Tomcat becomes unreachable or inaccessible after a number of days. So far the observed timeframe tends to be between 7 and 20 days.
If the generated hprof shows the main suspect as "com.rsa.sslj.x.cu" then this is most likely the cause.
Conditions: This has been observed in environments where a very large number of AXL queries are done on the CUCM server.
Workaround: Restart the Tomcat service on the CLI using "utils service restart Cisco Tomcat". Turn off the AXL queries. - CUCM 8.6.1 auto registraion is not working, Fixed CSCtx33094 - Symptom:
8.6.1-20000-1 auto registration is not working.
RegisterReject text='Error: DB Config'
Conditions: Very short network glitch between publisher and subscriber
Workaround: none - CUCM 8.5.1 (SU3) 7835/45-I2 IBM Raid driver reverts back during L2, Fixed CSCtx25915 - Symptom:
File system goes read only after L2 upgrade to CUCM 8.5.1(SU3) from 8.5.1(SU1/2) with the cop file installed as the IBM raid driver resets back to 1.1.5-2455.
IBM Raid driver rpm for aacraid version 1.1.5-24702 is installed but not loaded.
when ssh into server we see the following message:
java.io.FileNotFoundException: /var/log/active/platform/log/cli.bin (Read-only file system)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.
(RandomAccessFile.java:212)
Conditions: Occurs only on 7835/45-I2 class of servers and only after they've been L2 upgrade to CUCM 8.5.1(SU3) release from 8.5.1(SU1/2) with the COP file installed. This does not apply if there is fresh install.
Workaround: A workaround to the bug can be applied by TAC using root account. However, Rebuild of the server is a permanent solution to read-only problem. Use of the file system repair on the recovery disc does not guarantee a fully functioning system. Even if the server is recovered into an operable state, full functionality of all features and services cannot be guaranteed. Cisco strongly recommends a server rebuild if the file system has become corrupted to ensure full functionality. - L2 upgrade 8.6.1.10000-26->8.6.1.10000-43 fails when locales installed, Open CSCtq97369 - Symptom:
L2 upgrade 8.6.1.10000-26->8.6.1.10000-43 fails when locales installed
Conditions:
Workaround: Uninstall the locale, and restart the upgrade. - Cisco Jabber for Android client is unable to register, CSCtq79475 - Symptom:
Android Client is unable to register with the CUCM after it loses wi-fi connectivity and regains connectivity.
Conditions: Android Device on CUCM doesn't have "Enable Cisco Unified Mobile Communicator" flag checked.
Workaround: Check "Enable Cisco Unified Mobile Communicator" flag on the Cisco DualMode Android Device page on CUCM. This should help the client in registering. - Upgrade fails in DB Migration from 6.x / 7.x CUCM to 8.x +, Terminated CSCts34871 - Symptom:
Upgrade Failed with DB Migration Error but with no apparent data problem.
Older CUCM, (6.x or 7.x), to Later CUCM, (8.x +). Upgrade installdb log
indicates a communication or connection issue.
From "installdb_l2.log":
08:55:32.566 | BulkMigrationTarget::BulkMigrationTargetPrepare *ERROR*
BulkMigrationTarget Object Setup Failed: [Error executing "SELECT COUNT(*) AS
CurRecCount FROM ccm7_1_3_30000_1@ccmpub01_ccm7_1_3_30000_1:timeperiod ":
[Informix][Informix ODBC Driver][Informix]Error on remote connection,
ccmpub01_ccm7_1_3_30000_1, conerr=-25582, oserr=107, errstr=.]
Conditions: - Older CUCM, (6.x or 7.x), to Later CUCM, (8.x +). - Upgrade installdb log indicates a communication or connection issue in BulkMigration.
Workaround: Plan A) Reboot and attempt the upgrade again, and it should work the second time. Plan B) (May not be available on some installations such as CUCMBE3K.) Use the Administrative CLI to turn off the Enhanced Upgrade processing for your system. To do that, use the following 2 commands: run sql DELETE Scratch WHERE Name LIKE '%ableBulkTableCopy' run sql INSERT INTO Scratch (Name) VALUES ('DisableBulkTableCopy') - Doc: CUCM publisher only bridge upgrade DRS backup fails, Fixed CSCtw75986 - Symptom:
Unable to backup Cisco Unified Communications Manager (CUCM) during a bridge upgrade. The Disaster Recovery System (DRS) web page hangs as well as "utils disaster_recovery" commands from the command line.
Conditions: Multiple servers in the CUCM cluster but only some of the CUCM servers have been upgraded. The servers that have not been updated are also able to reach the publisher over the network.
Workaround: Shutdown any server that has not been upgraded to match the newer CUCM version running on other nodes or upgrade the remaining servers to the same exact CUCM version. Or follow the bridge upgrade procedure which states that all servers in the cluster should be upgraded before trying to take a backup using the Disaster Recovery System (DRS): http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/cucos/8_0_2/cucos/iptpch7.html#wp1058411. The reason for this is to backup any files that are local to the subscribers (not replicated, such as MoH files or custom TFTP files). - UCS CUCM 8.5 coredump, Fixed CSCts29293 - Symptom:
CUCM 8.5.1 on UCS platform crashes in CCM process.
Typical coredump:
backtrace
===================================
#0 0x001487a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x014e9825 in raise () from /lib/tls/libc.so.6
#2 0x014eb289 in abort () from /lib/tls/libc.so.6
#3 0x0a0a39a8 in SdlMsgQueueCirc::enqueueSignal (this=0xc3e2f50, msg=0x8dc91590, priority=2) at SdlMsgQueueCirc.cpp:136
#4 0x0a0754f4 in SdlRouter::enqueueSignal (this=0xc3e0b30, sdlSignal=0x8dc91590) at /view/BLD-cm_su2_8_5_1-cct-ccm-d/vob/ccm/Common/Include/Sdl/SdlMsgQueue.hpp:58
#5 0x0a075d90 in SdlRouter::route (this=0xc3e0b30, vSenderPID={mSdlProcessName = 0x0, mSdlNodeId = 3, mSdlAppId = 100, mSdlProcessNumber = 169, mSdlProcessInstance = 5402}, vDestinationPID={mSdlProcessName = 0x0, mSdlNodeId = 3, mSdlAppId = 100, mSdlProcessNumber = 157, mSdlProcessInstance = 1228}, vSdlSignalTag={tagId = 401196, pid = {mSdlProcessName = 0x0, mSdlNodeId = 3, mSdlAppId = 200, mSdlProcessNumber = 17, mSdlProcessInstance = 1}, userInfo1 = "SEP0017E0D822A0", '\0'
, userInfo2 = "10.130.20.207", '\0' }, vSignalPriority=kDeletePriority, rSignal=@0x76042e0) at SdlRouter.cpp:343 #6 0x0a070351 in SdlProcessBase::output (this=0x1020b418, rSignal=@0x76042e0, rProcessId={mSdlProcessName = 0x0, mSdlNodeId = 3, mSdlAppId = 100, mSdlProcessNumber = 157, mSdlProcessInstance = 1228}, _signalPriority=kDeletePriority) at /view/BLD-cm_su2_8_5_1-cct-ccm-d/vob/ccm/Common/Include/Sdl/SdlService.hpp:156 #7 0x089b9e2d in HuntListCdrc::broadcastMessage (this=0x1020b418, fTemporaryDeviceInfoList=@0x1020d184, fSignal=@0x76042e0) at /view/BLD-cm_su2_8_5_1-raw-d/vob/ccm_tpl/release/include/stlport/stl/_list.h:120 #8 0x089c94e7 in HuntListCdrc::SendCcNotifyReq (this=0x1020b418) at ProcessHuntListCdrc.cpp:9259 #9 0x089e2b77 in HuntListCdrc::distributeCall (this=0x1020b418, fTemporaryDeviceInfoList=@0x1020d184, fSendCcSetupReq=false) at ProcessHuntListCdrc.cpp:6908 #10 0x089e2d6e in HuntListCdrc::executeRouteAction (this=0x1020b418) at ProcessHuntListCdrc.cpp:6941 #11 0x089e30c3 in HuntListCdrc::select_facility_DmPidRes (this=0x1020b418, s=@0xecd43f0) at ProcessHuntListCdrc.cpp:1356 #12 0x089ed55e in HuntListCdrc::fireSignal (this=0x1020b418, sdlSignal=@0xecd43f0) at /view/BLD-cm_su2_8_5_1-cct-ccm-d/vob/ccm/Common/Include/Sdl/SdlProcessBase.hpp:183 #13 0x0a06f7cd in SdlProcessBase::inputSignal (this=0x1020b418, rSignal=0xecd43f0, traceType=SdlSystemLog::SignalRouterThread, highPriority=0, normalPriority=0, lowPriority=0, veryLowPriority=0, lazyPriority=0, dbUpdatePriority=0) at SdlProcessBase.cpp:371 #14 0x0a0753cc in SdlRouter::callProcess (this=0xc3e0b30, _sdlSignal=0xecd43f0, _deleteSignal=@0x7606fa7, _traceType=SdlSystemLog::SignalRouterThread, _hp=0, _np=0, _lp=0, _vlp=0, _lzp=0, _dbp=0) at SdlRouter.cpp:238
Conditions: LRO is enabled on vmware. vmware tools is out of date.
Workaround: upgrade vmware tools disable LRO - Attendant Console log fills entire /common partition on CUCM server, Fixed CSCtn02841 - Symptom:
The /common partition will become filled when running the Attendant Console for an extended period of time. This can be seen by executing the following command and looking for an ac_j.out.log file consuming the entire partition:
admin:show diskusage common sort
This command can take significantly long time,
and can also effect the system wide IOWAIT on your system.
Continue (y/n)?y
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda6 87665856 83214908 0 100% /common
83134096 /common/
79228256 /common/log
76277332 /common/log/taos-log-b
76142748 /common/log/taos-log-b/cm
74992048 /common/log/taos-log-b/cm/trace
74985276 /common/log/taos-log-b/cm/trace/ac
74984720 /common/log/taos-log-b/cm/trace/ac/logs
74984704 /common/log/taos-log-b/cm/trace/ac/logs/ac_j.out.log
Conditions: This has been seen in 7.1.3 as well as a 5.x call manager versions.
Workaround: Restarting the Attendant Console service and/or restarting the server allows the file to be cleared out and the partition space to be collected again.
Connect with Us