- - Symptom:
Agent stuck in talking state even after disconnect. No call disconnect event from JTAPI.
Conditions:
This is an intermittent issue where JTAPI runs into an exception and doesnt deliver disconnect events (ConnDisconnectedEv, CallCtlConnDisconnectedEv, TermConnDisconnectedEv etc..) when the call is disconnected. From application perspective it shows up as a stuck call.
Workaround:
None
- - Symptom:
Cannot reset phones. Resetting a phone from the phone webpage does not
reset the phone.
show tech notify shows ccm has been removed from the list
Cannot login via Extension Mobility - login indicates success, but profile does
not get applied.
Conditions:
UNKNOWN - an intermittent issue.
Workaround:
Restart the callmanager service.
- - Symptom:
Tomcat has run out of Permgen memory. The majority of web services are still available, but some might fail to respond. Example, Extension Mobility logins may be refused.
Conditions:
Multiple manual restarts of large web services like CAR can lead to exhaustion of Java PermGen memory. Specifically activation/deactivation or start/stop of Cisco web services such as CAR through the Serviceability pages. Estimates for 7.1 releases is in the neighborhood of 40 restarts of CAR.
Workaround:
To recover:
- Restart Tomcat.
- Inclusion of fix for CSCsy70968 eliminates likelihood of occurence due to DRS backups.
Further Problem Description:
- -
Symptom:
CPU spike while activating and deactivating services in SA page
OR
Tomcat log shows "java.lang.OutOfMemoryError: PermGen space"
Conditions:
CPU spike while activating and deactivating services in SA page
OR
Java PermGen memory becomes low on repeated activation/deactivation or
start/stop of Cisco web services such as CAR.
Workaround (for the OutofMemory issue):
To recover:
- Restart Tomcat.
To avoid the issue:
- Disable the CAR web service
- Do not stop/start other web services available in the Serviceability GUI.
Additional Info:
Please see CSCta20132.
- - Symptom:
Cannot enable video capability or ciscocamera for 9971 and 9951 phones
Conditions:
Config item missing from phone config page
Workaround:
Install a device pack that has these changes.
- -
Symptom:
Dusting and Send Call to Mobile does not work on a NURD call with Local
Route Group involved.
Conditions:
Use of Local Route Group with NuRD and having the Log Mobile Number in CDR
for Rerouted RD Calls Serveice Parameter set to True
Workaround:
Do not use Local Route Group and/or set Log Mobile Number in CDR for
Rerouted RD Calls Serveice Parameter set to false
Further Problem Description:
- - Symptom:
Many CUCM processes are killed some causing things like Web access and
alerting to be out. This may also impact AMC/RTMT, DRS backups and the ability to collect CDR records.
The OOM Killer reports some stats when it kills processes. One of the stats seem to point to the depletion of lowmem memory (as shown below):
...
Apr 5 10:46:54 server1 kern 4 kernel: Normal free:3696kB min:3728kB low:7456kB high:11184kB active:204kB inactive:276kB present:901120kB pages_scanned:396 all_unreclaimable? yes
...
Apr 5 10:46:54 server1 kern 4 kernel: Normal: 0*4kB 0*8kB 1*16kB 1*32kB 1*64kB 0*128kB 0*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 3696kB
...
Conditions:
Memory leak eventually causes the system OS to start killing processes.
Workaround:
Disabling CSA (utils csa disable) prevents this problem.
After this problem occurs, rebooting the system will restore the system to operational state.
Further Problem Description:
A process with a memory leak starts to allocate too much lower memory. In order to protect the operating system kernel, the OS starts to kill processes using lower memory. This will cause various services to fail depending on which ones are killed by the OS.
- - Symptom:
LDAP authentication delayed by 10 seconds
Condition:
CUCM Appliance.
Workaround:
None
Defect opened to make following optimizations:
From the platform API logs, can see CertifiateManager.getCertificate() method being locked.
This method probably does not need a lock. Like the enablePort() method, it should probably use a lock duration of 0
Also from IMS perspective we can do an optimization. If LDAPS is not configured, don't initialize trust-store.
- - Symptom:
CTI does not send CtiLineInServiceEvent to application upon device registration. This results in failures with the application, ie. agents not able to login, etc.
Conditions:
A specific race condition exists where the device must register, then unregister immediately, which results in the failure condition in CTI. The event sequence is as follows in the CTI SDL traces:
SdlSig-I | CtiDeviceRegisterNotify
SdlSig-O | CtiDeviceOpenDeviceReq
SdlSig-O | CtiLineOpenLineReq
SdlSig-I | CtiDeviceUnRegisterNotify
Subsequent device registrations will result in CTI Manager not sending CtiLineOpenLineReq, thus preventing the line from going in service.
Workaround:
Unassociate/reassociate the device to the application user.
- - Symptoms:
The DB entries are not removed after removing the license file via cli command file delete license
Conditions:
This problem happens when there is only a license file uploaded in the server and user removes the license file
Workaround:
user will need to remove the corresponding DB entries in licenseinfo table. For CUP server license file. the following two SQLs need to be executed:
run sql delete from licenseinfo where tklicensefeature = '4'
run sql delete from licenseinfo where tklicensefeature = '5'
Note CUP will also document this issue and declare CUP doesn't support valid license removal through the CLI command. The only time that user needs to remove the license file is a publisher rehost is performed and the original license file becomes invalid. users will need to upload a new license file, use this cli command to remove the invalid license file, then restart license manager.
Further Problem Description:
- - Symptom:
File system goes to read only mode.
The following may be seen in the (RTMT-System Logs) or "messages" file on the
local server:
-------
kern 2 kernel: EXT3-fs error (device sda2): ext3_journal_start_sb: Detected
aborted journal
kern 2 kernel: Remounting filesystem read-only
-------
You could also see the following in the (RTMT-Application Logs) or
"CiscoSyslog" file:
-------
SyslogSeverityMatchFound events generated: SeverityMatch - Critical kernel:
EXT3-fs error (device sdb1) in start_transaction: Journal has aborted
or
SyslogSeverityMatchFound Detail: At Tue Sep 01 23:01:03 CDT 2009 on node
10.120.200.33, the following SyslogSeverityMatchFound events generated:
SeverityMatch - Critical kernel: EXT3-fs error (device sdb1) in
start_transaction: Journal has aborted
------------------------------
To determine whether the root (/) partition is still writable, enter the
following from CLI:
utils iothrottle enable
You should see the following message:
"I/O throttling has been enabled"
utils iothrottle disable
You should see the following message:
"I/O throttling has been disabled"
To determine whether the /common partition is still writable, enter the
following from CLI every 2 minutes:
file list activelog syslog/* detail
You should see the size of the file "CiscoSyslog" change, for e.g.
589,219 CiscoSyslog
and then approx. 2 minutes later:
589,550 CiscoSyslog
Conditions:
Following hardware models are susceptible to the problem when installed or
upgraded to CUCM or Unity Connection release 7.1.2.20000-2:
MCS 7835-I2 servers
MCS 7845-I2 servers
or
customer-provided IBM xSeries x3650
CUCM/UC release can be identified from the product banner displayed on system
console. Another way to find out CUCM/UC release is to run platform admin CLI
command "show version active".
Hardware model can be identified by running platform admin CLI command
"show hardware".
Workaround:
If experiencing above problem for specified CUCM/Unity Connection release and hardware
models, then apply the following workaround:
1. Boot the system using the recovery disk (version 7.1.2.10000-16 or
later)
2. From the recovery CD menu select option 'f' to run file system
check
3. When completed select option 'q' to quit recovery CD
4. eject the CD when prompted and reboot the system
Additional Information:
***If you think you are running into this defect, please collect the
following:
1) show hardware
2) active syslog/* files
3) "utils create report hardware" (DSA)
Any customer that have had the r/o problem on the /common partition and recovered via reboot and/or Recovery CD should consider doing an upgrade to a CUCM or UC version w/ the CSCta73022 fix, then doing a DRS backup, fresh install the same CUCM or UC version, and restore. Reason being is the /common partition is common to both the inactive and active (upgraded) UCM and as such, will still potentially have broken files and or directories. The fresh install would remove this possibility.
If the customer doesn't known which partitions were affected and no record exists, the above procedure should be followed verbatim.
See field notice 63270
http://www.cisco.com/en/US/ts/fn/632/fn63270.html
- - Symptom:
Update of a Large Number of Associated Devices
In original customer was an update of a partition name associated to 20,000 devices.
Conditions:
Large cluster - 20K + Phones
Workaround:
The cluster should auto recover. This causes and Alarm 47 which will set replication back up on its on. The Alarm is caused because of the update making Informix run out of memory.
- -
Symptom:
Inbound H.323 call to UCM 7.1.3 gets silence for PSTN caller for 10-15 secs and call drops.
Conditions:
Ver: 7.1.3.10000-11
UCM SDI traces may show:
10/01/2009 21:35:32.628 CCM|ProcessH225Message::decodeUuie ** ERROR rc=4
D0081S: End of input reached before message was fully decoded; check PDU #5 'H323-
UserInformation'
or:
In Failed UUIE:
10/01/2009 21:35:32.628 CCM|Ie - H225UserUserIe -- IEData= 7E 02 01 05 20 80 06 00 08 91....
Length is spanned over 2 bytes
02 01 in Hex [ 201 ] = 513 [ in decimal ]
Since second byte is "01" we , return from the retrieveUuie function.
Workaround:
If working version of UCM is still in inactive partition switch back to the previous version. this
appeared to work in version 6.1.4.1190-3 but appears broken in 7.1.3.10000-11.
At least one installation had this problem with IOS Versions before 12.4(24)T1 but not on or after that
version. If the H.323 integration is to an IOS gateway consider upgrading to this IOS version.
Alternatively - configure "signaling forward unconditional" under voice service voip section of the
config.
Further Problem Description:
- - Symptom:
after invoking Music on Hold server several times, unicast moh did not play music on hold. Music on hold may be invoked by hold, transfer, conference, park, or other features.
Conditions:
UCM 6.1(4) and unicast music on hold server invoked several times.
ANN could be affected by this behavior as well
Workaround:
Upgrade to a version with fix for this issue.
Alternate Workaround:
(a) Configure each MOH audio source ID for multicast
and (b) Configure each MOH server to multicast
and (c) All Media Resource Groups (if any are defined) must NOT have multicast enabled
This should result in MOH servers sending out multicast but also able to send out unicast MOH on same MOH resources.
This would not require making any network (router) changes to forward multicast MOH packets as long as Media Resource Groups (MRG) are not configured to enable multicast MOH.
One Drawback:
The MOH servers will be transmitting multicast streams for each MOH source and MOH codec so this may add some network traffic to the local network. These multicast streams will be continuous and running at all times. The MOH server(s) will be sending the MC stream(s) to the local router but as long as the router is NOT configured to forward the moh multicast packets the lan traffic will be minimal. By default, routers do not forward multicast moh packets.
No workaround known for ANN issues.
Additional NOTE:
This defect is fixed in 6.1.4.1102-1 but is NOT in 6.1.4.2000
It is included in 6.1.4.2113.
- - Symptom:
While inserting VG224 SCCP, we get the following message after the 10th port :
491 The specified name has invalid characters or is not formatted correctly for this device type.
Conditions:
CUCM 7.1.3
Issue not faced in CUCM 7.1.2 and below
Workaround:
Insert VG224 as MGCP instead of SCCP
Further Problem Description:
01. The first 10 ports insert fine
02. Issue from 11th port onwards
03. GW inserts fine when MGCP selected instead of SCCP
04. GW inserts fine on CUCM 7.1.2
05. Issue 100% recreatable in lab on a 7.1.3 box
This is what I see in the BPS logs :
2009-11-06 18:10:10,552 DEBUG [Thread-11] common.LogWrapper - GatewayDBManager::ExecuteInsert|Error code : 491
java.sql.SQLException: 491
at com.informix.jdbc.IfxSqli.a(IfxSqli.java:3171)
at com.informix.jdbc.IfxSqli.E(IfxSqli.java:3484)
at com.informix.jdbc.IfxSqli.dispatchMsg(IfxSqli.java:2328)
at com.informix.jdbc.IfxSqli.receiveMessage(IfxSqli.java:2244)
at com.informix.jdbc.IfxSqli.c(IfxSqli.java:1244)
at com.informix.jdbc.IfxSqli.executeExecute(IfxSqli.java:2170)
at com.informix.jdbc.IfxSqli.executeExecute(IfxSqli.java:2107)
at com.informix.jdbc.IfxResultSet.b(IfxResultSet.java:378)
at com.informix.jdbc.IfxStatement.a(IfxStatement.java:1299)
at com.informix.jdbc.IfxStatement.executeImpl(IfxStatement.java:1269)
at com.informix.jdbc.IfxStatement.c(IfxStatement.java:989)
at com.informix.jdbc.IfxStatement.execute(IfxStatement.java:875)
at com.cisco.ccm.bps.gateway.InsertGateway.ExecuteInsertList(Unknown Source)
at com.cisco.ccm.bps.gateway.InsertGateway.fnExecuteSql(Unknown Source)
at com.cisco.ccm.bps.gateway.InsertGateway.InsertRecords(Unknown Source)
at com.cisco.ccm.bps.gateway.InsertGateway.insert(Unknown Source)
at com.cisco.ccm.bps.service.TransactionController.selectTransaction(Unknown Source)
at com.cisco.ccm.bps.service.ScheduledJobHandler.run(Unknown Source)
Caused by: java.sql.SQLException
at com.informix.util.IfxErrMsg.getSQLException(IfxErrMsg.java:395)
at com.informix.jdbc.IfxSqli.E(IfxSqli.java:3489)
... 16 more
2009-11-06 18:10:10,564 DEBUG [Thread-11] common.LogWrapper - GatewayDBManager::ExecuteInsert|Exception : java.sql.SQLException: 491
2009-11-06 18:10:10,565 DEBUG [Thread-11] common.LogWrapper - DBManager::getDBErrorMessage|Query : SELECT name FROM typedberrors WHERE enum ='491'
Tweet This
Share on Facebook
Digg This
Save to delicious
Stumble it
RSS Feed
