Route calls with VM through DID ?

[janni78]

Hi, is there a way to route calls in VM Pro using DID.

For example send all incoming call to VM:Route and let it send out calls to different group and give different menu options depending on what number you have dialed.

 

[disturbedone]

The VM:AutoAttendant option in the Incoming Call Route only works to Modules. If you want it to go to a Start Point, do this ...

Create a System Short Code
S/C *900 (for example)
T/N #AutoAttendant (no speech marks needed)
Feat VoiceMailNode

Point the Incoming Call Router to *900

I prefer to do it this way because it allows you to test internally as well as externally, whereas using the VM:AutoAttendant only allows you to test it if you have external lines connected.

 

[aarenot]

disturbed one
this works great but how do you deal with a call when vm ports are busy or unresponsive for whatever reason.

seems if vm goes down, then no calls to any did routed this way.

i might suggest routing the call to a hunt group first

then to vm, with another destination if that does not work programmed. a user in the hunt group can route calls to vm as well.

i use both, but a vm down situation requires some programming in the ipo to ensure calls do not go ring no amswer when vm is down.





You do not always get what you pay for, but you never get what you do not pay for.

 

[legendinmylunchtime]

Use fallback dest in ICR in case vm craps itself

 

[disturbedone]

That's it....use the Fallback Destination, that's the way to do it. It will send a call to this destination if the VM is "unavailable" ie not working, turned off etc. If the ports are busy though, they'll get busy tone. If you get this a lot, you need to get more ports.

 

[intrigrant]

If VM Pro is unlicensed then the Fallback destination will not work. VM pro will take the call and will perform actions but no speech unfortunally, bit of a problem if you use a AA.

 

[aarenot]

i have tried a few different methods myself, good to hear others experiences with what worked for them.
have used the fall backs, but did not neccessarily know all the scenario reactions mentioned.

thanks much

You do not always get what you pay for, but you never get what you do not pay for.

 

[janni78]

The VM:AutoAttendant option in the Incoming Call Route only works to Modules. If you want it to go to a Start Point, do this ...

Create a System Short Code
S/C *900 (for example)
T/N #AutoAttendant (no speech marks needed)
Feat VoiceMailNode

Point the Incoming Call Router to *900

I prefer to do it this way because it allows you to test internally as well as externally, whereas using the VM:AutoAttendant only allows you to test it if you have external lines connected.

First of all you can test a module internally by making a shortcode like this *900/"AutoAttendant"/VoicemailCollect

Second, I don't think you got what I wanted to do, I don't what to using different "Shortcodes" in Voicemail Pro, I want to use the same module for different incoming number but route them differently in this module depending what number they have dialed in on.

 

[disturbedone]

Not as far as I know there isn't an easy way of doing it. There are ways to do it but it still requires additional work.

You could create a module for each number, direct the Incoming Call Route to the required one. Then put a Goto action to the main call flow where you have most of the AA to set up. Then use a Module Return action to send it back to the module that it originally came in on and specify where they go to then. This way you only have to set up the big call flow once instead of numerous times but you still have to create a basic call flow for each DDI you have.