wardmundy
Nerd Uno
- Joined
- Oct 12, 2007
- Messages
- 19,201
- Reaction score
- 5,220
This is still on my Wish List for 3CX, but I thought I would sketch out a possible way 3CX could easily implement support for text-to-speech applications and see if anyone else has suggestions before passing this along to @Nick Galea & Co.
I think the easiest design would be using Custom Extensions. In its most rudimentary form...
Custom Extension Template
Extension Number
Extension Label
Opening Prompt (.wav or .gsm)
App Name (custom directory would house scripts which could be bash, PHP, perl, etc)
Custom Variables for App (separated by commas)
Results Prompt (could be generated by App as a result or canned prompt like Opening Prompt)
Failed Call Prompt
How This Would Work
When the custom extension was called either directly or from an IVR, the system would answer the call, play the Opening Prompt (if any), and then execute the App passing a current time stamp and CallerID number/extension number plus the Custom Variables (if any). The current time stamp is important because it will be used by the App as the file name to return the TTS result in .wav or .gsm format. The CallerID is important because it gives the App a way to look up a particular caller's account info in a database.
The App itself will parse the variables and then perform its magic, e.g. generating a news report or weather forecast. The App results will be stored in a sound file in /tmp as timestamp.gsm or timestamp.wav. Control then is returned to 3CX which plays the Closing Prompt (/tmp/timestamp) and then hangs up the call. There would need to be some sort of timeout value for the App so that 3CX kills the App after x number of seconds and plays the Failed Call Prompt before hanging up.
Bells & Whistles
Don't want to be too greedy in proposing this but, when we get the basics working, the next big thing would be to process one or more prompts for additional info from the caller. This initially could be touchtone input for an account number or zip code. This could be handled by additional fields in the Custom Extension Template for Voice Prompt 1, Result 1 and Voice Prompt 2, Result 2. These results would be passed to the App as the final variable in a Results array which could be populated or empty.
Down the road it could be STT voice input (.gsm or .wav files instead of text) that could be converted to text by the App and then processed.
I think the easiest design would be using Custom Extensions. In its most rudimentary form...
Custom Extension Template
Extension Number
Extension Label
Opening Prompt (.wav or .gsm)
App Name (custom directory would house scripts which could be bash, PHP, perl, etc)
Custom Variables for App (separated by commas)
Results Prompt (could be generated by App as a result or canned prompt like Opening Prompt)
Failed Call Prompt
How This Would Work
When the custom extension was called either directly or from an IVR, the system would answer the call, play the Opening Prompt (if any), and then execute the App passing a current time stamp and CallerID number/extension number plus the Custom Variables (if any). The current time stamp is important because it will be used by the App as the file name to return the TTS result in .wav or .gsm format. The CallerID is important because it gives the App a way to look up a particular caller's account info in a database.
The App itself will parse the variables and then perform its magic, e.g. generating a news report or weather forecast. The App results will be stored in a sound file in /tmp as timestamp.gsm or timestamp.wav. Control then is returned to 3CX which plays the Closing Prompt (/tmp/timestamp) and then hangs up the call. There would need to be some sort of timeout value for the App so that 3CX kills the App after x number of seconds and plays the Failed Call Prompt before hanging up.
Bells & Whistles
Don't want to be too greedy in proposing this but, when we get the basics working, the next big thing would be to process one or more prompts for additional info from the caller. This initially could be touchtone input for an account number or zip code. This could be handled by additional fields in the Custom Extension Template for Voice Prompt 1, Result 1 and Voice Prompt 2, Result 2. These results would be passed to the App as the final variable in a Results array which could be populated or empty.
Down the road it could be STT voice input (.gsm or .wav files instead of text) that could be converted to text by the App and then processed.
Phone System 