Sometimes it would be nice to use a script call somebody and play a message.
I “needed” a wake-up-call system and since I use a voip-phone and have access to a server. I thought i would be quite nifty if I could have the server call me. Furthermore i would like to be able to script calls, so for instance the calendar could call me with reminders rather than sending an email.
jacob@vps:~./control.sh sip:email@example.com "wake up you lazy bastard!"
Is the basic usage i wanted to have. In order to get this functionality there are two steps.
Generating wav file
I ust use text2wave, from festival, which is available as a package on ubuntu.
echo $2 | text2wave - -o message.wav
$2 to use the second argument, and pipe it to text2wave. Let text2wave read sdtin and output a file message.wav
Call and play the wav file
pjsua_app --config-file=test.conf --play-file message.wav $1
Here the magic is in the conf file. Its a rather straightforward to use, and the documentation is good.
# we don't want the host's audio device
# SIP parameters
--registrar sip:firstname.lastname@example.org # DNS SRV, or FQDN
# default of 55 will be rejected as being too short by sipX
# auto-answer all calls with "200 OK"
# automatically loop incoming RTP to outgoing RTP
# mix WAV file into the audio stream
This is based on a config file i found somewhere, can’t remember where. There a a lot of other options, pjsua handles nat quite nicely as well. It was easy to test it at my homebox, behind a router, just be sure to set an external ip address.
Now this will call and play the message, but it wont stop pjsua. It will just sit around waiting for someone to call. I couldn’t find any nice way to handle this, but since pjsua reads stdin for commands, it possible to pipe commands to it.
echo "sleep 60000 q" | pjsua_app --config-file=test.conf --play-file message.wav $1
So sleep for 60 seconds, then accept the next input from stdin, the “q”uit command.
Generally this configuration is set for 1 minute, it might be necessary to tweak this.
There is/were a bug in the tarball, that meant that it wouldn’t run if it couldn’t find a soundcard, since it should run on a vps this is quite annoying. But in the svn version its solved, so if you want to do something like this, use the svn version. Other than this installation is straightforward.
When working with cron, remember to use full paths. In the control.sh script the better solution were to add a cd working directory, in order to have all the paths correct. This were quite annoying to debug, as the script would run from the shell. And just fail when added to the crontab. Furthermore mails from crontab were delayed, so i couldn’t see the output. I did get someone to look over my shoulder and spot the bug.