Does the ability to remotely (non-US) send data over dial-up to a US number exist as a service?

I’m really new to telephony, I’m 24 so was never exposed to dial-up and modems and things like that.

I’ve recently found myself in the position of wanting to do dial-up communication with a phone number in the US, specifically to emulate the client side of a payment terminal (but communicating with the real server).

I know the protocol that I’m supposed to be emulating, I know that it needs to be done over dial-up, I have the phone number. But I haven’t started writing an implementation yet, because I don’t live in the US, and thus have no access to modem/hardware equipment.

ChatGPT kept pointing me to asterisk, but from reading the docs it’s clear that’s not exactly what this software is for, but I still wanted to ask this community: Do you know of any services that could let me virtually send bytes to go to a specific US number over dial-up?

As I’m new to all the terminology, it’s unclear if this is even a thing. I’m aware there are VOIP processing services, and RAS services that allow you to receive dial-up - but are there any that allow you to remotely control or initiate calls and data transfers to a number hosted in the US? Is there a way to set this up through hosting providers who don’t provide exactly this solution, but provide the foundations?

I ended up in this community by accident, but I think people here might be the best to ask.

I appreciate your time reading my post, thanks guys.

On Sunday 17 November 2024 at 20:20:19, taint via Asterisk Community wrote:

… to emulate the client side of a payment terminal (but communicating with
the real server).

I know the protocol that I’m supposed to be emulating,

What is that protocol? It would help to know what specification you have to
meet in order to be able to communicate with the server. It might be
something standard such as one of the ITU V.something modem specifications:

If this is the case, your best bet is simply to get a hardware modem (assuming
you can find someone selling such things these days - it’s about 30 years since
I last used one).

On the other hand, the equipment may be using something proprietary (which
wouldn’t entirely surprise me for a payment terminal), in which case you’ve
got a much more interesting challenge on your hands.

I’m not at all sure Asterisk is the right tool for the job in either case.

So, what do you currently know about the communications specification between
the client you want to emulate, and the server?

Antony.


Don’t procrastinate - put it off until tomorrow.

                                               Please reply to the list;
                                                     please *don't* CC me.

you are going to have to buy something like this:

US Robotics Sportster External 33.6 Faxmodem Model 0459 unit only | eBay

But you are going to need to buy it from the country you live in because different countries often do not use the same sound frequency and cadence for the sounds we hear when dialing a phone number, such as ringback tone and busy tone.

As a result a US dialup modem is highly likely to NOT work when plugged into your telephone network in your country. And, if your telephone network does NOT provide a so-called “POTS” or “land line” then you are really going to be screwed.

Also you will be dialing internationally. There will be high long distance charges.

There are NO services that I know of that let you virtually send bytes to a specific US telephone number over dialup.

What you really need is to find someone living in the United States preferably in the state that the destination telephone number is located in (unless it’s an 800 number) who is willing to setup a machine with a modem on it you can SSH into and develop on and buy a telephone line that plugs into that modem. Any “old school” ISP could do this - if it was back in 2004, 20 years ago when I was working at my old ISP employer Internet Partners - this would be a snap, we’d write up a contract and build up a physical machine for you, get a POTS phone line, plug it in and you could then SSH into it and go to town. We had a pile of modems so no problem there.

Today, you are going to have as much problem finding someone in the US who can do this as you are having figuring it out, anyone under the age of 45 probably has zero experience with any of this tech. This is really, really old school. Plus the fact you want to dial into a bank/payment terminal processing facility is already going to freak a lot of people out.

It sounds to me like you got a contract from someone in the US wanting cheap telephony development done who doesn’t know the first thing about the Public Switched Telephone Network. They probably talked to a bunch of phone devs in the US my age who quoted them a LOT and went overseas. Is there any way you can go back to them and say “look if you want me to do this your going to have to do some hardware setup in the US”

A couple of other things you should probably know as well:

Just about all these dialup processing networks limit to either 300baud or 1200baud because the higher speeds are unreliable over the PSTN. And a LOT of the “more modern” 56k modems have serious problems with that low of a speed. I’m PRETTY sure I’ve done 1200Baud connections with that 33k Sportster back in the day. But, it’s going to be something of a crapshoot. You will have to force the serial port on the PC into 1200bps to make the modem do 1200baud. That also requires a REAL serial port in the PC not one of those USB-to-serial port “dongles” The dongles often drop characters and other such rubbish.

