vgetty, rockwell, and incoming data calls: a FAQ?

Gardner Cohen (beldar@pobox.com)
Mon, 8 Jun 1998 21:05:47 +0200


Or, how to cope with a modem like a Rockwell that doesn't do acceptable
fax/data discrimination.

Symptom: incoming data calls wait for the carrier tone vgetty offers after
a period of silence after the greeting.  The modems then scream at each
other for as long as 60 seconds (presumably as long as the shortest of the
two modems's timeout values).  The answering modem spews fax tones, while
the originating modem generates data carrier tones.

One solution: have the originating modem generate data calling tones (I had
never heard of these until Gert mentioned them when I asked about this a
while ago).  For some/most modern rockwell modems, putting a '^' in the
dial string accomplishes this.

Then things work very nicely.

Incoming fax with fax calling tones: vgetty starts to play greeting,
rockwell detects fax calling tone, vgetty interrupts the greeting and
offers a fax carrier.  All is well.

Incoming data with data calling tones: vgetty starts to play greeting,
rockwell detects data calling tone, vgetty interrupts the greeting and
offers a data carrier.  All is well.

Incoming voice: as before.

Incoming fax without calling tones: vgetty offers a fax carrier after silence.

Incoming data without calling tones: you are still out of luck.

Unfortunately for those of us dialing in using win95 machines, win95
doesn't accept '^' as a valid phone number character.  I've been unable to
find out how to modify the character class to do this, but found a
workaround.  There's a registry setting for the character to send for
"pulse" or "tone" dialing ("P" or "T" respectively).  Since I never call
from pulse phones, I've changed that registry key to be "T^" and have set
up my DUN connections to use pulse dialing.

It's been suggested on the mailing list that the originating modem could
send a '1' DTMF to interrupt the incoming message and get a data carrier,
but in my experience (vgetty 0.8.0 / 18Mar98; mgetty 1.1.12-Jan27, as well
as the latest version) all that gets me is the modem's useless data/fax
discrimination cycle (see screamfest described in the first paragraph).

Here's an example log file of 1.1.14 responding to a '1' DTMF during the
greeting:

06/08 11:41:11 yS2  vgetty: experimental test release 0.8.1 / 25Mar98
06/08 11:41:11 yS2  mgetty: experimental test release 1.1.14-Apr02
...
06/08 11:41:42 yS2  playing voice file /var/spool/voice/messages/standard.rmd
06/08 11:41:42 yS2   vgetty: raw modem data header found
06/08 11:41:42 yS2   vgetty: modem type Rockwell found
06/08 11:41:42 yS2   vgetty: compression method 0x0004, speed 7200, bits 4
06/08 11:41:42 yS2    vgetty: queued event RESET_WATCHDOG at position 0004
06/08 11:41:42 yS2   voice command: 'AT#VBS=4' -> 'OK'
06/08 11:41:42 yS2    vgetty: AT#VBS=4
06/08 11:41:42 yS2    vgetty: unqueued event RESET_WATCHDOG at position 0004
06/08 11:41:42 yS2    vgetty: voice_handle_event got event RESET_WATCHDOG
with data <_>
06/08 11:41:42 yS2    Rockwell: AT#VBS=4
06/08 11:41:42 yS2    Rockwell: OK
06/08 11:41:42 yS2    vgetty: queued event RESET_WATCHDOG at position 0005
06/08 11:41:42 yS2    vgetty: unqueued event RESET_WATCHDOG at position 0005
06/08 11:41:42 yS2    vgetty: voice_handle_event got event RESET_WATCHDOG
with data <_>
06/08 11:41:42 yS2   voice command: 'AT&K3' -> 'OK'
06/08 11:41:42 yS2    vgetty: AT&K3
06/08 11:41:42 yS2    Rockwell: AT&K3
06/08 11:41:42 yS2    Rockwell: OK
06/08 11:41:42 yS2   tio_set_flow_control( HARD XON_OUT )
06/08 11:41:42 yS2   voice command: 'AT#VTX' -> 'CONNECT'
06/08 11:41:42 yS2    vgetty: AT#VTX
06/08 11:41:42 yS2    Rockwell: AT#VTX
06/08 11:41:42 yS2    Rockwell: CONNECT
06/08 11:41:47 yS2    Rockwell: <DLE> <1>
06/08 11:41:47 yS2    vgetty: queued event RECEIVED_DTMF at position 0006
06/08 11:41:47 yS2    vgetty: unqueued event RECEIVED_DTMF at position 0006
06/08 11:41:47 yS2    vgetty: voice_handle_event got event RECEIVED_DTMF
with data <1>
06/08 11:41:47 yS2    vgetty: <VOICE DATA 19440 bytes>
06/08 11:41:47 yS2    vgetty: queued event RESET_WATCHDOG at position 0007
06/08 11:41:47 yS2    vgetty: unqueued event RESET_WATCHDOG at position 0007
06/08 11:41:47 yS2    vgetty: voice_handle_event got event RESET_WATCHDOG
with data <_>
06/08 11:41:47 yS2    vgetty: <INTERRUPT PLAY>
06/08 11:41:47 yS2   voice command: '' -> 'OK|VCON'
06/08 11:41:47 yS2    Rockwell: VCON
06/08 11:41:47 yS2    vgetty: trying data and fax connection
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I'd like to have it report "trying data connection" in this case.
06/08 11:41:47 yS2   voice command: 'AT#CLS=2' -> 'OK'

Looking at vgetty/answer.c, I see that if I'd implemented a call_program
script, I could have it return an exit status to select data, fax, or
data+fax.

The file doc/Readme.voice_shell states (when describing the default behavior):

  If vgetty detects a single number only, it stops playing, then tries to 
  make a data connection with the remote end, if it doesn't succeed, then 
  it tries a fax connection with the remote end. 

which is not the case, which you can verify by looking at event.c.

One can enable data-only reception after a single digit DTMF with this patch:

--- event.c~    Thu Mar 26 00:58:57 1998 
+++ event.c     Mon Jun  8 11:52:43 1998 
@@ -73,7 +73,7 @@ 
                     { 
                     first_dtmf = FALSE; 
                     voice_stop_playing(); 
-                    answer_mode = answer_mode & (ANSWER_DATA | ANSWER_FAX); 
+                    answer_mode = answer_mode & (ANSWER_DATA); 
                     switch_to_data_fax_mode = TRUE; 
                     return(OK); 
                     }; 

But for my purpose, the data calling tone is the cleaner solution.