Issues with Voicemail Pro Languages (Select System Prompt Language Module) 7

[dsm600rr]

Hello all,

I have a client that was upgraded to R11 and is running VM Pro on an Application Server.

They have an Option 1 for English and an Option two for Spanish.

When option two is selected for Spanish the call just hangs. Nothing happens (This worked previously before the upgrade and virtualization of VM Pro on the Application Server)

When I change Options 2 (Spanish) to English, It works.

Voicemail Pro Indicates "Spanish" Language as (YES - Installed on server).

I have tried other languages that indicate (YES - Installed on server) and none seem to work outside of English.

Thoughts?

 

[dsm600rr]

I Created a new "Spanish - Select System Prompt Language" Module and re-tested, still not working.

 

[sizbut]

Without being near a system myself at the moment to check, I would:

a) using the Voicemail Pro prompt editor, browse to where the default prompts sets are and see if the non-English folders contain prompt files. Even play a few. (separate the "are the prompts available" issue from the "does the Speak Language" action work.

b) set a uses local to Spanish and see if they get Spanish prompts after *17.

c) Run a trace and see what the path is for prompt requests before and after pressing 2.

Stuck in a never ending cycle of file copying.

 

[dsm600rr]

Using the Application Server File Manager is PITA. All I can see for Audio Files is "vmpro" > Greetings/Names.

Im guessing thats where the issue is. Its looking in: $LOC\Custom\base120.wav

 

[intrigrant]

Set a users locale to spanish and dial *17, if spanish is installed it will play the spanish systemrompt.
If it does not play spanish then the language is not installed.
If it does play the spanish prompt you do something wrong.

 

[sizbut]

Using the Voicemail Pro client, you can browser the prompts, no need to go near File Manager.

But yes, that path looks wrong. If they are recording their own prompts then it really should be more like Custom\$LOC\base120.wav.

So I assume the issue is not with the standard prompts but prompts they have recorded themselves.

[Personally I keep away from the File Manager function in Web Manager - whoever designed it had no knowledge of how Voicemail Pro works. Yes that your stuck with recording prompts using the Voicemail Pro client]

Stuck in a never ending cycle of file copying.

 

[dsm600rr]

intrigrant: I made a test user and set the locale to Spanish. Called a DID that I sent to *17 and entered in that test users mailbox. Everything still played in English.

So it appears as though it thinks Spanish is installed, however it is not? I am not sure if my process of dialing in is any different than hitting *17 from a physical phone on-site (I am not on-site) - however it played English as normal.

Is there a way to load the Spanish Language?

 

[dsm600rr]

sizbut: I did not change the file location from what it was: $LOC\Custom\base120.wav

Because this worked before the VM Pro was moved from a Windows Machine to a VM on Linux Application Server.

 

[intrigrant]

Use the phone to dial *17 and not a ICR to *17 as it will use the systems locale.
Just do as asked.

 

[sizbut]

Never said you did!

We really are down to file locations and file permissions. On earlier versions of the Linux servers, everything ran with root permissions, so everything worked - but that was a huge security no no.

If the base directory for Wavs is set to /opt/vmpro/Wavs, you're saying it can play /opt/vmpro/Wavs/en/Custom/base120.wav but not /opt/vmpro/Wavs/es/Custom/base120.wav. As said, use the Prompt Editor in the Voicemail Pro client to browse to that location to check it exists and that the editor can play it. That checks both the location and file permissions (see below).

Voicemail now runs with (if I recall correctly) with the permission of a user called VMPro and I would suspect that it might not have the right permissions to play the migrated prompts (how did they migrate?). The fact that it can't play the default *17 Spanish prompts either is odd though.

Stuck in a never ending cycle of file copying.

 

[intrigrant]

In previous releases the folder ./custom and underlaying folders had full access rights for the VMPro app but it has changes as now the VMPro app access files through the vmpro account.
The only way is to set/change user rights for vmpro on the subfolders.
Nvertheless VMPro should hqve read rights to all folders in the ./opt/vmpro and undelaying folders meaning all wavs can be read and used.
So testing the spanish locale shuold play spanish system prompts for a user with the spanish locale.
Once you tested that you can move on to change r/w attributes on other folders under./custom

Open a shell with root rights and type the command "setfacl -R -m u:vmpro:rwx ./opt/vmpro/Custom", it will give VMPro read/write access to all files and folder beneath ./Custom
Check the correct path name as it is casesensitive and i don't know it from the head

 

[TouchToneTommy]

Based on AegisTech calling the file $LOC\Custom\base120.wav, you're using Kyle Holladay's Standard Base Configuration VM mdb

Use WinSCP to browse the files in the App Server. /opt/vmpro/WAVS/es/Custom is where the base120.wav should reside. See if it is there.

Also forward and back slashes matter in Linux but not in Windows, as well as capitalization of the folder and files names, including the extension. I've seen where basexxx.WAV was in VMPro, but the file was basexxx.wav which doesn't match in the app server but does in Windows

 

[sizbut]

BTW. Intrigrant is correct on the error with the use of an external DDI. In that case the locale used would be taken from the incoming call route unless you routed that to a short code set to Spanish. Setting the user (the one making the call, not the one called) locale to Spanish would only apply to internal access to voicemail.

Stuck in a never ending cycle of file copying.

 

[dsm600rr]

TouchToneTommy: Thank you. And you are correct, this is a Kyle Holladay Base Config. I will preform the suggested and report back.

intrigrant: Thank you for the suggestions and information.