Here's my situation: I have a Unity 22.214.171.124 server with Callmanager 3.0.9. The Unity server exists in a multiserver Exchange site with another server. Users whose boxes reside on the Unity server aren't exhibiting trouble, but the users who exist on the other server are not receiving voicemail messages from external callers until late in the evening. It doesn't matter when the messages are left. This is not the case with messages left from internal callers(users on our ip phone system). <br><br>It's not that the messages aren't being received, but that they aren't being delivered until after 7 pm in the evenings.<br><br>Another thing, the messages seem to be holding in the MTA queue on the Unity server. <br><br>What could be causing this. How is the routing of external calls different from internal calls?<br><br>Thanks,<br>Tom Parker<br><br>
The primary difference here is outside callers leave messages via the Unity Messaging System account on the local Unity server's Exchange box and the MTA in Exchange takes care of getting it to the home server of the subscriber in question.
when a subscriber leaves a message for another subscriber, the message originates in the home store of the sending subscriber (i.e. we stream the voice message directly into their home store) and it delivered from that location.
I suspect you have an MTA connectivity issue between our Exchange server and the rest of your site. Did you upgrade to SP4 on our box but not the other Exchange servers in the site by any chance? There are known issues with the MTA when you do this.
You can test this by opening a message profile on an account homed on the local Unity's exchange server and sending a message to one of the subscribers off our Exchange box and seeing what it does.
Thanks for your response. I checked the event viewer on the Unity server and there were a bunch of RPC communication errors with the other server. I checked the service packs and both servers are running sp4. I did some digging on Microsoft KB and found a entry for the 9318 event ID being reported and it attributed it to network communications. I did a little more digging and found a name resolution problem on my other server.
It's kind of odd though the the name resolution problem would clear up and and the come back. I will monitor it, but I think its cleared.
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...
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 discusses the bas...