# Run the answering machine in runlevels 3, 4 and 5 S0:345:respawn:/sbin/vgetty ttyS0to /etc/inittab. You can run
# telinit qto force init to re-read the inittab. If you're init default runlevel is 3, 4 or 5 (the usual case), then vgetty will be started on /dev/ttyS0 automatically on boot. Details are in the man page, inittab(5).
$ sox -c 1 -r 18939 -t ossdsp /dev/dsp greeting.wav
$ sox greeting.wav -t ossdsp /dev/dsp
$ wavtopvf greeting.wav | pvfspeed -s 9600 >greeting.pvf
$ pvfspeed -s 9700 greeting.pvf | pvftowav | sox -t wav - -t ossdsp /dev/dsp
$ pvftormd ZyXEL_1496 2 greeting.pvf greeting.rmd
$ rmdtopvf greeting.rmd | pvfspeed -s 9700 | pvftowav | sox -t wav - -t ossdsp /dev/dsp
# cp greeting.rmd /var/spool/voice/messages/standard.rmd
rmdtopvf [message.rmd] | pvfspeed -s 9700 | pvftowav | sox -t wav - -t ossdsp /dev/dsp
Here's a shell script that will convert the .rmd file to an 8000 samples/second .wav file and email it to you at work
#!/bin/bash MESSAGE=$1 CALLERID=$2 CALLNAME=$3 WAVFILE=`echo $MESSAGE | sed 's/.rmd$/.wav/'` rmdtopvf $MESSAGE | pvfspeed -s 8000 | pvftowav >$WAVFILE echo "Number: $CALLERID Name: $CALLNAME" | mutt -s "telephone message from $CALLNAME" -a $WAVFILE you@work exit 0
message_program /etc/mgetty+sendfax/message.shin /etc/mgetty+sendfax/voice.conf, then telephone messages left for you at home will get emailed to you at work as .wav file attachments. Note that you must run an MTA (such as sendmail, qmail or postfix) on your home computer in order for this to work. Some MTAs are considered significant security risks.
As far as I could tell, vgetty was not setting this register and so the voice modem was ignoring the caller ID information sent by the telco. So I dug through the vgetty source code looking for where the modem was initialized, and finally hit pay dirt in the file mgetty-1.1.28/voice/libvoice/ZyXEL_1496.c, in a function called "ZyXEL_1496_init" (unsurprisingly). This function sets bits 3, 4, 5 and 6 of S-register 40 to enable distinctive ring detection, but does not set bit 2 to enable caller ID.
mgetty, a close cousin of vgetty, supports user-defined modem init strings via the "init-chat" parameter in /etc/mgetty+sendfax/mgetty.config file. Unfortunately, as far as I could determine vgetty has no corresponding facility. However, this is free software so it is possible to patch the source code and fix this small deficiency in what is otherwise a superlative piece of software.
So I added a couple of lines of code to that the ZyXEL modem initialization would turn on caller ID detection, and since version 1.1.25 (which was shipped with Red Hat Linux 7.1) was getting a bit out of rev, I decided that I would patch up version 1.1.28 instead. So I rolled some RPMs, which are available below (N.B., the binary RPMs are for two architectures, namely Alpha and i386. The Alpha binaries are a bit out of rev now, but I will be updating them soon, once I get my PWS-600au back up!):
Alpha | Intel | |
---|---|---|
mgetty | mgetty-1.1.28-5.alpha.rpm | mgetty-1.1.30-0.8.i386.rpm |
mgetty-sendfax | mgetty-sendfax-1.1.28-5.alpha.rpm | mgetty-sendfax-1.1.30-0.8.i386.rpm |
mgetty-viewfax | mgetty-viewfax-1.1.28-5.alpha.rpm | mgetty-viewfax-1.1.30-0.8.i386.rpm |
mgetty-voice | mgetty-voice-1.1.28-5.alpha.rpm | mgetty-voice-1.1.30-0.8.i386.rpm |
and the source RPM is here.
The following table is a summary of some modems that I personally have tried:
Model | vgetty | caller-id |
---|---|---|
ZyXEL U-1496E | yes | with patch |
Zoom 2949 | with patch | not yet |
Hayes Optima 336 | yes | not yet |
A more detailed discussion of my experiences with these modems is below. I believe it should be possible to make caller-id (a.k.a. "calling number delivery" or CND) work with all of these modems; I just haven't got around to making the patches yet.
Using the default /etc/mgetty+sendfax/voice.conf file, the modem would not automatically hang up after the caller had left a message, but instead would attempt to receive a data/fax call. I tracked this down to the way that the Zoom modem reports end-of-message to vgetty. If you don't want to know the details, skip the next paragraph.
When the modem (henceforth called the DCE) is put into voice recording mode, it transmits control and status information back to the computer (henceforth called the DTE) by sending "data-link escapes" (DLEs) in-band followed by a character which specifies what the DCE is communicating to the DTE. The sequence DLE q is supposed to mean "silence detected" and is the DCE's way of telling the DTE that the message is finished. The sequence DLE s is supposed to mean "no voice energy" and is the DCE's way of telling the DTE that it doesn't think this is a voice call, so it should try something else (like data or fax). Unfortunately, the folks at Lucent interpreted this differently, and (on page 67 of the document linked above) they return DLE s for "hangup detected". Since most folks hang up after they leave a message, this leads vgetty off to try a data or fax connection when really it was just the end of a normal voice message.
I found a workaround for this, and I have a patch which will enable you to use this modem with vgetty, with the caveat that it will not be able to automatically switch between voice and data/fax modes after this patch is applied.
Nonetheless, the messages recorded by the Zoom modem have the strange property that although they start out fine, they shift to a high speed (and pitch) after just a couple of seconds. I haven't tracked this down yet. I also don't have caller ID working on the Zoom modem yet, but I should soon.
If there are other voice modems out there that you would like to use, let me know (contact info is here) and I'll see what I can do. I might have to ask you to send me the modem.