Connecting two dial-up modems using a VoIP ATA

I'd think of it as how many adapter layers there are to make a legacy technology work like image-only email.

I remember those devices. You cannot restore a backup created with them either.

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 think Polycom, since bought by HP, might have something like that. For wireless backup of a small LAN setup you can examine Cradlepoint.

Do a search for "wireless home phone" (not "cordless"):

* 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...

Which glucometers? Any info released?

By any chance have you firmware for any of these?

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.

This may be a dumb question, but how do you connect analog devices to this?

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):

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. 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.

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.

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.

The VPN before VPNs were popular

Fax over VoIP is used all the time. It works even without T.38.

One needs a FXS port, the other needs an FXO port. FXO's are only commonly found on telco gear.

https://en.wikipedia.org/wiki/Foreign_exchange_service_(tele...

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.

You could have with two 9V batteries https://electronics.stackexchange.com/questions/548222/provi...

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.

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.