Lots of businesses really, really want a mobile number from me for some reason, don’t accept VoIP numbers, and I don’t want to give them my real mobile number.
So instead I have a stack of SIM cards plugged into GSM USB sticks (like this mostly is) and get the inbound messages sent to me via Pushover notification.
I look for them on eBay but I don't have any current recommendations. In fact, I'm digging around for LTE replacements at the moment since T-Mobile is ending their GSM-only service rather soon.
I have a few USB sticks plugged into a powered USB hub and Gammu watches all of them for inbound messages.
robotmay who also replied to you is correct for what I do, I have multiple prepaid US SIMs with PAYGO rate plans. It's trivial to get many of these and register them in bulk to get "real" mobile numbers.
(This is why I laugh and laugh at people who insist that VoIP numbers are more "fraudulent" because of whatever. Right now, breaking no rules whatsoever, I can get a hundred mobile numbers that any service will accept, and they'll go for a year without needing any more money. Stop using phone numbers as identity verifiers, people. All you're doing is making it harder for the people who aren't technically savvy and accomplishing nothing to prevent actual fraud.)
It's been a while since I looked, but the cheapest US paygo plans are still at least $3/mo (eg H2O wireless), and probably double that if you want more convenient billing. Have you found something better, or are you deriving that much utility from scaling to many devices or what? I'd think if the goal is signing up a bunch of accounts, one would be content with a single plan or maybe two, and just periodically swapping their phone numbers.
It seems like it would be easy enough to change your setup to hide your actual location by locating the gateway elsewhere and backhauling with its own IP connection.
BTW are there any standard interoperable formats for transmitting/presenting/archiving text messages, akin to Maildir for email or SIP for voice? If not, maybe Maildir is the right answer.
How so? None of the fraud prevention APIs I've seen tell you if a given number is connected to a base station, only whether it's theoretically GSM, landline, VoIP, or something else. With the ability to tunnel LTE over an unstructured Internet connection ("wifi calling,") I don't have to be within range of a single US-based base station to "appear" like I am in the US to the mobile network.
And everyone tells me that only accepting "real" mobile phone numbers means they're just piggybacking on the identity checks that mobile carriers do. Which, if true, I'd like to introduce you to Constable George Crabtree and his nineteen perfectly valid mobile numbers, all of them with his name in the CNAM field.
All this does is prevent someone who's not tech savvy and who might be trying to save a bit of cash by using a Republic Wireless or TextNow or some other "free calls and texts!" service from fully participating in this new app-based reality we've constructed. Someone who actually wants to commit fraud will step right over these dumb speed humps and do whatever they like.
I'm not saying don't do fraud detection, I'm saying don't do fraud detection that is so screamingly trivial to bypass.
In the UK you can get a SIM for free from most networks as pay-as-you-go (i.e. you add credit to it instead of getting a monthly bill). With most of those you can happily receive messages on it without ever spending a penny.
The problem is that fixed part of most plans’ pricing make the cost prohibitive, not the pay-as-you-go component (eg the cost of a sim and phone number).
We were able to use a LoRa-like layer to forward to a base station that then uses a VoIP provider to do the brunt of the communication work.
I think I failed to convey my point clearly. My point is that if you need a separate sim per IoT device, the (possibly monthly) cost of a sim and number will greatly exceed the cost of messages sent.
That makes sense. The provider incurs an ongoing (trivial to them in bulk) cost for leasing you the number so they can’t let them go stale - although three months is definitely more than lining their pockets. My VoIP provider charges a fixed 99c/month for each unique phone number. 15 € for three months is cheap for personal purposes when you have just a few in the field but isn’t sustainable for large scale deployment. I continue to be impressed by what can be accomplished in the 915 MHz ISM band; it’s not LoRaWan proper but you can achieve non-line-of-sight communication over a hundred and fifty miles (at obviously incredibly slow bitrates) with some signal conditioning magic. It would be amazing to spread a network of these around the world to enable constant low-bitrate communication without a base rate for pure pay-as-you-go options.
True, but that's using SMS for telemetry (totally valid for use cases where power or connectivity are challenges) or remote control, not brokering SMS between another medium; this use case is forwarding SMS messages to Telegram. Maybe if you had a SIM for a geography that wasn't supported by a VoIP provider for programmatic access?
Think of this as much about being a learning exercise as anything else. The project doesn't need to stand on it's own - the creator gets to learn something about both sides.
It's like seeing that M.2 is PCI-E, and wondering if they can plug a regular video card into it. :)
Although for this project, I can construct systems in my head where this would be useful, centered around non-US mobile plans which are "calling party pays", with free on-net SMS. The US is "bill and keep", which makes sending SMS off-net largely the same as on-net from the carrier's point of view.
In "calling party pays", having a device on the same network as the controlled device is about avoiding per-SMS charges.
I imagine they mean this specific use case where you need ip connectivity to Telegram anyway. If it were bridging to something local, it would make more sense.
So instead I have a stack of SIM cards plugged into GSM USB sticks (like this mostly is) and get the inbound messages sent to me via Pushover notification.