[asterisk-dev] [feature] Support for relative paths for all "say" functions

[Nicolas Chapleau]

In reponse to tzafrir's comments: 
 
> I am trying to add relative path support for digits/letters/phonetics for all "say" functions that are located in say.c. There are many ways to do this and I'm trying to choose the least
> obstructive as far as I can tell. I'd like some input if possible:
> > 
> > *** Reasoning ***
> > 
> > normal voice files using playback (background, ...) can have a prefix added to the language 
> > 
> > ie. playback(welcome), playback(path1/welcome), playback(sub1/path1/welcome) ...
> > 
> > whereas "say" functions can't => SayNumber(1000)
> > 
> > this limits us to a single voice under a specific language for any digits/letters and phonetics (what I call VOCAB files). We need to able to use multiple voices under an existing language for digits/letters amd phonetics. For example:
 
Comments from tzafrir: 
 
The language serves two different roles here:
 
1. defines the syntax: how exactly do you day the number?
 
E.g. in Hebrew "2009" is not just "two", "thousand", "and", "9",
 
It is basically "two-thousand", "and", "9". 
 
And then there's the simple subdirectory of the number.
 
RESPONSE: 
 
This in no way affects anything to do with the language and how it is said. It only tells where to get the voice prompts from Relative to that language and directory, instead of the root of that language. Instead of playing the file from sounds/LANGUAGE/digits, it plays from sounds/LANGUAGE/VOCAB_RELATIVE_PATH/digits. Please feel free to rename VOCAB_RELATIVE_PATH to anything else that might be less misleading. As a side note, this will also work for any new LANGUAGE architecture that may be used.

> 
> 
> 
> > 
> > Consider the following sound file directory structure:
> > 
> > (English)
> > sounds/digits
> > sounds/letters
> > sounds/phonetics
> > sounds/customer1
> > sounds/customer2
> > sounds/customer3
> > sounds/customer1/digits
> > sounds/customer1/letters
> > sounds/customer1/phonetics
> > 
> > (French)
> > sounds/fr/digits
> > sounds/fr/letters
> > sounds/fr/phonetics
> > sounds/fr/customer1
> > sounds/fr/customer2
> > sounds/fr/customer3
> > sounds/fr/customer1/digits
> > sounds/fr/customer1/letters
> > sounds/fr/customer1/phonetics
> > 
> > there is no way to use the files under customer1 when using any of the "say" functions, as they are hard coded to look in the root language path.
> > 
> > *** Implementation ***
> > 
> > Method 1 (what I would prefer):
> > One way to add this would be to add an element in the ast_chan structure, but I do not want to do this as I feel that it is too obstructive, unless the API has previsions for this.
> > 
> > Method 2:
> > Add the ability to pass in a relative path in each "say" function, but again this changes the way existing functions are called, and also requires a change to each "say" function (to obstructive). 
> > 
> > Method 3 (what I chose):
> > Add an optional CHANNEL variable and use it to prefix the path in ast_say_streamfile. By using this method, I only need to change 1 function (ast_say_streamfile) which is called in ALL "say" functions, as well as add 2 functions that checks/builds the filename with the prefix. This method only applies to functions in say.c and does not affect existing syntax.
> > 
> > *** How it works ***
> > 
> > Add a channel variable called VOCAB_RELATIVE_PATH to enable this feature (simply call the dialplan Set function to enable it). If this variable exists, then the relative path defined by it is used, otherwise it defaults to it's usual location. If the file is not found under the relative path, it also defaults to it's usual location. 
> 
 
tzafrir's comments: 

This duplicates LANGUAGE.

 

RESPONSE:
 
I agree that this seems to duplicate LANGUAGE, but in fact it only complements it. The LANGUAGE field is still used and the VOCAB_RELATIVE_PATH only appends to it. If the functions in "SAY" had relative paths just like the playback and background functions do, this would not be an issue, but they are hard coded. I would like to implement this but I would need to change the syntax and I do not wish to do so for compatibility reasons.

 

Cheers,
 
NicChap.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20090821/4b390f61/attachment.htm