Need some assistance troubleshooting a Unity 5.0 Voice Mail to Nortel Option 11 (Succession4 software) with a Cisco 2821 Gateway with IOS 12.3(14)T4 and QSIG on the T1 interfaces. All is working now but everu time a voice mail is left on the Unity for a user on the Nortel side, the MWI on/off signal generates a PRI#265 error on the Nortel system. There are over 1000 of these error messages per hour. The errors don't SEEM to cause any detriment on either system other than a pain in the ... for the customer's help desk. Has anyone else run into this situation and how did you resolve the issue. Will be scheduling time on the customer router to perform some "isdn q931 debug" to try to identify the code that the Nortel is unable to identify correctly. Am searching on my Nortel side to resolve issue as well but wanted to also see what the Cisco side had to say. Customer implemented via IP only and QSIG with no external serial interfaces for the MWI control. Any suggestions?
Hello I'm about to setup the same thing where we have Unity -- CM -- 3800qSIG -- Nortel - Phone. Just with the Nortel being Option 81c with Succession 4.0. Did you get Voicemail interop working with the Nortel sets including MWI. If so can you share with me how you did this from a configuration view. Any special commands on CallManager, the Gateway or the PBX??
Still looking into this problem. This seems to be the scenario: Cisco Unity with QSIG IP trunk to Nortel Opt81c PBX. Nortel PBX's (Opt81s and Opt11s) networked via Nortel communications. Status signals across the QSIG trunk to DNs local to the Opt81 - all works fine. No PRI errors of any kind. Status signals across the QSIG trunk to DNs remote to the attached Opt81 - errors. Two errors in fact - PRI#265 and PRI#247. From the Nortel Engineering standpoint, the expalnation is as follows: Meridian Voice Mail (voicemail system prior to the Unity) knew when a DN was local or remote to the attached PBX. Thus messages to the PBX had a system code that indicated a control message for a local DN or remote DN and the PBX acted on those system codes. The Cisco Unity sends ALL messages to the attached PBX as if DNs are local. The PBX searches for the phone but does not find it as locally attached and sends out the RPI#265 error, it does however find the extension thru its call plan as a remote station and sends it to other remote PBX - and that transaction generates the second PRI error.
My two options, as I see them so far, are:1. create a QSIG IP trunk between Unity and all seven Nortel PBXs (all but one have been upgraded to support QSIG);2. get the Cisco Unity to mimick the Meridian in indicating a local phone extension versus remote phone extension to the attached PBX. Question: Can the Cisco UNITY perform such a function?
Do you know what exactly Unity would need to do in order to indicate remote extensions? If it is something like add a dtmf prefix, then this may be possible.
Also, you might check if the behavior is different for MWI requests performed by MCK/MIC feature keys on 2616 stations. If you can light remote lamps easily using a single local 2616, then you might consider adding a PIMG gateway to your Unity. You could still use the QSIG trunk for call traffic and simply have a few PIMG ports dedicated for MWI. Not the cleanest solution but certainly better than your option of putting QSIG trunks to each of the seven remote nodes.
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...