We are hitting this bug as well and it is absolutely annoying to get this message 10-15 times or even more a day. At the moment, that is the main reason why our users didnt use Jabber at the iPhone. Does the low severity means that the error will not be fixed in the next few month?
Solved! Go to Solution.
I have this same issue with a couple of VIPs in the company who do not think of this issue as just "cosmetic".
Other than this issue, we could finally fix unreliable push notifications for iPhone with 11.5(SU4) - only to run into the next problem: delayed notifications on iPhone. When a call comes in, your Jabber for Windows and your phone might ring, you take the call, end the call and then get the same call 15-30 seconds later on your iPhone. I don't want to go off-topic here, hear me out, I think there is a connection between these issues.
All iPhones have a hard-coded power saver settings for WiFi. In our case, the user is in our corporate network that's working with a couple of very low thresholds and a pretty short lease-time.
That combined with the iPhone's energy saver settings might lead to the iPhone disconnecting from the IM&P and/or phone services for Jabber. Then, when it reconnects once the user wakes their iPhone up, it'll try to access messages and/or call history - I suppose.
I'm just right now running a field experiment for this, maybe you want to try this as well - I found this workaround:
(credits to monal.im)
I'm really hoping this might be a workaround for now.
Upgrade to SU5 did not resolve the problem for us. Users are confused about whether they need to take any action or if there is data at risk.
We have this "unread messages might be deleted from server due to timeout" notification issue on mobile devices (we use iPhones). Some users get 15+ of these notifications a day. Beyond annoying, users also think they are missing or losing content. We consider this a serious issue.
We upgraded Call Manager to SU5 but the issue persisted. Support had us then try disabling "stream management" (under XCP router service), this prior weekend, which seemed to stop the messages, but that caused new (more serious) problems where people would go offline and not "stay alive" in the mobile client.
Screenshot below. Please Cisco, address this.
I'm also having this issue (opened with TAC under SR 685785832), with some users getting the alert - what seems like constantly, and while the bug only references 11.5.1 - I think this issue is also happening in CUCM version 12.0.1.
I'm running a centralized IM&P cluster with CUCM ES 220.127.116.1106-1 (beyond what is generally available), and two telephony nodes running 11.5.1 SU5 (18.104.22.16800-18).
Can anyone on this thread (other than @timo.binz) confirm if their "unread message" issue was resolved by upgrading from a lower version of 11.5.1 to SU5?
I noticed that there have been 5 cases added to this bug in the past two weeks, and the bug doesn't actually list any fixed versions of software.
It would be great to get clarity on if this SU5 "fix" for this bug is real, and if so, can it be backported to the latest special for 12.0.1? If not, will it be available in IM&P 12.5?
That said, this alert ("Unread Messages alert") is documented in the APNS guide at the bottom of Table 8: Alarms for Push Notifications. This guide has open caveats for 11.5.1 SU3, so it doesn't appear to have been updated for 11.5.1 SU5 (or 12.0.1). The alarm level for the Unread Messages alert is documented as "ALERT_ALARM" and the guide references other alarms as "CRITICAL_ALARM".
The APNS guide indicates that the default level for push alarms can be changed from error (at which it seems that the "Unread Message alert" is set), so I tried the related commands on the bottom of page 20 to update the alarm level and the frequency, both of which were unsuccessful, which despite the error returned were run on a UCM publisher node
admin:utils managementAgent alarms pushfrequency 90
ERROR: This CLI command (pushfrequency) is only allowed on UCM Publisher node
Executed command unsuccessfully
admin:utils managementAgent alarms minpushlevel critical
ERROR: This CLI command (minpushlevel) is only allowed on UCM Publisher node
Executed command unsuccessfully
Has anyone been able to run these commands and had them resolve this issue? I tried them on CUCM 11.5.1 SU5 and CUCM 12.0.1, and for fun also tried them on the primary IM&P node (22.214.171.12400-3), and all were unsuccessful.
This whole issue, assuming it is not completely frivolous, appears to be related the following buffer - under the IM&P XCP Router > Stream Management > Stream Management Buffer Size (default 100). My current working theory (as I don't know how to view or relate the actual buffer contents for a particular session), as the buffer is quite large at 100, it is including status changes are clogging this buffer, while Jabber Mobile is in the background. If so, status changes should not be clogging this buffer while the app is in the background, as there is no reason that they need to be sent to Jabber Mobile when the app is in the background.
As I understand it, legitimate items for this buffer (at least for Jabber Mobile, while in the background) should only include (1) Notice of new chat messages, (2) chat invitations (based on documentation), (3) missed call notices, and (4) new voicemail notices.
Lastly, while this bug, as filed was documented as cosmetic, it clearly is not, based on the increasing number of customers reporting this issue, and the behavior of the bug, is that some customers are ultimately getting 10s of frivolous distractions from their day, from their productivity, from their peace of mind and from their trust in Cisco products.
I agree with Shawn. I opened a case to basically be told they don't care and its not a bug. Even with no incoming IMs or calls I will still get this error - quite annoying and generates lots of support calls. Hopefully they will fix this issue soon.
What learned this week that you don't even need to have any contacts and if you are logged into Jabber Mobile, you will still receive the "Unread messages might be deleted from the server to timeout. Please sign in Jabber to check unread messages."
Given this most recent info, there is no basis that Support/BU can deny that this issue is a defect.