I am having a little trouble getting Unity to answer an incoming DID call. I am using Callmanager 3.3(3) and Unity 4.0(3) being integrated by TSP version 7.0(3b). Occasionally a call will get through seemingly when the first coulple of voicemail ports are being utilized. However, 98% of the time the caller hears a short ring and an immediate fast-busy. If I configure Unity not to answer and let it roll to the next available port, then it works every time. Anybody seen this before?
My first thought is to check your ports and see if all are connected to CallManager. Also in CCM, check to make sure all of your ports are Forwarded Busy/No Answer to the next available port. Do this for all except the last port. Do you have any ports hung? We experienced a problem with a port hanging, same versions of software as you and we were hitting defect CSCed54449 and CSCed41828. The
workaround was to upgrade to Unity 4.03 sr1 and then apply ES64. But I would check with TAC on your specific application event log errors. If you have a hung port, you would be seeing some messages that indicate a port has been busy for xxxxx time as well as a message indicated the port has been disconnected from CCM. When you say an incoming DID call, is the caller calling a subscriber on your system and then being routed to voicemail? Or is the caller reaching an Automated Attendant call handler or something like that?
Are you getting this error “Installer User Interface Mode Not Supported. The installer cannot run in this UI mode. To specify the interface mode, use the -i command-line option, followed by the UI mode identifier. The value UI mode identifiers...
The below trick might come handy when you have to add a new node to a cluster but you don't have or is unsure of the security password for the publisher. This procedure has been around for ages.
1) Login into the CLI of the Publisher.