Voicemail Code in VM Pro 2

[kevykevg]

I am having an issue. I am attempting to setup a dynamic call flow which needs to be password protected and I want to use the individuals voicemail code to do this. Is there any way to pull in the voicemail code into a call flow and then compare it to a user entered value.

I have tried the CFG:Get $CP0(ext variable)voicemail_code $CP1(return value variable) in a free format generic action and then compared the $CP1 to the $KEY variable in a test variable action that I have them enter. I always get a fail result.

Any help would be greatly appreciated.

 

[tlpeter]

Try this in the pin field:

Pin
Each action can be protected by a PIN number. The PIN number can be the voicemail code of the presumed user.
To do this enter a $ symbol. For example, entering $ would force the caller to dial their voicemail code, entering
104$ would force the caller to dial 104 followed by their voicemail code.



ACS - Implement IP Office
ACA - Implement IP Telephony -- ACA - Design IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[kevykevg]

I have tried that but it does not work as it does not know what extension is dialing in. I may have not noted this before but this flow is for outside of the office so no extension is defined.

 

[tlpeter]

Try using some of this:

https://tlpeter.homeserver.com/IPOffice/Change_Voicemail_Code.zip

ACS - Implement IP Office
ACA - Implement IP Telephony -- ACA - Design IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[kevykevg]

Thanks. I have seen that flow before which was how I came up with the GET command that I listed above. My guess is I need some way of pulling the existing voicemail code from the configuration and then assign it to a variable that I can then test against.

 

[tlpeter]

You could try using $KEY in the pin field




ACS - Implement IP Office
ACA - Implement IP Telephony -- ACA - Design IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[kevykevg]

I have tried that but you can only put $ or a number in that field. I tired iCare to see if they had any idea and stumpped them also.

 

[TaureanDragon]

What version of VmPro do you have? Some versions of VmPro did not work with a valid variable name in the name of a module, it had a tendancy to incorrectly expand the contents (eg: $CPO).
Assuming "voicemail_code" is a valid data element I have a module that may help (not at work til next week so can't test) if you post to taureandragon1 at hotmail dot com i'll email it.

 

[tlpeter]

TD, the voicemail_code does work.
I made that module and tested it.
I have made it in 4.2

I am not sure if you can do a "get" for the voicemail code.



ACS - Implement IP Office
ACA - Implement IP Telephony -- ACA - Design IP Telephony
ACA - Voice Services Management
______________
Women and cats can do as they please and men and dogs should relax and get used to the idea!

 

[TaureanDragon]

If the Get was to work it would follow the format:
CFG:GET "$CP0" Voicemail_Code
and the result would get passed back in the $SAV variable.

 

[kevykevg]

I have tried the GET command as listed above assuming that it assigns it to the $SAV variable but when I do a test variable comparing the $SAV to the actual code I get a no match response.

We have 5.0.23 VM Pro version.

 

[TaureanDragon]

After the GET command copy the contents to a CP variable and test that using test variable. Although the $SAV is available to test against I have always copied the result to a CP variable before testing. So although it is possible the GET on the voicemail_code does not work, it could also be possible the test using the $SAV does not work.

 

[kevykevg]

I have attempted to assign the $SAV variable to a $CPx variable to test but I still have the same result.

 

[TaureanDragon]

Have tested the same, and the GET on 'voicemail_code' always returns '****'. I guess if the data is not being passed back, there should be an ability to pass a value and carry out a TEST against the voicemail_code (or any other parameter for that matter).

 

[kevykevg]

So it would seem that it would be pulling in the asterisks for the voicemail code instead of the actual number. I know we can push a value into the configuration but now I am beginning to think that we can only look at information as it would appear if we did an export of the configuration to a text file.

 

[TaureanDragon]

If you are using the SET function to set the Passcode, you could in theory, accepting this method will have Security implications, also write the passcode to
1) a Mailbox user variable
2) a database (if licensed to use databases)
3) a text file (if licensed for VB Scripting),

Then instead of doing a get from the mailbox fetch from this alternate source. However, if the passcode is changed by any other interface, eg the TUI, Visual Voice, Phone Manager... then this method would not work.

Best approach would be if Avaya supported a TEST capability, may be worth making a request.

 

[amriddle01]

Would a different approach be accepable?
You could have users log into their mailbox and in doing so would be entering their code and so it is secure, then depending what mode VM Pro is running you could then route them to the callflow you have created using one of the following means:

· IP Office mode
Users who press 0 while they are logged into their mailbox will be routed to the Next result of a get mail action in VM Pro, link this to the callflow

· Intuity mode
Users who press *0 whilst in their mailbox will be routed to their Voicemail Reception number if set. The Next result is not used. So set the voicemail reception number to route to the callflow.

Just a thought

ACS - IP Office Implement

"What the Crocodile Hat....was that?

 

[kevykevg]

Yes, that would be an easier way, but where would the fun be in that.

The whole point is to try and make this a dynamic callflow that we could then be password protected with unique passcodes. Avaya, just needs as TaureanDragon stated above, needs provide a TEST capability. As I am sure they are not going to let us pull someone's password as this would be a security risk.

 

[amriddle01]

I didn't realise you were doing this for sh*ts and giggles, I thought you just wanted a solution, I will come up with something more comical next time

ACS - IP Office Implement

"What the Crocodile Hat....was that?

 

[kevykevg]

Well it is not just for play as I and trying to do it for my company then once it works use it for our customers in the future. There is no "need a solution yesterday" person bark for this though just had burned through all the ideas I had to accomplish this and wanted to see if anyone else out there had some thoughts.