Jump to content

Use of Variable to build wav filename to announce

Ben Vlaeminck

Recommended Posts

I'm looking for the right way (defining variable and syntax for announcement file) to define the contents in the Play Announcement block - Announcement field, in order to play the correct file based on chosen language via Get dtmf Char.

File names are constructed as "NL_Welcome.wav" and "FR_Welcome.wav".

Depending on dtmf char entered, 1 for NL, 2 for FR, I like to set a variable Language_Prefix to NL in case 1 pressed, to FR in case 2 pressed.

then use the Language_Prefix to construct full filename in Announcement field by composing Language_Prefix and "_Welcome.wav".

look forward to your replies...


Link to comment
Share on other sites

Thank you Tom, I noticed this article already, but it's not really what I'm looking for.

The full purpose of my setup is to use the Language Choice not only in this rule, but also in rules following this one to determine the language of ALL announcements played for this call. Not by checking theVariable value and havind 2 or 3 different blocks for 2 or 3 different language announcements. One Block should do the job for any language.

All other Announcements have also been setup in order to comply to this structure "LC_NameOfAnnouncement.wav" whereby LC is the LanguageChoice.

Is this possible?

Link to comment
Share on other sites

In that case you can simply store the language selection into a global variables (being defined in the start block of one of the active call routing rule of the script user) and use that variable to build the filename in the play announcement block.


For example, put this line into the start block of one of the active call routing rules:

Dim sLanguagePrefix


After the the different exits of your get dtmf character block place insert script code blocks and fill the variable according to the language selection, e.g.

sLanguagePrefix = "EN"


When using a play announcement block you can then simply calculate the final name of the wav file to be used by entering the following into the announcement text field:

= sLanguagePrefix & "_NameOfAnnouncement.wav"


Link to comment
Share on other sites

Tom, one more problem...

This works perfectly within the rule the variable content was set, all announcements follow correct language.

But in that rule, at the end I Skip the rule to go to the next rule in CRM, and there the content of the variable is lost...

what do i do wrong? what do i mis?

Link to comment
Share on other sites

Hi Tom, or others?

Please pick this one up, it's blocking my customer...

I was on the go to use Persistent Variables for this one, i.e. setting the LanguageChoice variable as a Persistent Variable, but I don't think that will work.

- first call comes in, and Dutch is choosen; messages will announce in Dutch

- While first call is still in the Call Routing script, with possible other announcements to come, a second call comes in, setting the LanguageChoice to English; this will make that my first call will hear coming messages in english too, I should think...

So, I'm looking for a way to pass my LanguageChoice variable contents from rule to rule for a specific call only. for another call LanguageChoice can hold another value, but also needed in multiple consecutive rules from the same user Call Routing.

thanks for your ideas about this!


Link to comment
Share on other sites

Hello Ben,


the persistent variables are not the solution here as you already figured. They share they content with all simultaneously running scripts of the same user (when using the "user" scope").


Running different scripts after each other by using the "rule sipped" exit only works if a call hasn't been connect by a previous rule. A call is already getting connected if you play an announcement as the server needs to connect it to be able to play the announcement.


There is in fact only one solution in this case: place all call routing into one GSE rule.


Now of course your rule can get quite huge. This can be handled easily by still having your call routing sort of separated as it is now by different rules, but now by using GSE actions. A GSE action is sort of a call routing subroutine you are able to create with the GSE and call it later on with the "Run GSE Action" block. Actions can not only be used to handle complexity, but also to share call routing functionality over different users, as they can be stored globally.


I assume you have access to the Swyx Partner Net (as you mentioned your customer). In there you will find a webinar explaining the usage of GSE actions in details, including the "global" functionality.


Link to comment
Share on other sites

Hi Tom,

Is it possible to create a Persistent Variable that who's name is composed of a fixed part and a variable part, whereby the variable part is the CallID() system variable.

this way, every unique call maintains it's for the call unique contents that can be checked anywhere in the rules...

Link to comment
Share on other sites

I already figured that out, but thanks for your thought about this.

As a solution I was wondering if there could be a function or procedure to delete a PV after the call is ended.

If not feasable, a SQL script will need to run on a scheduled base, to delete older records from the table; i.e. records older than today... (or last week/month, leaving resources for troubleshooting passed issues in this respect).

As an addition, a more easy / flexible built-in system feature to handle multilanguage would be nice to have.

If this solution works out, I may write an addendum to the already available article on the forum about Best Practices to handle Multilanguage announcements :).

thanks for thinking with me! I'll keep you informed.

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use and have taken note of our Privacy Policy.
We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.