Daniel spent an afternoon this week wiring up Twilio for both his home phone and his business line, with Claude acting as the API translator — formatting commands, handling the Twilio console, doing all the plumbing that would've taken months to figure out solo. And he landed on something genuinely elegant. SMS gets converted to email server-side, so two-factor codes just show up in his inbox. He never has to hunt for his phone or debug why Google Messages decided to stop syncing. And that got him thinking — if the setup was this clean, why not go fully SIP? Ditch the carrier entirely, run everything through virtual numbers, just carry a data plan and treat the phone as a dumb router. But he hit three friction points, and he wrote in to ask whether they're actually solvable. Let me read you what he sent.
"It's tempting to go fully SIP — all you need is a data plan, and you can set up whatever virtual numbers and routing you want. But there are a few gotchas that probably explain why most people don't do this, at least yet. These are beyond the complexity of maintaining Twilio, but that may soon be a thing of the past. The first road bump is SMS for two-factor authentication: because virtual numbers have a long history of being exploited by spam operators, compliance burdens are heavy, and many platforms will blacklist known virtual number ranges for authentication. This means if I wanted to use my Twilio 053 number as my sole Israeli number, I could, but would likely run into friction attaching it to, say, my banking app or the government portal — sooner or later, something significant would refuse to take the number."
"The second is domestic calling: for those who still use it, phone providers commonly provide generous terms on domestic calls, something not always the case in SIP-driven systems. The third is a more peripheral concern, but anyone thinking about this will probably think about it sooner or later: whether you can dial special numbers like emergency services. You wouldn't want a phone that couldn't call the police in an emergency. Because companies like Twilio are accustomed to selling to business users, these concerns aren't usually front and center, but the solutions they provide are powerful."
He also asks us to look at whether smaller localized SIP providers might provision numbers that dodge the blacklists, and how to choose a data-only provider for the backbone — ideally with overseas roaming, so the whole thing works wherever there's internet, with the Android device acting as nothing more than a mobile router and a hardware smartphone.
I love it. The phone as a screen with a modem — all the intelligence lives somewhere else. And the setup he built with Claude is the template for how this should work. Agentic AI as the systems integrator, not just the chatbot. But the three friction points he named — they're not bugs in the SIP ecosystem. They're features of how the telephone network evolved, and each one has a different owner. 2FA blacklisting belongs to the platforms. Domestic calling economics belong to the carriers. Emergency services belongs to regulators. You can't solve all three with a better Twilio configuration.
Which is the thing that makes this conversation worth having. If the problems were technical, someone would've shipped a fix by now. The fact that they've persisted this long tells you they're structural.
Let's start with the blacklisting problem, because it's the one that breaks the most things for the most people. When Daniel's bank sends a 2FA code, it's not just sending an SMS. It's doing a lookup on the number — what range does it belong to, what carrier issued it, is it a mobile number or a landline or a VoIP assignment. And virtual number ranges, like the 053 block Twilio uses in Israel, have a documented history of being exploited by spam operations. Not a few bad actors — a sustained, multi-year pattern of abuse. So platforms built blocklists.
And the blocklists aren't subtle. They're not doing probabilistic scoring. It's a binary check — is this number in a range we've flagged as virtual, yes or no. If yes, the SMS never goes out.
Right. And from the platform's perspective, this is rational. A bank is optimizing for fraud prevention, not for Daniel's convenience. The cost of one compromised account dwarfs the cost of annoying a few power users who want to use SIP numbers for 2FA. The math doesn't even wobble.
So when people blame Twilio for this — and they do — they're pointing at the wrong layer.
Completely. Twilio doesn't decide what numbers get blocked. The receiving platforms do. Twilio can register you in their A2P 10DLC system — that's Application-to-Person 10-Digit Long Code, the compliance framework for business messaging in the US — but that system assumes you're a brand. It wants your business name, your tax ID, your campaign description. It's not designed for an individual who just wants a personal number that receives 2FA codes. The Trust Hub requirements are built around enterprise use cases. You can try to squeeze through, but you're contorting a business compliance framework to fit a consumer need, and the seams show.
And even if you get through A2P 10DLC registration, that doesn't guarantee the platforms will unblock you. The blocklists are maintained independently. You're checking a box that might help, but it's not a guarantee.
No, and this is the cat-and-mouse nature of the whole thing. You might find a localized SIP provider that provisions from a range that isn't on the major blocklists yet. A smaller Israeli provider with a batch of 053 numbers that haven't been flagged. That works — until it doesn't. The blocklists update. The platforms catch on. You wake up one morning and your banking 2FA codes have stopped arriving, and you're locked out of your account while you scramble to add a backup number.
Which brings us to the server-side SMS-to-email conversion Daniel built, which is... honestly, it's the right architecture even if 2FA weren't a problem.
Explain that, because I think people hear SMS-to-email and think it's a kludge.
It's the opposite of a kludge. The fundamental problem with SMS is that it's tied to a physical device. Your phone is the recipient, so if your phone is dead or lost or in another room, you don't get the message. And the Google Messages sync workaround — where it tries to bridge SMS to your browser — is a debugging nightmare. It breaks constantly. People spend hours troubleshooting why their web client stopped syncing. Daniel's approach sidesteps all of that. The SMS arrives at Twilio, Twilio fires a webhook, the webhook drops it in email. Now your 2FA codes live in the same place as everything else you need to get things done. It's phone-optional by design.
And it's auditable. Email is searchable, archivable, available on every device you own. You're not squinting at a notification that disappears after three seconds. The code is just... there, in your inbox, with a timestamp. I've been saying for years that SMS is a terrible substrate for authentication, but if you're stuck with it, routing it to email is the least-bad way to consume it.
Daniel's setup doesn't solve the blacklisting problem — if the platform refuses to send to a virtual number, it refuses, end of story. But for the platforms that do send, the email conversion pattern is strictly better than receiving it on a handset.
Let's talk about the second friction point, because domestic calling economics are weird in a way that most people never think about. When you pay your traditional carrier forty shekels a month or whatever, you get — what — unlimited domestic minutes? Thousands of minutes you'll never use. And that seems normal. But it's not normal. It's cross-subsidized.
By international rates and data overage charges.
The carrier makes its margin on the things that cost them almost nothing to provide — international termination, data beyond your cap, roaming. The domestic minutes are the loss leader. They're cheap to deliver because the carrier owns the infrastructure end-to-end, and they're bundled generously to make the plan feel like good value. SIP providers don't have that luxury. They don't have international roaming revenue or data overage fees to subsidize domestic calling. Their only revenue stream is the call itself — per-minute or per-channel pricing. So of course domestic calls cost more on SIP. It's not that SIP is expensive. It's that traditional carriers are running a bundling strategy that hides the real cost allocation.
So if you're someone who still makes a lot of domestic phone calls — and those people exist, even if the trend line points toward zero — the SIP economics might actually be worse than a traditional plan.
For heavy domestic callers, yes. The break-even depends on your calling patterns. If you make five minutes of domestic calls a month and everything else is data, SIP wins easily. If you're on the phone with your mother for two hours every Sunday, the traditional carrier's bundled minutes start looking pretty good.
And that's before we get to the third friction point, which is the one that actually matters in a way the other two don't.
Emergency services. And I want to be careful here, because this isn't a theoretical concern. It's not "wouldn't it be nice if 911 worked." It's "if someone in your house is having a medical emergency, can the phone connect to the dispatcher and can the dispatcher locate you."
That second part is where VoIP falls down.
The calling part actually works. VoIP providers in most jurisdictions are required to route emergency calls. Twilio has E911 support. The call will connect. The problem is location data. When you dial emergency services from a traditional mobile phone, the carrier triangulates your position from cell towers and sends that to the dispatcher. It's not perfect, but it's fast and it's automatic. With a VoIP phone, the location is whatever you registered when you set up the service. If you registered your home address and you're calling from home, great. If you're calling from a coffee shop three neighborhoods away, the dispatcher has no idea.
And the registered address goes stale. People move, people travel, people forget to update their E911 registration. The traditional carrier system is continuously updated by virtue of the phone moving through the network. The VoIP system is a static database entry that's only as current as the last time you thought to change it.
This is the asymmetry Daniel mentioned. Twilio sells to businesses. A business with a SIP trunk knows exactly where their office is. The address doesn't change. The E911 registration is set once and forgotten. The consumer use case — I might be anywhere, locate me — is not what the system was designed for.
So if you go fully SIP, you're accepting a real degradation in emergency response capability. And it's the kind of thing where you won't notice the problem until the worst possible moment.
Which is why I think the right answer here is not "SIP or carrier" but "SIP and carrier." Keep a cheap traditional line for the things only a traditional line can do well — 2FA delivery and emergency calling — and route everything else through SIP. It's the dual-SIM mindset applied to telephony architecture.
That's the pragmatic answer. And it's not a compromise, really. It's acknowledging that different networks have different strengths. The traditional carrier is optimized for ubiquity and reliability at the cost of flexibility. SIP is optimized for programmability and cost at the cost of... well, ubiquity and reliability in the specific cases we just talked about. You don't have to pick one.
The question then becomes: how do you choose the data-only backbone that makes the SIP half of this work? Because not all data plans are created equal, and the differences matter a lot when you're running voice traffic.
Walk me through the criteria.
First and most important: does the provider allow VoIP traffic at all? Some data-only plans explicitly throttle or block SIP signaling. They detect the traffic pattern and degrade it, or they write it into the terms of service that VoIP is prohibited. You have to check before you commit, because finding out your calls drop after thirty seconds when you're already ported over is... not great.
And how do you check? It's not like the marketing page says "we block VoIP."
You read the acceptable use policy, you search forums, you test. Get a prepaid SIM from the provider you're considering, set up a SIP client, make some calls. If the call quality is consistently garbage while data speeds look fine, they're probably doing traffic shaping on SIP packets. Walk away.
Second criterion?
eSIM support for overseas roaming. Daniel specifically mentioned wanting to use this while traveling. If you're landing in a new country and need to get online, eSIM provisioning means you can buy a data plan before you even leave the airport. No physical SIM to swap, no shop to find. The provider needs to support eSIM and have roaming agreements in the places you actually go.
And some of the data-only providers that look great on paper have terrible roaming coverage. They're optimized for domestic use.
The third thing is data pricing structure. Some providers give you a flat monthly bucket. Others do pay-per-gigabyte. Voice over SIP isn't particularly bandwidth-hungry — we're talking about sixty to a hundred kilobits per second for a decent codec — but it adds up if you're on the phone a lot. You want to do the math on your expected calling volume and see which pricing model wins.
And call quality isn't just about bandwidth. It's about latency and jitter.
Right. You can have a hundred-megabit connection and still get terrible call quality if the latency is spiking. SIP is real-time traffic. Packets arriving out of order or two hundred milliseconds late make the call sound like a walkie-talkie in a tunnel. The only way to know is to test on the actual device, on the actual network, at the times of day you'll actually be using it.
So the provider selection process is: verify VoIP isn't blocked, check eSIM and roaming support, run the numbers on data pricing, and test call quality in real conditions. That's four steps, none of which are on the provider's comparison chart.
And that's before you even get to number provisioning. Which brings us back to the localized SIP provider question Daniel raised. Twilio is the eight-hundred-pound gorilla, but there's a whole ecosystem of smaller players. Regional SIP providers that provision numbers from local ranges, often with less baggage on the blocklists. In Israel, for example, there are providers that can give you a 053 number that isn't from a range Twilio has burned through.
But you said it yourself — that's a temporary advantage.
It's a cat-and-mouse game. Today the number works. Tomorrow the blocklist updates and it doesn't. If you're relying on that number for 2FA, you need a backup plan. Which is exactly why the hybrid approach makes sense. Keep the traditional carrier number for the things that can't tolerate blocklist roulette. Use the SIP number for everything else.
And the "everything else" is actually most of what a phone number does in 2026. Voice calls, messaging that isn't 2FA, inbound routing, call forwarding, voicemail-to-email — all of that works beautifully on SIP. The only things that break are the two we've identified: 2FA from paranoid platforms, and emergency services location.
I want to zoom out for a second and talk about the thing that makes this whole conversation different than it would've been even two years ago. Daniel set this up in an afternoon. With Claude. He didn't read the Twilio API docs. He didn't learn SIP signaling. He described what he wanted, Claude formatted the API calls, and it worked. That's the force multiplier he mentioned.
And it's not just about setup speed. It's about maintenance. The reason most people don't run their own telephony infrastructure isn't that they can't figure out the initial configuration. It's that they don't want to be on call when it breaks. Agentic AI changes that calculus. If Claude can monitor the Twilio console, detect when a webhook is failing, and fix it or alert you — suddenly the maintenance burden drops from "I need to be a part-time systems administrator" to "I need to read a notification and approve a fix."
That's the shift. The barrier to running your own telephony has never been the technology. SIP is decades old. The barrier has been the ongoing operational cost of keeping it running. AI collapses that cost.
But it doesn't collapse the structural problems. Better tooling doesn't make banks unblock virtual numbers. Better tooling doesn't give emergency dispatchers your real-time location. Those are problems of policy and market structure, not problems of configuration complexity.
Which is why I think the future of this is not "everyone runs their own SIP infrastructure." It's "the people who want to can, and the number of people who want to will grow as the maintenance burden shrinks, but the structural friction points will keep it from going mainstream until they're addressed by regulation or market pressure."
So let's talk about whether regulation might actually address them.
On the 2FA front, the trend is actually away from SMS entirely. The security community has been screaming about SIM swapping and SMS interception for years. The direction of travel is toward passkeys, authenticator apps, hardware tokens. If SMS 2FA becomes obsolete, the blacklisting problem becomes irrelevant for authentication. You'd still have the issue for any service that sends you an SMS for non-authentication reasons — appointment reminders, delivery notifications — but those aren't mission-critical in the same way.
And on emergency services?
That's harder. The location problem with VoIP is fundamentally about the mismatch between a static registration and a mobile user. The fix would require either a regulatory mandate that VoIP providers implement real-time location — which is technically difficult and expensive — or a shift toward emergency calling that doesn't depend on the carrier network at all. Some jurisdictions are experimenting with emergency services reachable via IP-based channels, but it's early, and it's fragmented.
The realistic near-term path is the hybrid one. Traditional number for the things that break, SIP for everything else, AI handling the operations.
A data-only plan that you've actually tested. I can't emphasize that enough. The number of people who sign up for a data plan, port everything over, and then discover their calls sound like they're underwater because the provider is shaping SIP traffic — it's not small.
What about the Android-as-hardware-router piece? Daniel mentioned treating the phone as just a mobile router and a hardware smartphone. That's a specific vision.
It's the logical endpoint of this architecture. If all your telephony intelligence lives in the cloud — your routing rules, your voicemail, your SMS-to-email conversion — then the handset doesn't need to be smart. It needs a data connection, a speaker, a microphone, and a SIP client. Everything else is server-side. The phone becomes a thin client for telephony.
What breaks when you do that?
Three things. Battery life — maintaining a constant data connection for SIP signaling drains faster than traditional cellular standby. Latency — every call is going through an extra hop to your SIP server and back, which adds maybe fifty to a hundred milliseconds if your server is well-located. And call quality under poor network conditions — traditional cellular calls are optimized for degraded connections in ways that SIP over a generic data connection isn't.
You're trading flexibility for reliability, again.
You're always trading something. The question is whether the trade is worth it for your use case. For Daniel, who's built this elegant server-side setup and mostly communicates via data channels anyway, the trade probably makes sense. For someone who just wants their phone to work when they dial a number, the traditional carrier is still the right answer.
Let's talk about the smaller SIP providers for a minute. You mentioned that localized players might provision numbers from ranges that aren't on the major blocklists. How would someone actually find and evaluate those?
It's a fragmented market. You're looking for providers that serve a specific region or country, not the global players. In Israel, there are several. The evaluation criteria are: what number ranges do they provision from, what's their per-minute or per-channel pricing for domestic calls, do they support the codec you want to use, and — crucially — what's their track record on number portability. If you ever want to leave, can you take your number with you?
Number portability is the thing nobody thinks about until they need it.
It's uneven across SIP providers. Some support it fully. Some make it painful. Some don't support it at all, and you're effectively renting the number for as long as you stay with them. If you're building a personal telephony system that you want to keep for years, number portability is non-negotiable.
The provider selection checklist is getting long. VoIP traffic allowed. eSIM and roaming support. Data pricing that matches your calling patterns. Tested call quality. Number portability. And for the number itself, a range that isn't already burned on the major blocklists.
That's the list. And notice that price isn't even the top criterion. The cheapest provider that blocks VoIP or can't port your number is a false economy.
One thing we haven't touched on is the SMS-to-email conversion pattern more broadly. Daniel built it for 2FA codes, but it's useful for anything that arrives via SMS. Appointment confirmations, delivery updates, bank alerts. All of it lands in email, searchable and archived, instead of disappearing into the black hole of a messaging app.
It's a pattern that works even if you're not running your own SIP infrastructure. You can do this with a Twilio number right now, today, without porting your primary number. Set up a virtual number, point SMS to email, and start giving that number to services that only need to reach you via text. Your primary number stays with the carrier for the things that need it.
That's actually the entry-level version of this whole architecture. You don't have to go fully SIP to get value from the pattern. Just the SMS-to-email conversion alone solves the "where's my phone" problem for a whole category of messages.
It's the kind of thing that takes about twenty minutes to set up with Claude or any competent AI assistant. The barrier is not technical. It's awareness that the pattern exists.
Which brings us to the actionable takeaways. If someone's listening and wants to move in this direction, what should they actually do?
Step one: don't port your primary number. Keep a cheap traditional carrier line for 2FA and emergency services. You can get a bare-minimum plan for very little money in most countries. That's your safety net.
Step two: pick a data-only provider for the SIP backbone, but verify they don't throttle VoIP, check eSIM support for travel, and test call quality on your actual device before committing to anything long-term.
Step three: use agentic AI as your systems integrator. The Daniel-and-Claude pattern — describe what you want, let the AI format the API calls and configure the webhooks — is the template. You don't need to read the Twilio docs. You need to know what you want the system to do and be able to describe it clearly.
Step four: if you need a number that platforms won't blacklist, look for localized SIP providers that provision from regional ranges rather than the bulk-assigned virtual ranges the big players use. But expect that advantage to be temporary. Have a fallback.
Step five, which is really step zero: route your SMS to email. Even if you do nothing else, this one change eliminates the "where's my phone" problem for every service that sends you text messages. It's the highest-leverage move in the whole playbook.
The steelman against all of this is pretty straightforward. You're adding complexity to a system that currently works. Your carrier phone already makes calls, receives 2FA codes, and connects to emergency services. The SIP setup is cooler, more flexible, and potentially cheaper — but it introduces failure modes that don't exist in the carrier model. If you miss a 2FA code because a blocklist updated, or if you can't reach emergency services with accurate location data, the cost of those failures is extremely high. For most people, the marginal benefit of SIP telephony doesn't justify the marginal risk.
That's fair. And I'd say the calculus changes depending on who you are. If you're someone who lives in your email, travels frequently, and is comfortable managing technical infrastructure — or comfortable having an AI manage it for you — the benefits probably outweigh the risks, especially with the hybrid approach. If you're someone who just wants the phone to work and never thinks about it, the traditional carrier is still the right answer. The point is that the option exists now in a way it didn't before, because the setup and maintenance costs have collapsed.
The open question I keep coming back to is whether the structural problems — the blacklisting, the emergency services location — will eventually be solved by regulation, or whether SIP will remain a power-user tool indefinitely. The technology has been ready for years. The friction is entirely in the governance layer.
The governance layer moves slowly. But the number of people who can run their own telephony is going to grow regardless, because AI is eating the operational complexity. The question isn't whether SIP telephony is possible — it's been possible. The question is whether it's accessible. And the answer is shifting from "only if you're a telecom engineer" to "if you can describe what you want to Claude."
If you've built your own SIP setup, or found a provider that dodges the blacklists, we want to hear about it. Reviews at my weird prompts dot com, or email the show at show at my weird prompts dot com.
Thanks to Hilbert Flumingtop for producing.
This has been My Weird Prompts. We'll be back soon.
