I think I have found a potential hole in the way that vgetty handshakes with the call_program but thought I'd pass it by the combined wisdom of this list before making a goose of myself with the authors. ;-)
Vgetty's "handshaking" between it and the shell appears to me to be flawed because vgetty responds with the same string "READY" to all successful commands. It also responds with "READY" when it finishes playing a message. Furthermore the hand shake is not a 1:1 with the shell. If vgetty get's input from the modem it will put more commands into the shells receive queue wihout requiring the shell to send a command to it. This creates the potential for the handshake to become out of sync.
This manifests itself on my system when the playing of a message ends just millisecs after the caller keyes in a number. The vgetty routine puts a "RECEIVED_DTMF signal into the queue along with the keypad character. It then puts "READY" signal into the queue just as the sound file finishes playing. The shell fetches the DTMF key and decides to tell the shell to stop playing the current message. The shell is expecting a "READY" response which it gets immediately. It then instructs vgetty to play the next message expecting a "PLAYING" signal, but instead it gets a "READY" signal. Errps!
Ascii diagram of the handshaking between Vgetty and the voice shell, time axis down the page, enable events autostop etc allready set
Vgetty Shell send PLAY message.rmd
recv PLAY message.rmd
send PLAYING
recv PLAYING
(waiting for next response)
(callers types a number, eg '9')
send RECEIVED_DTMF
send 9
recv RECEIVED_DTMF
recv 9
# So far so good, now things get messy. (message has finished playing send "READY") (tell vgetty to "stop" playing)
send READY send STOP (expect ready)
recv STOP (huh? STOP received during idle) recv READY (wrong "ready")
send READY send PLAY newmsg.rmd
recv READY (huh? should receive
"playing")Comments?
P.
-- SLUG - Sydney Linux User's Group Mailing List - http://slug.org.au/ Subscription info and FAQs: http://slug.org.au/faq/mailinglists.html
