We are running a pilot of Cisco's IP telephony project, with Unity as our voice mail platform. The install was done by a consultant, but I'm the man ultimately responsible for the system in our organization.<br><br>I got back from lunch today and voice mail was unavailable - dialing the pilot number gave a fast busy. I got on the Unity console and looked at the status URL, and found that the Unity service was stopped.<br><br>Starting it brought everything back just fine.<br><br>Then, just a few minutes ago it happenned again. This time, however, the status page showed the Unity service was up, even though we were getting fast busy signals when calling the numbers.<br><br>The only change I made today was to unplug and plug back in a fiber link between two of our three Catalyst switches (a 4006, a 5500, and a 6509). They are all wired together in a triangle via gigabit fiber. When I unplugged the link the first time, the Unity perhaps lost connectivity for at most 20-30 second before the spanning tree algorithm did its thing and all was back up.<br><br>And it was plugging that link back in that seemed to kill it the second time. Again, there should have been no loss of connectivity there (maybe a few seconds at the most).<br><br>I see in our NT Application log for the Unity service the following Warning message at about the times we experienced the problems:<br><br>AvCiscoTsp device 1: Disconnected from CallManager 10.64.16.41<br>(also for devices 2, 3, and 4 - we have a 4-port license)<br><br>and then within a second in the log:<br><br>AvCiscoTsp device 1: Reconnected to CallManager 10.64.16.41<br><br>So it seems like it got reconnected just fine. I don't know why it would be giving a busy when I call. As I said, the second time this happenned the Unity service still appearred to be running fine. Via the status URL, I stopped and started it and everything came back.<br><br>I believe our consultant said we were using TSP version 28, which I guess is not considered the most stable production version (24 is?). We upgraded to that for some other problem, which didn't get fixed anyway, so there likely is not a problem to downgrade.<br><br>It looks like we're using Unity 2.4 Build 220.127.116.11<br><br>If there is anything else I can describe or provide that would be helpful in diagnosis, please let me know.<br><br>I am going to probably try and reproduce the problem to see if it is consistent. We were about to start rolling into production with this IP phone system; I suppose it is better that this cropped up now rather than next week.<br><br>thanks!<br><br>johnS<br><br>
FYI, I just got a chance to do a little more debugging on the issue, and it has nothing to do with spanning tree or anything funky like that - that was what just precipitated it.
I reproduced the problem by simply unplugging the ethernet cable on the Unity server for a few seconds, and plugging it back in. The same error messages were generated (loss of contact with the CM, followed by an apparent reconnection) and the same symptoms were evident (fast busy when calling voice mail, even though the service was up and the CM connection was re-established).
We're seeing if we can run the problem down here... it would be excellent, however, if you could report the problem to TAC so we can get your contact info and all that good stuff if we can't get the same things to happen on our lab systems...
I have opened a case, B216482, tech is Michael Ingram - he said he would get in contact with you, Jeff.
He tried to reproduce the problem (it apparently was something he knew about and expected from older releases), and was unable to with Unity 2.4.6 and CM 3.0.8.
It also sounds like this is the minimum version level we will need to get support from TAC. I think it probably would be wise to get up to this before we roll from pilot into production, no? Any other advice on how to proceed?
One of the TSP folks here mentioned this as a possible reason for this error as well:
================ It sounds like they have a single CallManager without a failover. If that is the case, they should probably uncheck the "Automatically reconnect to the primary CCM on failover" checkbox in the AvCiscoTsp configuration applet. Having this checked should work, but it might be causing the problem they are seeing. Of course they should also grab the CCM logs when the problem occurs.
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...