<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"> 
  <channel>
  <title>Unity Express Hot Issues from Cisco TAC</title>
  <link>http://www.cisco.com/en/US/customer/products/sw/voicesw/ps556/products_tech_note09186a0080937324.shtml</link>
  <description>Hot Issues from Cisco TAC.  Please click the link for complete details.</description>
  <language>en-us</language>

  <managingEditor>wsisk@cisco.com (Wes Sisk)</managingEditor>
  <webMaster>news-at-cisco-rss@cisco.com (Cisco Newsroom)</webMaster>
  <pubDate>Mon, 23 Nov 2009 11:40:17 EST</pubDate>
  <lastBuildDate>Mon, 23 Nov 2009 11:40:17 EST</lastBuildDate>
  <generator>PERL</generator>

  <docs>http://www.cisco.com/en/US/customer/products/sw/voicesw/ps556/products_tech_note09186a0080937324.shtml</docs>
  <ttl>10080</ttl>

<item>
<title>CUE messages stuck in the notification queue . , Fixed CSCsh34819</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsh34819</link>
<description>None
&lt;b&gt;Basic Description &lt;/b&gt;
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.
&lt;br&gt; 
&lt;b&gt;Workaround &lt;/b&gt;
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.


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsh34819</guid>
</item>
<item>
<title>Occasionally CUE in bad state after a restore or upgrade of CUE 3.1.x. , Fixed CSCtc77633</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtc77633</link>
<description>






&lt;B&gt;Symptom:In couple of customer cases, after upgrade or clean install with restore, CUE ended up in a non-operational state. The customers were upgrading from a CUE 3.1.x system.
&lt;/B&gt;






&lt;br&gt;
&lt;B&gt;Conditions: We observed that the customer backup files had inconsistency between the version indicated in the files and 
the schema in them. The version shows 1018 whereas the schema it contains is for version 1019. 
We don&#39;t know how they ended up in this state. Because of this inconsistency in the Database, any upgrade or 
a clean install of a newer version with restore of this backup could result in a non operation CUE.&lt;/B&gt;




&lt;br&gt;
&lt;B&gt;Workaround: Workaround is to fix the backup database manually by engineering and restore it on the customer&#39;s system.&lt;/B&gt;



&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;














</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCtc77633</guid>
</item>
<item>
<title>re-INVITE dropped when CME with rtp-nte and CUE rtp-nte , Fixed CSCsz73632</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsz73632</link>
<description>Problem Description:
On H323 slow start calls into CME, with SIP to CUE, calls may fail to connect, and will disconnect with timer expiry (value 102), due to CUE not responding to a SIP REINVITE.  This is a race-condition, so the issue being observed will be intermittent in nature.

Additional Information:
This issue is a result of CUE dropping the RE-Invite when it is sent to CUE by CME soon after the ACK is sent to CUE.

Resolution:
This issue is fixed on CUE 3.1.1.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsz73632</guid>
</item>
<item>
<title>Phone displays Error 500: Internal Servlet Error , Fixed CSCsy21716</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsy21716</link>
<description>






&lt;B&gt;Symptom:&lt;/B&gt;

The CUE can get into a state while using VoiceView Express to access voicemail where, after pressing 1 for the Inbox, the phone displays an Error 500 :

&#39;Location:/voiceview/WEB-INF/screens/phoneobjects/CiscoIPPhonelconFileMe
nu.jsp Internal Servlet Error: javax.servlet.ServletException org.apache.jasper.runtime.PageContextlmpl.handlePageException (Unknown Source)....

 The user is able to listen to voicemail through TUI, but VVE access to voicemail will not work.






&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

This was found while performing stress-type testing of the VVE interface on the phone. Steps used to produce this:
1. press the services button on the phone and log into VVE.
2. select 1 for Inbox
3. press the services button again and log into VVE
4. select 1 for Inbox
5. rapidly repeat above steps




&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

A reload of the CUE module will correct this condition.



&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;

None














