For a long time in the dialup era my "answering machine" was a US Robotics voice-capable modem attached to my home Linux PC, with some scripts to make it pick up after N rings, play a message, record whatever the caller said, and then email me the resulting sound file. The Linux support for it included DTMF tone recognition, so I added in a quick hack so that if I sent it the right pin code during the "please leave a message" part it would wait for me to hang up and then dial my ISP, so I could ssh in to it from wherever I was...
I wrote some stuff in Turbo Pascal for DOS to do something like this (albeit it didn't email files-- it just dumped them into a directory on the disk). My parents had two phone lines so making test calls from a real phone was easy. I just had to go around the house and turn off the ringers on all the phones so I wouldn't wake anybody doing test calls in the wee morning hours.
I didn't understand the sample format so all my playback was via the phone handset. I was in over my head, at that time, when it came to grokking audio codecs.
My grand vision was to make some kind of voice-based bulletin board system.
TellMe was one: Call the number, ask it questions, get answers. Part of my normal commute for a time involved calling TellMe to get the weather for the day on a Nokia dumb phone once I got settled into the drive.
Goog411 was another one. You could call Google, ask it questions, and get summaries of search results along with answers for a distinct questions (a lot like LLMs do today). I distinctly recall standing in the supermarket looking at large and inexpensive hunk of meat that was labelled as a "Boston Butt Roast", and calling Goog411 to find some common uses for it. (It did give me confidence to buy it, and we did cook it and eat it. It was lovely.)
These things worked well for that brief moment in time when cellular calling minutes were either plentiful or unlimited, when smartphones didn't commonly exist, and when mobile data was ludicrously expensive.
I was going to use that to start a private voicemail company in my little rural town. Had the name and everything ready to go (mailvox!) but I was too broke to afford the second phone line xD.
Plus in retrospect I'm sure it would have been used almost exclusively for illicit purposes. But that wasn't really something I had thought of back then.
It's funny to think that not that long ago businesses would pay a premium for that feature set from their voice service provider. Maybe not the SSH part lol, but I worked with plenty of small and medium businesses in my career that paid for a voicemail to email service.
The DLE-escaping problem the article mentions — where 0x10 bytes in PCM audio had to be doubled to 0x10 0x10 — is the same class of bug that plagued the Hayes +++ escape sequence in data mode, and it is striking that it was never properly solved. The fundamental issue is that the Smartmodem architecture multiplexed control and bearer on a single serial channel, and every framing scheme for doing that with an 8-bit-clean payload on an async serial link is either fragile (in-band escaping) or wasteful (COBS/SLIP-style byte-stuffing adds overhead proportional to the escape density). The multi-UART solution that modern cellular modems adopted — separate serial channels for control, bearer, GNSS, debug, etc. — is really the only correct answer, and it is interesting that it took nearly two decades to become standard practice. What Harald Welte describes in his 2017 post is not so much an "ugly hack" as it is the inexorable gravitational pull of the Hayes architecture: once you have committed to AT commands over serial as your control plane, every new capability including real-time voice must be shoehorned into that same channel, and the result is always going to look awkward. The persistence of this design through winmodems, ISDN terminal adapters, and into modern 5G USB dongles is a textbook case of interface lock-in outweighing architectural fitness. On the IVR side, it is worth noting that Asterisk's early versions (circa 1999) supported voice modems via TAPI before the project pivoted hard to VoIP and never looked back — Mark Spencer reportedly called the TAPI voice modem support the single most painful integration in Asterisk's history, which says something about the state of V.253 interoperability in practice.
Hayes solved it by requiring +++ to have a one-second pause on either side. Normal data transmission won't pause at that boundary, so the two never get confused. The reason it was a problem at all is because Hayes patented their solution, so manufacturers who didn't want to pay Hayes to license their patent would work around it by not requiring the pause.
> is the same class of bug that plagued the Hayes +++ escape sequence in data mode, and it is striking that it was never properly solved.
When I ran a BBS, it was critical to configure the modem and software to use signaling lines (I forget the term's name, something like the rx or tx line) to signal commands.
I'm surprised that voice modems weren't using these, as they were common with external modems.
Didnt later modem standards introduce HDLC like mechanisms? MNP and later LAPM packetize modem traffic thus you can control what is raw data and what is control layer.
I got a Voice Modem at some point toward the end of the 90's. I played around with it and wrote an answering machine for it in bash. It announced a synthesized welcome message with date and time, and gave options for control of some elements of my home automation via DTMF (after authenticating). It was clunky, but it worked well.
I came across it a few months ago while clearing out some old junk. I did not think twice about tossing it into the trash.
There is at least on class of voice modems the article didn't mention: The type 407 modem. In the 1980-1984 time period, I was part of a project to build a system for approving-disproving checks at some point of sale. The customer came to us, and wanted a way for a retailer to use a touch-tone phone to input a check routing code, have their database provide a determination of the check being good or bad, and returning a message via voice sysnthesizer to the customer on the telephone. In a nutshell, anyway. Their competitors kept requiring the retailers to purchase phones with integral card readers (for reading mag stripe credit cards).
I designed and built the box with the speech synthesizer, and it sat between the customer's computer, and a type-407 modem.
The Bell 407 modem was a large rack of many modems. Too pricey. Too big a hardware investment if you just wanted one incoming line. But we found something called a Tuck 407. The Tuck 407 utilized a 300-baud modem chip, and the one we had only could transmit in this mode. We didn't use this mode. We used the mode that utilized a touch-tone decoder and fed the digits out the modem's serial port. The modem also featured an input for audio, which it fed back into the phone lines. Thus, a voice modem. But the price of teh Tuck 407 was still somewhat pricey at $400 each. I only ever saw two of them cross my workbench, and they were resold to the customer.
My company built their own type 407 modem. They wanted basically a pc board level product that had the same footprint as the voice synthesizer board, so they could both be placed in the same enclosure (card rack). Eventually, that was done. It also chewed up about $30K in R&D costs. But it worked very well. It would have implemented the AT-style instruction set, but nobody was sure how to shoe-horn that on top of the hardware we'd built, that relied on extra control pins of the RS-232 connector into the modem. Several sample units were built, the product passed it's FCC part 15 and part 68 requirements, and only 2 initial sample modem boards ever made it to the customer that had also bought the two Tuck 407 modems.
The plans for the 407 modem got burned up in a fire. Almost like in a novel, it was so classic.
For a long time in the dialup era my "answering machine" was a US Robotics voice-capable modem attached to my home Linux PC, with some scripts to make it pick up after N rings, play a message, record whatever the caller said, and then email me the resulting sound file. The Linux support for it included DTMF tone recognition, so I added in a quick hack so that if I sent it the right pin code during the "please leave a message" part it would wait for me to hang up and then dial my ISP, so I could ssh in to it from wherever I was...
I wrote some stuff in Turbo Pascal for DOS to do something like this (albeit it didn't email files-- it just dumped them into a directory on the disk). My parents had two phone lines so making test calls from a real phone was easy. I just had to go around the house and turn off the ringers on all the phones so I wouldn't wake anybody doing test calls in the wee morning hours.
I didn't understand the sample format so all my playback was via the phone handset. I was in over my head, at that time, when it came to grokking audio codecs.
My grand vision was to make some kind of voice-based bulletin board system.
A voice based BBS could probably trace some kind of cultural or technical lineage to TikTok today, interesting to think about.
There were some things that came kind-of close.
TellMe was one: Call the number, ask it questions, get answers. Part of my normal commute for a time involved calling TellMe to get the weather for the day on a Nokia dumb phone once I got settled into the drive.
Goog411 was another one. You could call Google, ask it questions, and get summaries of search results along with answers for a distinct questions (a lot like LLMs do today). I distinctly recall standing in the supermarket looking at large and inexpensive hunk of meat that was labelled as a "Boston Butt Roast", and calling Goog411 to find some common uses for it. (It did give me confidence to buy it, and we did cook it and eat it. It was lovely.)
These things worked well for that brief moment in time when cellular calling minutes were either plentiful or unlimited, when smartphones didn't commonly exist, and when mobile data was ludicrously expensive.
Goog411 had sms and travel directions, as tap into something like google maps. I used it to travel several interstate trips back in the day
Similar setup for me as well. Later I copied the rig for a long distance and out-of-country call back system to save money. Loved that modem...
I was going to use that to start a private voicemail company in my little rural town. Had the name and everything ready to go (mailvox!) but I was too broke to afford the second phone line xD.
Plus in retrospect I'm sure it would have been used almost exclusively for illicit purposes. But that wasn't really something I had thought of back then.
It's funny to think that not that long ago businesses would pay a premium for that feature set from their voice service provider. Maybe not the SSH part lol, but I worked with plenty of small and medium businesses in my career that paid for a voicemail to email service.
The DLE-escaping problem the article mentions — where 0x10 bytes in PCM audio had to be doubled to 0x10 0x10 — is the same class of bug that plagued the Hayes +++ escape sequence in data mode, and it is striking that it was never properly solved. The fundamental issue is that the Smartmodem architecture multiplexed control and bearer on a single serial channel, and every framing scheme for doing that with an 8-bit-clean payload on an async serial link is either fragile (in-band escaping) or wasteful (COBS/SLIP-style byte-stuffing adds overhead proportional to the escape density). The multi-UART solution that modern cellular modems adopted — separate serial channels for control, bearer, GNSS, debug, etc. — is really the only correct answer, and it is interesting that it took nearly two decades to become standard practice. What Harald Welte describes in his 2017 post is not so much an "ugly hack" as it is the inexorable gravitational pull of the Hayes architecture: once you have committed to AT commands over serial as your control plane, every new capability including real-time voice must be shoehorned into that same channel, and the result is always going to look awkward. The persistence of this design through winmodems, ISDN terminal adapters, and into modern 5G USB dongles is a textbook case of interface lock-in outweighing architectural fitness. On the IVR side, it is worth noting that Asterisk's early versions (circa 1999) supported voice modems via TAPI before the project pivoted hard to VoIP and never looked back — Mark Spencer reportedly called the TAPI voice modem support the single most painful integration in Asterisk's history, which says something about the state of V.253 interoperability in practice.
Hayes solved it by requiring +++ to have a one-second pause on either side. Normal data transmission won't pause at that boundary, so the two never get confused. The reason it was a problem at all is because Hayes patented their solution, so manufacturers who didn't want to pay Hayes to license their patent would work around it by not requiring the pause.
> is the same class of bug that plagued the Hayes +++ escape sequence in data mode, and it is striking that it was never properly solved.
When I ran a BBS, it was critical to configure the modem and software to use signaling lines (I forget the term's name, something like the rx or tx line) to signal commands.
I'm surprised that voice modems weren't using these, as they were common with external modems.
Didnt later modem standards introduce HDLC like mechanisms? MNP and later LAPM packetize modem traffic thus you can control what is raw data and what is control layer.
Not in any widespread manner. Legacy compatibility won as far as the interface between the modem and the computer was concerned.
I got a Voice Modem at some point toward the end of the 90's. I played around with it and wrote an answering machine for it in bash. It announced a synthesized welcome message with date and time, and gave options for control of some elements of my home automation via DTMF (after authenticating). It was clunky, but it worked well.
I came across it a few months ago while clearing out some old junk. I did not think twice about tossing it into the trash.
There is at least on class of voice modems the article didn't mention: The type 407 modem. In the 1980-1984 time period, I was part of a project to build a system for approving-disproving checks at some point of sale. The customer came to us, and wanted a way for a retailer to use a touch-tone phone to input a check routing code, have their database provide a determination of the check being good or bad, and returning a message via voice sysnthesizer to the customer on the telephone. In a nutshell, anyway. Their competitors kept requiring the retailers to purchase phones with integral card readers (for reading mag stripe credit cards).
I designed and built the box with the speech synthesizer, and it sat between the customer's computer, and a type-407 modem.
The Bell 407 modem was a large rack of many modems. Too pricey. Too big a hardware investment if you just wanted one incoming line. But we found something called a Tuck 407. The Tuck 407 utilized a 300-baud modem chip, and the one we had only could transmit in this mode. We didn't use this mode. We used the mode that utilized a touch-tone decoder and fed the digits out the modem's serial port. The modem also featured an input for audio, which it fed back into the phone lines. Thus, a voice modem. But the price of teh Tuck 407 was still somewhat pricey at $400 each. I only ever saw two of them cross my workbench, and they were resold to the customer.
My company built their own type 407 modem. They wanted basically a pc board level product that had the same footprint as the voice synthesizer board, so they could both be placed in the same enclosure (card rack). Eventually, that was done. It also chewed up about $30K in R&D costs. But it worked very well. It would have implemented the AT-style instruction set, but nobody was sure how to shoe-horn that on top of the hardware we'd built, that relied on extra control pins of the RS-232 connector into the modem. Several sample units were built, the product passed it's FCC part 15 and part 68 requirements, and only 2 initial sample modem boards ever made it to the customer that had also bought the two Tuck 407 modems.
The plans for the 407 modem got burned up in a fire. Almost like in a novel, it was so classic.