At my previous company we regularly had need for shared numbers that callers would not know were shared[^1]. We tried using Twilio/etc for this, and it sometimes worked, but we ran into issues in some cases where the systems we were using the phones with banned the use of virtual numbers. I don't know how these systems determine that numbers are virtual, but doing so appears trivial and mostly correct with US/UK numbers.
So, question for Cophone, do these phones have a "real" number, or a virtual number? And, perhaps a follow-up, are these VMs with a virtual network stack, or are they physical devices with a real physical SIM/eSIM/modem with screen sharing?
[^1]: This sounds nefarious, but we essentially partnered with a lot of retailers, and needed to interact with their customer service and operations departments who were a long way organisationally from those who signed the partnership contracts, and with little scope for deeper integrations. The lowest friction option was to pretend to be a completely normal customer rather than explain our special case setup every time. Fun fact, this is why we used a gender-neutral name on the postal address, so that anyone from our company could call up and claim to be the recipient.
Cophone has virtual phone numbers. This is - one of - the reasons why some services like WhatsApp won't even sent you a text message, although it is possible to receive SMSes.
Cophones are VMs with virtual stacks.
This is a very painful problem to have. Receiving 2FA SMS programmatically is surprisingly difficult because of all the safeguards against scammers, even if your usage is legitimate. As you say, normal providers like Twilio are blacklisted so they are unreliable at best.
https://clerk.chat offers the ability to receive SMS on genuine non-VOIP numbers. They are ridiculously bad at pretty much everything – terrible communication, terrible customer support, terrible reliability, terrible UX, etc. – but they can actually do this where other VOIP-based providers like Twilio can’t. They may be your least worst option.
Another option that’s available is to set up an Android phone with https://ifttt.com and a genuine phone plan. Then get IFTTT to forward any SMS it receives to whatever service you need. There are open-source apps that do similar things as well – the sibling comment mentions a similar solution. It’s a pain to maintain though.
I’d love it if there were a better solution out there, but I haven’t found one yet. Basically the only thing I need is a genuine phone number that will forward SMS on to a web hook.
I was feeling the pain of 2FA and 2FA SMS for too long as well and thus build a product, Daito (https://www.daito.io), around the concept of shared 2FA as a service for companies and teams.
In addition to TOTP 2FA (our main service), we also started to offer 2FA via SMS via _physical SIM cards_ hosted in a data center in Germany (we are a German company) as every other solution we tried (Twilio + seemingly 50+ other, non-physical SIM card-based, options by now) was simply not working reliable.
We have been talking to Twilio et al and a lot of telcos, carriers, ISP, providers and seemingly everyone in between: there simply is no easy and reliable solution to this. :(
In our tests the best reliability we could reach for national and international senders&receivers on VOIP-based numbers was only every around 80%. We are still looking for other options, and specially non-VOIP options that are actually affordable, but so far we can only offer a German number (+49). This number however, is way, way more reliable than anything we have seen from others.
We currently support forwarding SMS to an email address, and webhooks for incoming notifications are in the works.
Anytime I think about these issues and this model I always wonder:
Can you get a cellular connection over a wire?
That is, instead of having 500 little radios connecting to one or two nearby towers, can you negotiate a direct connection to the tower and use the entire cellular stack except for the PHY ?
This is pretty much what we have been asking every supplier (telcos etc) over the past 2 years. The answer is always no. And if it is a "Maybe, I think so" it turns into a "no" weeks or months later when have finished digging through the corporate hierarchy.
The only solution that seems to work is old school SIM card hosting in a SIM bank. In some narrow cases, e.g. sender is in the country and receiver is in the same country, you might have pretty good (95%+) reliability of receiving critical SMS (A2P traffic), but still far away from what you'd call reliable.
There exists FOSS that could do this too (start with "osmocombb").
But the real problem here isn't technical, it's a business/legal issue: the carriers and their regulators are trying to minimize (or at least, reduce) the ability for bad actors to operate large numbers of "cell phones" at minimal cost/complexity.
So everything that could be done (technically) to make this work is, in practice, prevented by those business/legal considerations.
Open source stacks are already or basically on the verge of being obsolete in most of the world's telco networks if you want to actually use them. They are incredibly cool and a huge undertaking but no one is saying they are practical for actual usage, and that's ignoring the clear illegality of broadcasting with such firmware.
Osmocom and others like FreeCalypso only work on very old devices with TI Calypso chipsets.
But in this context, I think the supported devices don't matter: the idea is to interface with one-or-more telcos directly at a higher level of the 3GPP stack?
You won't need the air interface - hypothetically just an appropriately rooted femtocell, carrier HSS/HLR/MME that can authn/authz you, and Asterisk server that is secure. Or a flooded Nokia Flexi on a rack shelf, I mean, they look cool, don't they...
We are hugely frustrated with providers insisting on SMS as a 2nd factor for commercial use because we value employee PII and feel they should not need to seed data brokers just do log into enterprise platforms.
We are looking for a solution at scale for SMS 2FA that, according to the national number registry and KYC/anti-fraud checks, is a "real" mobile SMS number.
We've found hardware devices that take from 4 to 32 SIM cards and are heading in that direction which seems ... nuts.
But, we value employee privacy and these days when even your accounting firms' privacy policy say they're selling your contact info upstream, we want to give employees a way to log in without compromising themselves.
Also, to anyone here running a B2B SaaS that offers TOTP instead of SMS, thank you.
There are lots of patchy solutions, but the issue we had was that we ultimately needed SMS and calls, inbound and outbound. 2FA only got us so far and wasn't usually the problem, more common was needing to call a company from the number on our account, or receive a callback from the company's support team.
Our ops team had a physical phone for this, but it lived in a desk drawer somewhere and that didn't scale as the team grew and became distributed.
I think what Twilio or others could do is offer non-VOIP, genuine, etc, numbers on the condition that the company and use-case is vetted and the usage is audited. A little like getting an EV SSL certificate, you'd give valid points of contact, undergo basic vetting of the company, perhaps even limit the count of numbers you can contact and require human review for increasing that quota.
Maybe this would be too hard, arguably EV SSL failed because it wasn't strict enough. Or maybe I'm misunderstanding why VOIP/automated numbers are so easy to identify, I assumed it was because they were higher risk in this way and that this sort of auditing would circumvent the need for that, but maybe there's another reason.
I’m surprised twilio doesn’t offer a “sim hotel” where you just mail in your actual SIM card and then interface with it over their api…
It solves all of their terrible new a2p 10dlc issues and would be genuinely useful.
Actually, there are all kinds of ways to solve their 10dlc problems and make their platform useful (again) for something other than spam but … that would be a boring and useful service and not customer engagement at scale.
SIM banks used to be a thing, but they get less common and common every year.
Why they are dying out? Because they are not that easy to source, maintain, scale or achieve super high reliability with them. Also, hard to offer a high availability option when the phone network only (well, in most cases) accepts one device per phone number.
Edito: Additionally, important to note is that most SIM cards can only be used for a prolonged time in that providers phone network. You e.g. can not buy US SIMS, ship them to the EU and host them there. T-Mobile US (and others) cut you off after (usually) 2 months of roaming.
> Also, hard to offer a high availability option when the phone network only (well, in most cases) accepts one device per phone number.
1. I guess it depends on your providers/region. From all three German mobile network providers (Telekom, Vodafone, o2) you can get up to three SIM-Cards for the same number.
2. The VoIP provider Sipgate (sorry again German) gives you as much SIM-Cards and eSIMs as you like (In exchange for money of course). You can route mobile as well as land line numbers to a VoIP-Phone, -Client or mobile phones. They can all ring in parallel.
3. Many years ago, I saw a presentation on a CCC event. (Sadly I can't find a video of it just now.) It was from a guy who documented how he became a mobile provider. He wasn't just reselling, because his numbers terminated in his own Asterisk server! So maybe, people looking for the best solution, should look into how to become a virtual mobile provider.
I suspect they’re still used for outbound scam calls/texts (and maybe inbound too), and probably gray-market voip-pstn interfaces in countries that make int’l voip interchange expensive.
Some cool stuff on aliexpress with 128 SIM card slots and 8 or 16 gsm radios where you can program your choice of imei.
As a Canadian with crappy cellular coverage, I’ve dreamt of having a couple French SIM cards that I could mail to France every so often so it looked while I wasn’t 100% roaming just to have a cheap unlimited data plan with cheaper int’l calling.
This solves 2FA codes, which was indeed part of our problem, but it doesn't solve incoming/outgoing calls that ideally needed to be on the same number as well for when we dealt with humans.
This is probably possible to do, but probably hard to get right, and still requires having a device reliably available to receive calls, and has limited scale (what happens if there are multiple calls at the same time?). This is why it would have been great to be able to buy this as a service.
How can this be determined? I'd imagine that only those with direct access to the "which number belongs to which provider" database could see that a given number belongs to $comapniesKnownToOfferTraditionalPhysicalService versus $comapnyKnownToOnlyDoVOIP can know this for sure? It it just that some companies with this access are selling a "we'll look that up for you" service? Or is it simpler and i'm just over thinking it?
If the owner of the number is a customer of a different telco (not Twilio), by what mechanism can Twilio determine whether the it's a physical (sim/esim/landline) or virtual number?
Sure, some operators operate only physical or only virtual, but others (like Google) operate both.
This isn’t something casually identified with flashy software solutions or APIs, it’s more of a relationships with carriers and other companies in the telco space sorta thing. It gets even more fun when you start looking in to MO and MT on the SMPP side of things.
Blocks of numbers moving from mobile to voip, sometimes things aren’t instantly updated in databases and might take a little bit before that eventually happens.
So, question for Cophone, do these phones have a "real" number, or a virtual number? And, perhaps a follow-up, are these VMs with a virtual network stack, or are they physical devices with a real physical SIM/eSIM/modem with screen sharing?
[^1]: This sounds nefarious, but we essentially partnered with a lot of retailers, and needed to interact with their customer service and operations departments who were a long way organisationally from those who signed the partnership contracts, and with little scope for deeper integrations. The lowest friction option was to pretend to be a completely normal customer rather than explain our special case setup every time. Fun fact, this is why we used a gender-neutral name on the postal address, so that anyone from our company could call up and claim to be the recipient.