The Linux drivers do best with the MOSChip based serial ports, just as a FYI.

Incidentally I still, to this day, use a modem. I use it to dial my cell phone for paging alerts, the reason is that if my Internet connection dies then it wouldn’t normally be able to send me an alert so the PSTN is the only way. It’s plugged into a real POTS line and a FreeBSD system. It’s actually a voicemodem and when it makes a call to my phone I answer it, like it’s a phone call, and it sends out a prerecorded warning alert. The reason I have to do it that way is because all of the cell companies have shut off their dialup paging gateways.

Most modems work in terms of bits, not bytes. They may provide for 8 unit asynchronous data, but underneath they convert that to bits, or groups of bits.

56k modems are only 56k one way, because they require a digital connection to the high speed sending end.

Asterisk does have some software modems, but not, I think, they highest speed ones.

Trans-oceanic circuits can do tricks that mean they are only really suitable for voice. I don’t know if it still exists, but there used to be a special prefix for calling the USA from the UK, which guaranteed that these techniques weren’t used, and which were charged for at a higher rate.

I can’t imagine there is any market for the sort of service that you are talking about.

You need a much more detailed technical understanding of the standard you are trying to match than I think you currently have.

RAS is specific to Windows, and I don’t think it covers all possible uses modems; I think it is more for dial up IP.

Many thanks for your replies @david551 @TedM - it’s really insightful, and yes maybe I am a bit too young for this haha!

This is actually for a security assessment - I have already been able to emulate the terminal protocols over IP to a web service online where I was able to confirm and report some security vulnerabilities, but I found that the terminals I am doing a security assessment of also support dial-up, so I want to develop a proof-of-concept video for that route too.

Here is the information I know from the terminal application specification:

Line speed: 300 BPS/1200 BPS, Async
Data formats: 7 bit, ASCII, even parity, 1 stop bit
Modulation: FSK carrier frequency - 1070/1270 HZ
Modem: compatible with Bell 103/212a in originate mode, no error correction.

Additionally, I have the terminal application’s specific protocol and example messages in their binary form, so really I just need to work out how I would be able to send this to the number in the US.

It sounds like the consensus is I will need to use US hardware connected in the US for this, and this is fine as I have a friend who could help with this. Is the eBay item linked something that would work with the communication parameters I’ve laid out here?

The only requirements for using the modem would be a phone line with an rj11 connector to plug into the modem, and a serial port connector to connect the PC to the modem, right?

I’m also going to look into whether getting a PoS terminal devkit with a modem backed in and sdk to re-implement the termainl application, if this might be easier.

Thanks for the insightful responses guys!

and @Pooh (it wouldn’t let me tag three people :L)

Just to add, there is also the potential that the standard has moved on since the document I have is old (dated 2008) and they could’ve changed to a different set of communication parameters, although I think this might be unlikely because the technology is very old and banking like payment terminals is usually ‘if it aint broke’.

I will have to research the capabilities of all the physical pos terminals compatible with the terminal application to get a feel for whether this is likely or not.

There is a third party soft modem for Asterisk that does Bell 103 and V.22. I can’t get a definitive answer to whether V.22 is the same as Bell 212a; that might involve obtaining both specifications and comparing them.

To use theme, you would need a guaranteed 3.1kHz (not speech) G.711 path, all the way, and would probably need it to support the 2,100Hz echo suppressor disable tone. Round trip times might prove incompatible with the higher level protoicols, or possibly even with the start up for the Bell 212a.

The technical parameters given only apply to Bell 103, not to Bell 212a. (The carrier frequency is probably more accurately 1,170 Hz, as the pair given represent the mark and space (roughly 1 and 0) frequencies. Also they only represent the frequencies from the calling to the called device, different frequencies are used in the other direction. It seems unlikely that you could do a remote test without communicating in both directions.)

(Bell 212a is QPSK, not FSK. For V.22, at least, the carrier frequencies are 1200 Hz one way, and 2,400, the other. although I don’t know which is used by the originating side.)

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.