Can't cover to Voicemail when routing to a station in a vector

[jen1262]

I have a VDN with VDN overide on.
37373 pointed to vec 34 which is doing:
wait hearing silence
route to number 7373 w/ cov y if unconditionally
stop

7373 is a station that is bridged onto 2 other phones, if the line isn't answered it should cover to voicmeil.

This issue is that if you call the TFN associated with the VDN, you get our general VM greeting and not the VM box for 7373. If you call 7373 directly we get to the VM box without a problem.

I would love some help. Since I haven't had an opportunity to play around in Avaya recently I am a little rusty on this stuff.

 

[tweege]

we had this exact problem with our sip integrated modular messaging. anytime a call was not answered on the physical extension that was going to voicemail, the mm would not route the call properly. it would either get the amilbox of the extension the call originated on, or the opening greeting if the originating extension did not have a mailbox.

the mm was not pulling the extension from the proper spot in the data string. there is a psn(001606U) about this.

here is the excerpt on the fix:

To correct this, do the following:
Activate the necessary features in your Modular Messaging System by going to
C:\Avaya_Support\Registry_Keys on each MAS and double-click the file CalledPartyAlgorithm-New1.reg. Once done the
selection takes effect immediately; no processes need to be restarted. This will change the way MM reads the SIP History Information
records used to integrate the call.
Should you want/need to re-enable the original functionality double-click on the file CalledPartyAlgorithm-Orig.reg on
each MAS. As before, the selection takes effect immediately; no processes need to be restarted.

only problem is, a reboot IS required. we found this out after a couple weeks and a couple patches later.

Thanks, Tim

 

[jen1262]

Tim,

We made the suggested change and rebooted this morning and still getting the same error. :-(

Any other suggestions?

Jen

 

[bleebrant]

Are the outside calls getting to VDN 37373 via another VDN?
If so, on the coverage path that 7373 is using you could try to change the CVG Enabled for VDN Route-To Party to Y.