We are running 2.4.5(57). This message is being heard when the operator mailbox is checked through either the example administrator or through any account that is part of that distribution group. It gives the time of the message, and then plays the "this message is no longer available" routine.
I can't recreate the problem, because whenever I call from outside or anywhere else, the message I leave is retrievable as normal. We seem to get about 4 messages a day that gives us this message. I sifted through the event log and there are no event errors logged.
Hmmm... the only time that message should come up is if you entered your message stack over the phone and then the message or messages in question are moved from the inbox (i.e. via Outlook at the desktop). We've gotten a list of the messages in the inbox and are presenting them, when we run into one no longer available to us in the inbox, we play that prompt and move to the next one.
I'm not sure why you'd be seeing this unless someone is accessing that message box at about the same time as you're checking the messages over the phone.
I'll have the conversation folks look for other triggers for that message, but one of the things that would be helpful here is to access your inbox (or the Example Administrator's inbox I suppose) using Outlook when this happens and see if there is a message there at all and if there is, if there's something unusual about the attatchement (i.e. maybe it's very short or completely empty or something along those lines). That should at least give us some clues to work with.
Just as a follow up... the conversations guys looked into the code and came up with a couple of scenarios that might cause this message to kick up:
1. The message has been removed after you entered your stack (I mentioned this one in the last post). I'm kinda doubting that's the case here, though.
2. The mailbox in question is full. Exchange wont let us mark messages read/unread (or change it's state in any way) when it considers a person's inbox full. If we can't change it's state, we back out with that error message and move on. I can't think of any other reason why we'd be restricted from marking a message as read or unread other than the inbox being full.
3. The message stream on the WAV file is invalid for some reason. This is why I want to see if you can actually get a message that does this from the inbox for us. Normally, however, this will result in an error being logged to the application event log from the MIU.
Let me know if you can repro this for me and get us a WAV file from a message that's throwing this error.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
[toc:faq]CUCM Database Replication is an area in which Cisco customers
and partners have asked for more in-depth training in being able to
properly assess a replication problem and potentially resolve an issue
without involving TAC. This document discusse...