I have a Unity 4.04 SR1 server running VMO with off box exchange. The server is dual integrated with Callmanager as one integration and SMDI via PBXLink boxes connected to a Nortel Option 81 as the other integration.
THis setup has worked with minimal issues over the past 1.5 years, but the Nortel integration has recently started failing intermittently and I am having a difficult time figuring out why. The symptom is that the integration will work fine for 4-5 days, and then suddenly and apparently without warning all calls to Unity that originate from the Nortel integration are redirected to the opening greeting.
Once the system fails, the Application log indicates an MIU error # 528 for every incoming call. While the system is in a failed state, the Call Viewer shows all incoming calls with a trunk ID of -1, a dialed number of 0000 and a no information for calling number or forwarding station. Rebooting the servers clears the issue until the next failure occurs (4-6 days typically).
The start of the issue seems to correspond with the removal of 16 ports from the Nortel integration and the subsequent move of these ports to the Cisco integration.
As a part of the troubleshooting process we have rebooted the PBXLinks during failure and the status was not changed. We loaeded ES35 on the Unity server. We verified that the Option 81 is no longer configured to use the removed analog ports that are connected to the Unity Dialogic cards. We verified that the Nortel digital sets are not configured to reference the analog ports that have been removed.
If anyone has any ideas of what may be causing this issue or has suggestions for troubleshooting, your help would be very much appreciated.
Just an update to this issue. Since the first post, we have replaced the PBXLink boxes and added a registry key to increase the MutexSleepTimerMS to 1 second from 500 ms. Also, it has occurred to me that the other item that changed immediately preceding this issue was an upgrade of the Unity TSP to version 8.1(3) from 7.04b. I didn't consider this to be a part of the issue previously since I am only having issues with the Nortel integration, but I thought I would mention it just in case.
TAC is insisting the issue is related to bug id CSCef80398, but I'm not convinced since all the cases I have seen involve CallManager ports and problems following server reboots. My problem involves Nortel ports several days after a reboot. If anyone has had a similar issue on a Nortel integration, I would be interested to hear what the fix to your issue was.
Had the exact same issue with an Avaya/Call Manager Dual integration. We were on the exact same software loads with PBX Links and Dialogic cards. It is due to the Dialogic cards getting a voltage spike from the buss of the server. We upgraded our software and servers and went to the PIMG integration on the Avaya side. We are now on Unity 4.1.1 with the PIMG's and have not had a 528 error since. Just our experiences for what it is worth.
We never did open a TAC case on this one. It was only taking the PBX ports out of service, so it ruled out the Call Manager side. We were on older servers, so that was the start of our problem. The problem seemed to be more evident after the server was disturbed (ie: reboots or higher memory usage). We just new that from looking at the logs/traces, one port on the dialogic boards caused the issue and took the rest of the dialogic ports out of service. The new PIMG's are so much more stable, it is a good upgrade. Hope this helps!
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...