Symptom: Real Time Reports feature does not work on the CUE GUI. We obtain a blank page
Conditions: Unity express 3.2.1 ; 3.2.2 on AIM module and UC520
Workaround: None
Further Problem Description: To repdroduce: On the GUI click on the Reports > Real Time Reports menu

Symptom: Reactive debugging in the CUE Editor does not work with UC500. The error message we get is "RMI OP can not accept calls made in RMI Protocol 1.1 for class com.cisco.wfframework.engine.rmi.RemoteWorkflowEngineImpl."
Conditions: Use the reactive debugging feature in UC500
Workaround: None
Further Problem Description:

Symptom: can't record VM while CUE 3.0(x) running several days with CCM
Conditions: under normal condition, the udp port will be locked in CUE
Workaround: reload the CUE module.

Symptom: Reports -> Real-Time Reports shows a blank white or gray page.
Conditions: It works fine with Sun JRE version 1.6.0_03 or below and does not work with Sun JRE 1.6.0_04 or above.
Workaround: - Install Sun JRE 1.6.0_03 or lower version. - Install CUE 7.0 ... (when it becomes available).

Symptom: Historical data is not getting recorded into the database, and not showing up in historical reports.
Conditions: Historical records do not get recorded into the database after using the following configuration: ccn reporting historical enable
Workaround: Reload the module after making the configuration change. Then historical data will start to be recorded after a reload.

Calls to the CUE with SRTP enabled will fail unless you use srtp negotiate cisco as CUE sends 200 ok with RTP. it should send 488 so that CME can fallback to RTP.
Workaround use srtp negotiate cisco

Upgraded the customer's CCME to 4.2(0) and Unity Express to 3.1.1. They are unable to record/change their greeting (either Standard or Alternate) through the VoiceView Express interface. They can access the interface and view messages okay. When they press the Record SoftKey it displays the screen that tells the it is recording the greeting, but doesn't do anything.
Workaround: Use TUI to record greeting.

Description: Voice mail notification shows calling number in the subject line for the external users while shows name for the internal users. This is an enhancement defect. Version Found: CUE version 2.3 Process to Replicate: Voice mail notification doesn't display the name of the PSTN users when the voicemail caller id is enabled, instead displays "Message from:" the PSTN number. When voice mail caller id is disabled this would display "unknown sender" .Voice mail notification would display the name information for the internal users. Customer requirement is that notification would display name like the internal users. Work Around: None

None Basic Description No e-mails notifications are received from Cisco Unity Express. Reload of CUE starts sending and receiving new mails however old messages get stuck in the queue.
Workaround One workaround is to disable message notification on a system wide basis and enable it again. If this does not work, take a backup of both data and config and restore it back right away. Reloading clears the queue as the queues do not get backed up.

Symptom: A redirect from a Cisco Unity Express Voicemail or AutoAttendant CTI Route Point may fail.
Conditions: The problem only affects Cisco Unity Express integrations with Cisco CallManager. A customer may have a gateway, phone, or trunk configured with a calling search space which includes the partition of the CTI Route Point but not the partition of the CTI Ports. Even though the calling search space assigned to the CTI Route point includes the parition of the CTI Ports, CallManager will block/deny the call by default because CallManager's default behavior for processing JTAPI redirects is to use the original calling party's calling search space rather than the redirecting party's calling search space. JTAPI client applications have the option to tell CallManager to use the calling seach space of the redirecting party. Cisco Unity Express needs to implent a new setting which allows an administrator to select weather CUE should use the original calling party's calling search space or the redirecting party's calling search space when redirecting calls from the AA or VM CTI Route Point to a CTI Port.
Workaround: Ensure that the original calling device has a calling search space which includes the partition of the CTI Route Points, CTI Ports, and any other directory number or pattern to which the CTI application may redirect a call.

--> Symptom: Calls to CUE fail intermittently with busy tone.
Conditions: It has been noticed in CUE 3.1.1 integrated with CUCM 6.0.1.
Workaround: Reload CUE.
Further Problem Description: This issue happens with QSIG path replacement. CUE is not handling this scenario properly and is unable to disconnect a call. Messages of the type: "Could not meet post conditions of disconnect()" are seen in the logs.

Symptom: Messages left on a Cisco Unity Express (CUE) voicemail system may be blank or contain erroneous audio.
Conditions: Audio issues have been seen on voicemails left on a CUE systems when more than one RTP stream is attempting to access the same CUE module and port. This has been noticed when CUE is configured to interwork with Cisco Unified Callmanager (CCM) servers.
Workaround: There should be only one RTP stream to a given destination UDP port on the CUE system. If it is found that is more than one RTP stream to the same CUE ip address and UDP port, determine the source of the secondary RTP stream and take necessary steps to disable that packet stream. To help identify a possible rogue RTP streams sent to the CUE module, NetFlow switching can be enabled on the Cisco IOS router that the cue module is installed in. On the Cisco IOS router which has the CUE module installed, configure ip route-cache flow on the GigE and the Service-Engine interface. Then show ip cache flow | include IP address of cue module. See example below where 172.16.243.223 is the IP address of the CUE module and 172.16.242.228 is a device sending an unsolicited RTP stream to the CUE module. In this example, we can see a UDP packet stream (UDP is IP protocol 0x11) and seeing a few ICMP unreachables being sent to that device (ICMP is IP protocol 0x1 and we can see the 0303 which is destination unreachable and port unreachable). esc-2800-1#sh ip cac flow | inc 243.223 Se1/0 172.16.243.223 Gi0/0 172.16.242.228 01 0000 0303 16 Gi0/0 172.16.242.228 Se1/0 172.16.243.223 11 4188 4210 530 SrcIf SrcIPaddress DstIf DstIPaddress Pr SrcP DstP Pkts

Symptom: A CUE that is oversubscribed may crash and reboot itself after a period of time. The period of time between crashes is dependent on the call volume being presented to CUE. Just prior to the crash the following is seen in the messages.log file: ERROR ccn LibMedia DBUG PROBLEM_FILL_BUFFER:Problem filling buffer: Failure reason for the associated error=for rtp input stream in DBIS.start(),Exception=java.lang.NullPointerException
Conditions: This was seen in CUE software 3.x.
Workaround: Limit the maximum number of connections on the CUE dial-peer. In order for this to be successful all calls to the CUE must go through the same VOIP dial-peer. There cannot be more than one dial-peer pointing to CUE. On the dial-peer pointing to CUE add: max-conn # Where # is the maximum number of calls your CUE supports. This can be found in the "show soft license" output on CUE as "Total usable system ports."