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...
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.
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
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.
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).
>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. Direct COM-port-to-COM-port could do the 115K using a single high-quality RS-232 cable if both PC's were within about 30 feet of each other.
You needed a modem when the remote PC was too far away for direct digital communication between com ports. Once the raw data coming in from the PC to the com port had been "modulated" by the modem for transmission over ordinary landlines, distance was no problem since the phone company handled that no differently than an analog voice call. The receiving modem would "demodulate" the signal coming in from the landline so the recieving com port would end up with the same data as if the com ports at both ends were in direct local contact. That's why they are called modems because they MOdulate/DEModulate the communication stream.
Organizations which were needing to be in constant contact across distance often found it more effective to arrange with the phone company to "lease" a "dedicated" landline between two separate locations rather than continuing to use the random-access public POTS network. These leased-lines had no need for a dialtone since they always connected the same two points and there was not going to be any dialing at all.
To communicate between two modems without going over the public phone lines, there will be no dialtone so you need to use the proper AT commands to instruct the modem to do without a dialtone, as well as a few other considerations. It's best to have the specific technical documentation for the exact modem in use at each end, so you can review the full range of AT commands supported. Some modems have more available commands than the occasional computer language or OS. Hyperterminal was a good app, included with Windows up through XP, for using the PC similarly to a not-so-dumb terminal so you can manually send & recieve ASCII characters (or files, etc) in real time through a COM port and thererby send AT commands to the modem on that port to get things going. After installing the modem device drivers from the manufacturer, their modem software or a third party app was the more user-friendly way (compared to Hyperterminal) to get going with dial-up. Whether it was exposed to the user or not, in the apps there was a field containing the "modem string" of specific AT commands that would be sent as needed for default performance or any optional features that the app supported.
In Hyperterminal you need to compose your own specific modem string and send it manually. If you enable echo you will see everything that you send as well as all data coming in.
Using the ideal (AT and related) commands from each PC's COM port to its modem are essential to be able to configure it away from the default requirement for a dialtone, over into the performance needed for a particular dedicated RJ11 cable between two PC's. You want to follow the modem manufacturers guidelines for "leased-line" operation.
This was essential once PC's failed to all ship with a COM port any more. Modems had been miniaturized to the size of an ISA or PCI card and were then available as internal modems with only a RJ11 jack (or two so you could connect an analog telephone too), and more & more there was not a 9-pin COM port on the back of new PC's at all.
Virtual COM ports appeared as part of the internal modem drivers and delivered the data to the modem by responding to the same software as a physical COM port.
So if you were previously connecting directly from a standard industrial device having a standard COM port, to a PC by connecting directly to its own COM port, when the PC died it could be replaced by a newer PC having only a modem (but without a physical COM port). But then you were going to need to add an external modem to the industrial device so you could run an RJ11 cable in place of the previous RS-232 cable. By then external modems were seldom used any more even though dial-up internet was still growing, so there were lots of surplus external modems and RS-232 cables (which often require various specific, sometimes asymmetric pinout wiring to accomodate things like handshakes).
External modems didn't essentially need device drivers since COM ports needed none, stand-alone modems can really get the job done by responding to AT commands as documented.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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...