</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsy21716</guid>
</item>
<item>
<title>Unable to check new msgs if a there is an NDR for a remote broadcast msg , Fixed CSCsk45716</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsk45716</link>
<description>Symptom:

If the caller calls in to CUE, the login is successful. But as soon as the caller presses 1 to check for new messages, the call gets disconnected.
&lt;br&gt;
Conditions:

VPIM has been configured between Unity and CUE. A CUE subscriber has been assigned broadcast rights. 

If the user sends a broadcast message to Unity and if the remote VM system rejects the broadcast message there is an NDR in the senders mailbox. failure reason: Mailbox does not exist.  From this point of time the user will not be able to check new message in the VM box.
&lt;br&gt;
Workaround:

Retrieve the mailbox from a IMAP connection and delete it.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsk45716</guid>
</item>
<item>
<title>CUE sends &quot;551 5.6.1 Media not supported&quot; for onramp fax , Fixed CSCsy29732</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsy29732</link>
<description>






&lt;B&gt;Symptom:&lt;/B&gt;
CUE will send &quot;551 5.6.1 Media not supported&quot; back to an IOS gateway when receiving a fax from a gateway that has the fix for CSCsu59847.

CSCsu59847 is first fixed in 12.4(20)T2, 12.4(22)T1, 12.4(24)T, and 12.4(11)XW10.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
This only happens when an IOS GW, running an IOS with the fix for CSCsu59847, tried to send an onramp (T.37) fax to a CUE user.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;
Load an IOS version that doesn&#39;t include CSCsu59847.

</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsy29732</guid>
</item>
<item>
<title>CUE support for multipart MIME , Fixed CSCta71757</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCta71757</link>
<description>                        --&gt;

&lt;B&gt;Symptom:&lt;/B&gt;
Calls to CUE fails and GTD info is seen inside the INVITE message that goes to the CUE
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;
Ip Phone(sccp) ------CME--sip-----&gt;CUE

Voice service Voip
signaling forward unconditional
&lt;br&gt;


&lt;B&gt;Workaround:&lt;/B&gt;
Disable &#39;signaling forward unconditional&#39; under global voice configs


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCta71757</guid>
</item>
<item>
<title>SIP unsolicited notify dtmf sometimes cause call to drop , Fixed CSCsy88264</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsy88264</link>
<description>






&lt;B&gt;Symptom:&lt;/B&gt;







Calls to CUE autoattendent or other CUE applications using DTMF are
terminated seemingly at random. Specifically, sometimes when CME
sends DTMF in an unsolicited SIP NOTIFY request, CUE sends an error
response with status code 500. CME reacts by terminating the call.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;





Unsolicited notifications (sip-notify) are used for carrying DTMF from
CME to CUE.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;




Use rtp-nte for carrying DTMF between CME and CUE instead of sip-notify.
&lt;br&gt;
&lt;B&gt;Further Problem Description:&lt;/B&gt;













With the sip-notify mechanism, CME sends two NOTIFY requests for each
DTMF digit generated. These are sent one immediately after the other and
although CUE usually receives them in the order they were sent, sometimes
they can be processed in the opposite order. This causes the SIP stack to
reject the first NOTIFY as being out of sequence.


</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsy88264</guid>
</item>
<item>
<title>GUI: Real-time reporting applet does not work on 1.6.0_07 , Fixed CSCsv22981</title>
<link>http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsv22981</link>
<description>&lt;B&gt;Symptom:&lt;/B&gt;

Reports -&gt; Real-Time Reports shows a blank white or gray page.
&lt;br&gt;
&lt;B&gt;Conditions:&lt;/B&gt;

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.
&lt;br&gt;
&lt;B&gt;Workaround:&lt;/B&gt;

- Install Sun JRE 1.6.0_03 or lower version.
- Install CUE 7.0 ... (when it becomes available).



</description>
<guid isPermaLink="true">http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&amp;bugId=CSCsv22981</guid>
</item>
   
</channel>
</rss>
