Direct Voice Mail via Networked Legends

[BobbR]

This seems my week for problems.
Two Legends, R7, networked via PRI. Manual says I can send Direct Voice Mail to extension on other system. Code 56 procedure merely rings the extension rather than its Voice Mail. DVM works fine intra-system, but now have requirement for inter-system DVM. Where to look?

 

[papabear762]

It should work, if your non-local udp tables are set correctly.

 

[BobbR]

What am I missing on setup of NL-UDP? The associated pattern for the extension range just routes to Pool 890 (Master Legend) with 3 digits. Calls are being routed correctly between systems. What additional coding is required to route DVM to Audix once the Master Legend receives a call? Since a DVM transfer rings the extension, I am obviously missing something.

 

[TouchToneTommy]

Hmmm....

Looking at the Network Reference, regarding Direct Voice Mail:

"Direct Voice Mail can be used for local extensions only and cannot be used for non-local extensions. The person calling and the person being called must be on the same system. In Release 6.1 and later systems if a local extension is covered by centralized VMS/AA at a remote system, Direct Voice Mail can be used to place or transfer a call directly to a local extension's voice mailbox on the centralized VMS/AA without ringing the telephone."

So, it seems to be saying that DVM can be used on either system to go to an extension local to itself, but for an extension on the other side, it's going to ring the station.

 

[BobbR]

TTT,

Your verbatim quote from the manual, on reading for third time, does say it will not work between systems, darn it.
My initial interpretation had me wondering how the remote/slave system was commanding master system to route to voicemail since a NLUDP extension cannot be in Gp Cover 30, or whatever, to provide routing.
The transferred, unanswered call will end up in voicemail if R6.1 or later, but you cannot transfer it direct without ringing the extension.
Wish there were an automated workaround (for all remote extensions).

 

[TouchToneTommy]

If you only have a handful of extensions that you need DVM for at the "other side", set up an adjunct number that covers to voicemail, and make Auto Attendant 2, 3, or 4 answer it. Make selector codes do MAILBOX transfers to the extensions. Transfer the caller to the adjunct, wait for the AA to answer, dial the appropriate selector code, and then hangup.

 

[BobbR]

Thanks for the neat tip, will give it a try in a few days and test on my extension, since I'm one of the handful that wants this.
I can envision a call bouncing around, routing over six T1 channels before hitting my VM (I'm on a slave system) so hopefully will not be two extensions doing this simultaneously.

 

[SYQUEST]

Since your systems are networked with a PRI configuration you should not have any "channel stacking" problems. Via the DCH messages both systems know what calls are where, very dynamic.

Hope this helps!

....JIM....

 

[TouchToneTommy]

Actually, I've got one site where a call comes into site A with the VM/AA, transfers to site B, covers to AA-2 back at site A, and each time they transfer back to site B and cover back to A, another channel gets used. 6 hops and you can't hear, and DTMF is no longer loud enough to be picked up by the VM.

 

[SYQUEST]

TTT are the sites in your example using PRI for the point-to-point?

If this is the case I will have to reread the Network Reference document description of using PRI to link Legends and Magixs...


....JIM....

 

[TouchToneTommy]

Yes, point to point T1 PRI. Think about the senario. Call comes into System A, which hosts the voice mail/auto attendant. Call transfers from the AA to an extension at Site B, using a channel. It is unanswered, so Site B's Magix covers it to voice mail, and uses another T1 channel to send the call back across to the voice mail. The caller 0's out or *8's out to a non-local extension, and the VM sends it back over to Site B on ANOTHER channel, ad infinitum.....

 

[kristiandg]

It is supposed to tear down wasted BCHs if the call is being ping-ponged. There's a unique call identifier flagged on the call so if the PBXs see its coming in and going out repeatedly, they are supposed to negotiate to clear the wasted channels. That is odd you don't have that working. Hmmm.

In terms of VM, I thought the key to this was to create a local hunt group on the non-vm equipped switch. That hunt group overflows to the vm-equipped switch's VM hunt group. I thought thats how they made it all work w/ direct to VM and all of that jazz.

Kris G.