On Mar 5, 2006, at 1:52 PM, Daniel Swarbrick wrote:
> I think we should focus more on clearly documenting the transcripts of
> all the voice prompts
as part of the conversion to property lists I will work on a voices &
prompts database.
this will be a property list -say- sounds.plist or perhaps more
accurately recordings.plist and contain information about all
available prompts including the full transcript, voice and language/
locale.
This would look like the following ...
// voices in which recordings of prompts are available
voices = {
Allison = {
fullname = "Allison Smith";
type = human;
gender = female;
locale = US-English;
// subdirectory within SOUNDS_DIR
subdirectory = allison;
};
Lawrence = {
fullname = "Cepstral Lawrence";
type = synthesized;
gender = male;
locale = UK-English;
// subdirectory within SOUNDS_DIR
subdirectory = lawrence;
};
};
// recordings of available prompts
prompts = {
digits = {
voices = ( Allison, Lawrence );
recordings = {
0 = "zero";
1 = "one";
...
};
voicemail = {
voices = ( Allison, Lawrence );
recordings = {
nobodyavail = "Nobody is available to take your call
right now";
...
};
...
};
you get the idea.
Basically, this is an abstraction layer for voice prompts. It would
allow the core to know what prompts are available in which voices and
locales, so it will become possible to set preferences for speakers,
gender and accents both statically and dynamically.
For example, a caller with a UK caller ID could automatically be
played all prompts in one of the available UK accents without having
to rewrite the dialplan. It would also make IVR scripting with
interleaved use of male and female voices easier.
Further, the console could print the transcript and speaker, such as ...
playing prompt "Nobody is available to take your call right now"
using voice "Lawrence" ...
depending on the verbosity level.
The master configuration plist would then be extended with a section
that defines the order in which languages, voices, gender, accents
should be picked, probably depending on locale but also, depending on
a virtual host entity (yet to be introduced), so that when multiple
companies share a single PBX, each company can have their own
preferences.
The full potential of this system can then be realised by writing a
GUI based IVR editor, where you script your dialplan by merely
selecting prompts from a menu while typing in some keywords, then if
none of the available prompts seem suitable, you'd type your own
text, then have a TTS system generate the recording and insert it
into the voices & prompts database. It could further be marked "order
live recording" from which a shopping list of recordings can then be
printed or emailed. Once the human recording has been delivered, the
application could be used to import it without the need to copy
files around and edit the database manually.
> I think there has already been some discussion about a
> system such as en_US, en_NZ, de_DE, de_CH, fr_CH etc, so that the
> system
> can gracefully degrade to another version of the same language if the
> localised dialect/accent is not available. In addition, nominate a
> language to be used as a last-resort language, eg. if a channel is
> using
> de_DE, but a required prompt doesn't exist in any de_* locale, then
> use
> the en_US prompt.
agreed.
> AFAIK, at the moment OpenPBX only has a concept of a language such as
> EN, DE, FR etc, not a full locale code like en_US.
Even worse, the current code base only works within a rather narrow
concept of grammar. Languages which don't fit that concept cannot be
supported properly without architectural changes to the code base.
I had been asked by the folks at Digium to comment on some patches
for Asterisk for Japanese number speaking support a while ago. It
quickly became apparent that changes would be required which the
Asterisk crowd isn't willing to consider.
Basically, the tenor was "This is not how Asterisk works, you will
have to get the Japanese language changed" paraphrasing OEJ.
So, yes, this needs to be sorted out, but it is not trivial, it will
require some serious work.
regards
benjk
___________________________________________________________
To help you stay safe and secure online, we've developed the all new Yahoo!
Security Centre. http://uk.security.yahoo.com
_______________________________________________
Openpbx-dev mailing list
[email protected]
http://lists.openpbx.org/mailman/listinfo/openpbx-dev
