>Or you can emulate the POTS network: two wires with 24-48VDC present.
Not even that, just two wires for modem-to-modem.
Or a minimum of 3 wires for a direct RS-232 cable.
There are a number of simple "AT commands" which modems respond to since the 1980's.
These are ASCII text commands sent from the COM port to the modem to control it.
New commands were added over the years as modem capabilities and features were advancing, for instance the early personal modems were "acoustic couplers" where you picked up the standard telephone handpiece and dialed the remote mainframe manually. Using the rotary dial before touch-tone phone service became available. Once the remote modem answered, you heard the tone then snuggled the handpiece into the receptacles for the telephone speaker & microphone to communicate 2-way data with the remote device. Before PC's you would be using a dumb ASCII terminal to either send commands from the com port to the modem, or once connected properly, to send & recieve data from the remote mainframe.
Before electronics were very well miniaturized, modems were still external peripherals which connected to the com port using a correctly wired RS-232 cable, and connected to the landline using a RJ11 modular connector (which replaced the acoustic coupling).
Once autodialing became a thing, the ATD command appeared which was sent from the COM port to the modem, including the user-entered target phone number i.e. ATD18001234567, initiating the sequence which connected to the landline, checked for dial tone, then autodialed 1-800-123-4567.
Originally COM ports were known as "serial" or RS-232 connections on mainframes until people started calling them COM ports when IBM came out with its early PC's. They were originally 25-pin D-sub connectors having male pins, OTOH the parallel LPT printer port was a 25-pin D-sub having female sockets. The com port is serial and never needed more than 9 conductors for its cable (often only 3 conductors) and was soon standardized down to a 9-pin D-sub having male pins. It was expected that all computers would have one or more com ports from then on, since this was the main way they were intended to connect to each other in case people wanted to do that. But most users simply moved files by physically transferring floppy disks instead. COM1 ended up as the default mouse connection once the mouse started to gain traction (the early mice had some real balls), eventually the PS/2 style mouse connection took over that duty after the IBM PS/2 version of the PC pioneered that little dedicated circular connector.
Such floppy transfer over "sneakernet" has some obvious limitations when the remote PC is in another building, or even a different floor of the same building, so those few organizations which had a qualified geek would sometimes run an RS-232 cable in-between the offices which needed to be linked. Then with the right communication software users at either end could transfer ASCII data live from terminal to terminal using their command lines, even whole files or do interactive autocommunication. Nobody had ever heard of a GUI.
If the remote computer was in a different building you could use an RS-232 cable up to a mile or two in length depending on data speed (baud rate):
For communicating within the same office, in the mid-1990's Windows began to support baud rates of 115K max even though the fastest speed the phone line could support was 56K on a good day. It still took years as common modem performance rose from 300baud to 2400baud to 9600baud and eventually 56K. Windows then allowed for connecting two modems in "parallel" using two separate phone lines simultaneously in order to reach 115K for those who dared...
as i recall, usr sportsters wouldn't talk without 24vdc minimum; but the couriers had a mode that would talk on cold wire. Bias really does increase range.
This one was one of those weird experiments I tried as a teen and was pretty surprised that it worked. A buddy was staying over and we both had our PCs setup on our dining room table. I don't recall the exact year, but 95-96 probably.
My family had two phone lines (necessitated by my obsession with the Internet), so we started playing Doom in modem mode (one pc connected to the kitchen phone line, and a 50ft cable going to my bedroom). At one point i decide to try the direct connection. ATDT one end, ATA the other (i think the caller init string needed something to tell it to ignore the lack of dialtone) and it worked! At that point we restarted our game in serial mode. I hadn't thought of this in ages.
If you are going to use the SPA series from Cisco/Linksys/Sipura, just be careful to not expose them to the internet or use them on sensitive networks - there’s a really gnarly remote firmware flashing bug in them.
If you use g.711, that's basically the same codec used when your calls pass over a T1 or other digital phone service. Which should be fine.
You're adding latency though, because g.711 over RTP is generally sending 20 ms bursts of data, so now you've got that to deal with.
I don't know if the cisco ata's short circuit the audio path if both ends of the call are on the same gateway, if so that would eliminate or significantly reduce the latency penalty.
It would still be encoded, assuming your (analogue) POTS call traversed more than one exchange then it would have been coded to g.711 (ulaw or alaw) for that inter-exchange. Although (from memory) that would be 10ms packets.
T1 time slots are 8-bits, samples are sent individually, with no packetization delay. There may be some delay between sampling and the time slot, and in a buffer when calls are connected between T1s and the time slots don't need to be matched up.
If you were calling into an x2/kflex/v.90/v.92 modem bank, that was hosted on a T1 (or larger), and v.92 could get 33.6 up, 56k (or so) down. It should be possible to recreate that with VoIP, but I don't know that anyone is that dedicated... anyway for end user modem to end user modem, 33.6 is the limit.
I recently tried this for making a YT video using an ATA with a USR Courier dialing into a ISP's POP in San Jose. V.92 flat out didn't work for me, but V.90 did. Surprisingly I was able get 50-53k downstream carrier rates, upstream was pretty lousy at 14.4-16.8k. The calls only lasted a couple of minutes before they were unable to renegotiate. 28.8k was much more reliable.
Another option I've used in the past is a Cisco voice gateway (like the VG204) or an FXS card in a random old router configured to be able to just route calls between analog ports. The nice way doing it through the VG is it'll pass analog straight through each other without any codec mangling.
I have a VG224 set up like this (local extensions 1001-1024), including a hunt group on x31337 that dials 8 modems I've got connected via a Shiva LanRover.
The bonus with the VGs is they don't need to be networked - you can keep them fully isolated to POTS-only and just use a console cable to set up the config. Of course, if you network them, then you can do Even More Fun Things...
I’ve been trying to collect more firmware images for stuff related to Cisco/Linksys/Sipura VoIP/ATA stacks to see if the vulns I was working on in the SPA series actually do impact more stuff.
One of my end goals is to attempt to make a patch or something, because all this stuffs out of support.
The VG224 has a telco RJ21 interface (that houses all 24 lines) that you can break out to a punch-down block, or dedicated RJ21-to-RJ11 boxes/panels/cables. In my case I have a breakout box with 24 phone jacks.
A VG248 is the same thing, just with two RJ21 interfaces for 1-24 and 25-48.
He got 33.6K doing this? Was it reliable? I did something similar to transfer files to & from a mainframe and ended throttling back to 2400 baud to get a solidly reliable connection. Not a big deal, the files were only hundreds or thousands of bytes.
Way back when PacBell/SBC/AT&T had me on a (digital) multiplexer which meant no 56k and no DSL. 33.6 was fine, and after the multiplexer was removed ADSL2 up to about 4 Mbps down (because the only ILEC out here to invest in infrastructure was GTE/Verizon).
I remember being overjoyed when I got a similar setup (don't recall all the details now) running reliably at 9600 so terminals and faxes were pleasantly usable (2400 is usable, but not exactly pleasant). 19200 was iffy and worked until it didn't (and I recall CPE sensitive) and speed beyond that was a non-starter. Too much time spent fiddling with this back in the day.
Semi-related: I remember needing to send a fax to some institution. I had a multi-function device that's a printer, scanner, copier and fax in one on my WiFi network, and I didn't want to waste paper so I'd just use Windows' Print to Fax feature to send the fax.
I remember contemplating how many encapsulations the document went through: it's supposedly a paper document, but it's all just digital, it went over WiFi to the device, the device dialed the number, and since I was using a cable modem, it did Fax over IP, and at the receiving end it probably never got printed on paper either, being received by a machine that converted it to a JPG/PDF...
Err in this case, the modems would both need to connect to "FXO" ports. All they actually need is loop current. The simplest circuit is just a battery, resistor, and capacitor. Fun tip: this also works to directly connect DSL modems.
Yes it requires that the DSL mode is compatible. Also on second thought I am 99% sure you don't need a wet loop for naked dsl, but you certainly do for analog modems. Sorry for the misleading info; it has been /a while/ since I hacked on copper PSTN stuff...
You're right; don't need a wet loop for DSL. We used to back-to-back DSL modems without them all the time. At least for particular brands (which often advertised they could do this)...maybe there were some that didn't support this.
I had a guy on the team in those long ago days who figured out how to channel-bond a pile of SHDSL modems over a couple of intra-campus phone cables (much less than CAT3 conformant) to get almost 10base-T speeds over a couple of 100m. In the end, we decided the cost of running a fiber was going to be less than the cost of maintaining the DSL solution, as clever as it was, and gave the upgrade path to whatever we wanted.
If the computers were physically close to each other, you could have just run a null-modem cable between them. I did it a couple times as a kid and it worked well.
Once upon a time I owned a little black box that would simulate enough of a phone system that you could plug two computers' modems into it and computer A would get a dial tone and computer B would get a ring.
It was great for developing and testing dialup-based software without having to tie up real phone lines.
These are called telephone line simulators, and you can find them on eBay occasionally still.
If you want the 56k standards (K56flex, X2, V.90, V.92) though, it gets more complicated because the 56k side of the connection has to be connected via ISDN. So you'll need an ISDN simulator instead, plus an ISDN modem which speaks the 56k protocol and a way to get an analogue phone connection out of an ISDN line (might be built into some simulators but there are other ways to do this as well).
I remember when VoIP ATAs first came out that one of the cardinal rules was not to use them with dial-up modems, since the codecs used didn't do well with the encoding schemes used a 33.6kbps and 56kbps.
What has changed since then that makes this work now? (Are networks fast enough that ATA just send PCM now?)
Nothing has changed. The issue wasn't with ATAs themselves, but VoIP providers. They handle things like compression that are out of your control and can mess with the modem signaling. Without a VoIP provider, you can configure everything so that the modems will be able to connect at 33.6kbps. As the article mentions, 56kbps requires special equipment on the ISP's end which is why 33.6kbps is the limit.
The big problem isn't compression - that can at least be disabled (in theory).
Modems expect a circuit-switched network which guarantees zero packet loss and zero jitter. Even if you connect using G.711 μ-law (uncompressed), you're still using a packet-switched network subject to packet loss and jitter. There's just no way around that.
In that regard nothing has changed. This setup is inherently unreliable. You can do it for fun, but trying to get it to work outside of a lab environment is never going to be production quality.
Nothing actually has changed; the regular phone network has been digital TDM for ages. If you disabled the echo cancelling and use an uncompressed codec like ulaw it's always worked to run a modem over an RTP stream, provided you were able to guarantee zero packet loss and zero frame delay (no jitter).
But if you are asking if this will really be reliable over the public Internet, the answer is still pretty much no, not well. Any network hiccups or delays will often just result in the connection dropping completely. The advice to steer clear of such solutions is still as valid as it ever was, but for a hobby retrocomputing project, yeah knock yourself out.
Not to hijack the thread, but we are talking about weird things you can do with ATAs here: anyone know of an ATA with a cell modem? I’m responsible for a municipal septic pump with an autodialer in the control station for alarms. It would be nice to get a phone call from it if it fails.
Yes, cellular modems with RJ11 phone ports do exist. From memory, the ZTE MF275 and the MF288 were such units (both are discontinued, though). You could receive phone calls through it.
Technically speaking, it is an "ATA", but you can't control the FXS port, as it's directly linked to the number associated with the SIM card.
Another solution would be using a cellular router in conjunction with a "normal" manageable ATA, which lets you configure the FXS port with a remote SIP account.
I think you can even find some stuff on ebay/aliexpress that combines both functionalities, but I never tried them (and would be worried of lack of support or firmware updates).
I commonly do work in this space, and my solution is a standard ATA hooked up to a Peplink device for cellular connectivity.
My experience has been that 'serving' over a cellular connection is dicey, and I've abandoned my quest to get static IPs on all of my cellular gateways. Peplink has a management portal that lets me control everything, including a built-in system to connect to web management portals behind the gateway.
PRI/T1 technology based on copper wires is being discontinued in much of the US right now, and consequently, demand for this kind of solution is going up
I remember having to support this device as a VoIP Support engineer. At least the SPA122 works fine if all you need it for is DAC/ADC.
Cisco's SPA 232D, which they frankensteined to support wireless handsets for some reason, is possibly the worse single piece of consumer hardware I have ever had the displeasure in troubleshooting.
I suspect this would not work all that well. Modems were designed in an age when the phone system was circuit-switched, so the protocols involved expect zero "packet" loss and zero jitter. Granted, later modem encoding standards became more tolerant (as the phone system evolved and became less "clean"), but I suspect most home internet links are going to have too much packet loss and jitter for this to work all that well. But it'd probably still be fun to play with.
52 comments
[ 3.8 ms ] story [ 168 ms ] threadhttps://www.epanorama.net/circuits/teleinterface.html
Not even that, just two wires for modem-to-modem.
Or a minimum of 3 wires for a direct RS-232 cable.
There are a number of simple "AT commands" which modems respond to since the 1980's.
These are ASCII text commands sent from the COM port to the modem to control it.
New commands were added over the years as modem capabilities and features were advancing, for instance the early personal modems were "acoustic couplers" where you picked up the standard telephone handpiece and dialed the remote mainframe manually. Using the rotary dial before touch-tone phone service became available. Once the remote modem answered, you heard the tone then snuggled the handpiece into the receptacles for the telephone speaker & microphone to communicate 2-way data with the remote device. Before PC's you would be using a dumb ASCII terminal to either send commands from the com port to the modem, or once connected properly, to send & recieve data from the remote mainframe.
Before electronics were very well miniaturized, modems were still external peripherals which connected to the com port using a correctly wired RS-232 cable, and connected to the landline using a RJ11 modular connector (which replaced the acoustic coupling).
Once autodialing became a thing, the ATD command appeared which was sent from the COM port to the modem, including the user-entered target phone number i.e. ATD18001234567, initiating the sequence which connected to the landline, checked for dial tone, then autodialed 1-800-123-4567.
Originally COM ports were known as "serial" or RS-232 connections on mainframes until people started calling them COM ports when IBM came out with its early PC's. They were originally 25-pin D-sub connectors having male pins, OTOH the parallel LPT printer port was a 25-pin D-sub having female sockets. The com port is serial and never needed more than 9 conductors for its cable (often only 3 conductors) and was soon standardized down to a 9-pin D-sub having male pins. It was expected that all computers would have one or more com ports from then on, since this was the main way they were intended to connect to each other in case people wanted to do that. But most users simply moved files by physically transferring floppy disks instead. COM1 ended up as the default mouse connection once the mouse started to gain traction (the early mice had some real balls), eventually the PS/2 style mouse connection took over that duty after the IBM PS/2 version of the PC pioneered that little dedicated circular connector.
Such floppy transfer over "sneakernet" has some obvious limitations when the remote PC is in another building, or even a different floor of the same building, so those few organizations which had a qualified geek would sometimes run an RS-232 cable in-between the offices which needed to be linked. Then with the right communication software users at either end could transfer ASCII data live from terminal to terminal using their command lines, even whole files or do interactive autocommunication. Nobody had ever heard of a GUI.
If the remote computer was in a different building you could use an RS-232 cable up to a mile or two in length depending on data speed (baud rate):
https://blog.seabird.com/ufaqs/what-is-the-maximum-cable-len...
For communicating within the same office, in the mid-1990's Windows began to support baud rates of 115K max even though the fastest speed the phone line could support was 56K on a good day. It still took years as common modem performance rose from 300baud to 2400baud to 9600baud and eventually 56K. Windows then allowed for connecting two modems in "parallel" using two separate phone lines simultaneously in order to reach 115K for those who dared...
My family had two phone lines (necessitated by my obsession with the Internet), so we started playing Doom in modem mode (one pc connected to the kitchen phone line, and a 50ft cable going to my bedroom). At one point i decide to try the direct connection. ATDT one end, ATA the other (i think the caller init string needed something to tell it to ignore the lack of dialtone) and it worked! At that point we restarted our game in serial mode. I hadn't thought of this in ages.
https://www.fullspectrum.dev/cisco-spa112-forever-day-cve-20...
You're adding latency though, because g.711 over RTP is generally sending 20 ms bursts of data, so now you've got that to deal with.
I don't know if the cisco ata's short circuit the audio path if both ends of the call are on the same gateway, if so that would eliminate or significantly reduce the latency penalty.
If you were calling into an x2/kflex/v.90/v.92 modem bank, that was hosted on a T1 (or larger), and v.92 could get 33.6 up, 56k (or so) down. It should be possible to recreate that with VoIP, but I don't know that anyone is that dedicated... anyway for end user modem to end user modem, 33.6 is the limit.
I have a VG224 set up like this (local extensions 1001-1024), including a hunt group on x31337 that dials 8 modems I've got connected via a Shiva LanRover.
The bonus with the VGs is they don't need to be networked - you can keep them fully isolated to POTS-only and just use a console cable to set up the config. Of course, if you network them, then you can do Even More Fun Things...
I’ve been trying to collect more firmware images for stuff related to Cisco/Linksys/Sipura VoIP/ATA stacks to see if the vulns I was working on in the SPA series actually do impact more stuff.
One of my end goals is to attempt to make a patch or something, because all this stuffs out of support.
The VG224 has a telco RJ21 interface (that houses all 24 lines) that you can break out to a punch-down block, or dedicated RJ21-to-RJ11 boxes/panels/cables. In my case I have a breakout box with 24 phone jacks.
A VG248 is the same thing, just with two RJ21 interfaces for 1-24 and 25-48.
I remember contemplating how many encapsulations the document went through: it's supposedly a paper document, but it's all just digital, it went over WiFi to the device, the device dialed the number, and since I was using a cable modem, it did Fax over IP, and at the receiving end it probably never got printed on paper either, being received by a machine that converted it to a JPG/PDF...
It used a magic cable that talked to the meters using RS-232 and converted the data into audio, plugging into the audio jack on the phone.
So, basically, it was a modem. The cable just had a little bump on it that did everything you used to do with a huge device.
https://en.wikipedia.org/wiki/Foreign_exchange_service_(tele...
I had a guy on the team in those long ago days who figured out how to channel-bond a pile of SHDSL modems over a couple of intra-campus phone cables (much less than CAT3 conformant) to get almost 10base-T speeds over a couple of 100m. In the end, we decided the cost of running a fiber was going to be less than the cost of maintaining the DSL solution, as clever as it was, and gave the upgrade path to whatever we wanted.
It was great for developing and testing dialup-based software without having to tie up real phone lines.
If you want the 56k standards (K56flex, X2, V.90, V.92) though, it gets more complicated because the 56k side of the connection has to be connected via ISDN. So you'll need an ISDN simulator instead, plus an ISDN modem which speaks the 56k protocol and a way to get an analogue phone connection out of an ISDN line (might be built into some simulators but there are other ways to do this as well).
What has changed since then that makes this work now? (Are networks fast enough that ATA just send PCM now?)
Modems expect a circuit-switched network which guarantees zero packet loss and zero jitter. Even if you connect using G.711 μ-law (uncompressed), you're still using a packet-switched network subject to packet loss and jitter. There's just no way around that.
In that regard nothing has changed. This setup is inherently unreliable. You can do it for fun, but trying to get it to work outside of a lab environment is never going to be production quality.
But if you are asking if this will really be reliable over the public Internet, the answer is still pretty much no, not well. Any network hiccups or delays will often just result in the connection dropping completely. The advice to steer clear of such solutions is still as valid as it ever was, but for a hobby retrocomputing project, yeah knock yourself out.
Technically speaking, it is an "ATA", but you can't control the FXS port, as it's directly linked to the number associated with the SIM card.
Another solution would be using a cellular router in conjunction with a "normal" manageable ATA, which lets you configure the FXS port with a remote SIP account.
I think you can even find some stuff on ebay/aliexpress that combines both functionalities, but I never tried them (and would be worried of lack of support or firmware updates).
and verify the frequency support vs. what your area's cell towers use.
My experience has been that 'serving' over a cellular connection is dicey, and I've abandoned my quest to get static IPs on all of my cellular gateways. Peplink has a management portal that lets me control everything, including a built-in system to connect to web management portals behind the gateway.
PRI/T1 technology based on copper wires is being discontinued in much of the US right now, and consequently, demand for this kind of solution is going up
* https://www.ztecanada.com/products/zte-wireless-home-phone-w...
In the US, AT&T has such a service:
* https://www.att.com/device-support/article/wireless/KM126643...
Cisco's SPA 232D, which they frankensteined to support wireless handsets for some reason, is possibly the worse single piece of consumer hardware I have ever had the displeasure in troubleshooting.
I suspect this would not work all that well. Modems were designed in an age when the phone system was circuit-switched, so the protocols involved expect zero "packet" loss and zero jitter. Granted, later modem encoding standards became more tolerant (as the phone system evolved and became less "clean"), but I suspect most home internet links are going to have too much packet loss and jitter for this to work all that well. But it'd probably still be fun to play with.
The equivalent to T.38 for data modems was ITU V.150.1 , but I get the impression that it wasn't implemented much.