Unity doesn't answer blind transfer

[admin_2]

When Unity answers and you dial an extension number that is set up for blind transfer on SMDI, the call will not ring back to the voice mail box after the predetermined Call Forwarding Time. This is a problem that Scott Morgan has fixed for us in the past, but did not show us how. Can you help with how to fix this problem? He said it is because you restrict voice mail port to voice mail port calling because if you do not, pager notification is locking up all the voice mail ports. Thanks.<br><br>

[#2]

This behavior was introduced in 2.4.5 to prevent two voicemail ports from getting tied up talking to each other. Unfortunately this can cause problems with certain SMDI integrations (like Toshiba) that retain the voicemail port's extension number in the calling party field of SMDI. In order to correct the fault, you need to edit the registry. Use regedit or regedt32 to set
HKLM>Software>ActiveVoice>Arbiter>1.0>SystemConfiguration "AllowCallsFromVoiceMail" = 1

This change will take effect once the system is restarted.

Disclaimer: Editing the Windows System Registry is a task which should only be undertaken by an individual with an understanding of how the registry works. Changes made are immediate and a single mistake can be disasterous. ALWAYS BACK UP THE REGISTRY BEFORE MAKING CHANGES.

[#3]

You mentioned that "the call will not ring back to the voice mail box after the predetermined Call Forwarding Time". If that is the case, there is no Unity setting that can actually make the call forward back to Unity (it would be on the switch).

However, the case may be that the call is forwarding back to the Unity port, but Unity is not answering it. This should happen only on 2.4.5.5+ systems when Unity gets integration information from the switch that the calling party matches a Unity port (Unity "knows" its ports by what is entered on the SA Ports page). It's not going to happen in all SMDI implementations, only a few PBX's will cause this to happen. Toshiba and Fujitsu implement SMDI packets slightly different than Bellcore standard, and with Unity's "don't answer incoming calls from myself" logic, this can cause the "no-answer" condition.

If these following conditions are met: 1)the switch is forwarding the call to Unity, but Unity is not answering 2)the calling party in the forwarding information matches a Unity port number 3)The Unity system is a 2.4.5 system 4)the SA Ports page has Unity's extensions entered, and these extensions match the calling party in the integration information, then the following Registry setting might help out:

HKLM>Software>ActiveVoice>Arbiter>1.0>SystemConfiguration "AllowCallsFromVoiceMail"

Only set it to "1" if the conditions listed above match your specific scenario. If not, I would recommend contacting AV Support for more diagnosis.