Return After Silence/hangup From Vm

[Vincent Ball]

I am running VG Pro 5.2.5049.

 

I have found that once a script has gone to a Voicemail Box, that unless the person finishes their recording by pressing '0' to force a return, that the VM script just does a Hangup, and does not return to the calling script.

 

This behaviour occurs even if the calling script specifies a return path.

 

This is a significant limitation, as it means that the Hangup script of the calling script is not run either.

 

The consequence for us is that we can't afford to allow a branch to VM from our main script, as it is not guaranteed that the person leaving a VM will always finish by pressing '0'. Therefore our cleanup script may not run, which is critical.

 

Is there any way that the VM script can be forced to Return, regardless of how the recording is finished - 0, silence or hangup?

 

Logs are available of course if needed.

 

Thank you........... VB

[SupportTeam]

I have found that once a script has gone to a Voicemail Box, that unless the person finishes their recording by pressing '0' to force a return, that the VM script just does a Hangup, and does not return to the calling script.

Yes. If the call is ended while the voicemail message is being recorded then the system will just end right there (with the "On Hangup" script for the voicemail system being ran...)

 

The approach you should take is to modify the "OnHangup" script for the Voicemail system, adding to it the actions that your main scripts "On Hanugup" script is doing.

 

You will need the Enterprise version of VG to do this - as you can only modify the voicemail scripts in the Enterprise version of VG.

[Vincent Ball]

Is that really a desirable design?

 

It is a fairly expensive option to upgrade to Enterprise for the single purpose of changing the script to what seems would be a generally preferred flow.

 

Surely the standard vgp scripts would be significantly improved by being changed to take the Return path.

 

It seems to me to be unlikely that the current implementation is desirable for anyone wanting to use VM. I can't imagine why a script designer want not want to take the Return path?

 

However, if that current design has to remain then we will just have to forego using VM, which is a shame as our users were keen when it was made it available.

 

Thanks for your consideration........... VB

 

(Or I just thought I could move all the Hangup Script logic to the end of the main script, and just allow users to leave a VM as the very last step of the main script. Then it doesn't matter if they Return from VM or not. Not elegant or as easily maintained but probably workable. And of course I am limited to only doing a VM option as a final step)

[SupportTeam]

The 'return-to' module is jumped to if the subscript chooses to return to the calling script... if the subscript does not choose to return to the calling script then that is not done... this approach makes it easier to predict what the system will be doing at hangup. ie: it will just finish the current module and then run the "On Hangup" associated with the current script. Voicemail system is just a series of scripts, so same rules apply.

Or I just thought I could move all the Hangup Script logic to the end of the main script, and just allow users to leave a VM as the very last step of the main script. Then it doesn't matter if they Return from VM or not. Not elegant or as easily maintained but probably workable. And of course I am limited to only doing a VM option as a final step

Yes, if you can do the 'cleanup/end-of-call' tasks before branching to VM then that would be a good solution.

[Vincent Ball]

That wasn't quite my point.

 

It seems very limiting that if the VM system/scripts are moved to, that it has been coded that in the two specific cases - silence and hangup - that the return path is not taken. In contrast to '0', where the return path is honoured in the script.

 

The difference is in the VM script coding, not the capabilities of the VG scripts.

 

I was trying to make the observation that the coding is unhelpful, as it is unpredictable (depending on what the user does) whether the return will happen or not, and therefore it is difficult to use the VM system where you need the calling script to regain control.

 

Just trying to be helpful here, and make a case for a generally valuable enhancement to VM for everyone, and especially Pro users.

 

VB

[SupportTeam]

It would be possible to modify the VM scripts to do a "return" upon silence, but it would not be possible to have it somehow jump back to the calling script on "hangup".

 

At hangup the current module is ended and just the "On Hangup" for the current script is ran... it would not always make sense to jump back to some module in previous script - the call has ended so the module/script we'd be returning to can't usually do anything anyway.

And running the "OnHangup" tasks for all the scripts in the call stack is not done as it would be causing too much confusion for users (this was a design choice).

 

This looks like boiling down to the fact that to get the system to do what you' like will be harder (but probably achievable) when using the "Pro" version of the software then if you were using the Enterprise version...

 

Enterprise has more features which allows easier creation of the more advanced systems.

[Vincent Ball]

the call has ended so the module/script we'd be returning to can't usually do anything anyway.

 

Except have the chance to run the hangup/cleanup script at least!

 

OK, I give in.

 

I think I will just give up on VM anywhere in a script, except at the very beginning before any real logic is handled, where again I can live with an unpredictable return and no cleanup.

 

I can't afford the time to rework my existing cleanup script back into the main script - it seems ultimately counter -productive anyway.

 

Thanks anyway........ VB

[SupportTeam]

Except have the chance to run the hangup/cleanup script at least!

You're asking for system to run the calling script's "On Hangup" task. The comments made in previous post would still apply here:

At hangup the current module is ended and just the "On Hangup" for the current script is ran...

...running the "OnHangup" tasks for all the scripts in the call stack is not done as it would be causing too much confusion for users (this was a design choice).

The solution may be to run the "On Hangup" script (or a very similar copy of it) before jumping to Voicemail...

 

Regardless of whether the Pro or Enterprise license is used changes would need to be made to the scripts themselves or the "On Hangup" script. With the Enterprise you would just have more choices of how to approach the design.

 

Sounds like you'd rather not make any changes at all and have VG change the way it treats the whole "On Hangup" situation. (which can be made, but would be a chargeable modification...)

[Vincent Ball]

You're asking for system to run the calling script's "On Hangup" task.

 

Not really, just to Return from VM.

 

The solution may be to run the "On Hangup" script (or a very similar copy of it) before jumping to Voicemail...

 

I don't think I can, as Pro doesn't provide subscripts. (I can see the inevitable coming up here.......)

 

 

I really don't mind making changes at all, goodness knows I have been beavering away at adding new features to our scripts ever since starting with VG. That's how I discovered the VG design - when a user didn't use "0" at the end of recording a message, and therefore the return didn't happen, and therefore the database update didn't get done, and then all xxxx broke out........

 

I guess also I was thinking of the Pro environment, where there isn't a stack of script calls, and therefore it seems straightforward to do a return to the calling script, as there can only ever be a single return path.

 

 

OK........ the inevitable looms, I need to make a case for an upgrade to Enterprise, and get on with some more changes...........

 

Thanks again.........VB