So the bonding layer is solved. The question is whether the phone will actually hand it two live connections, and that starts with what dual SIM dual active even means.
Right, and this is where the marketing language has done real damage, because almost nobody selling a dual SIM phone is selling you what Daniel is describing.
Daniel's got a whole thing about this. He wrote in with a prompt that's basically a technical walkthrough he wants us to do out loud. His framing is this. Bonding two connections normally needs a remote server somewhere on the far end, which is why it's awkward on any off-the-shelf system. But if you had a dual SIM phone and two independent data plans, in theory you could do the whole thing on the handset itself. Not a mobile router in your bag that the phone tethers to. Everything on the phone.
Which is the hard version of the problem, yes.
He says the requirement straddles hardware and software, and he wants us to use Android as the hypothetical. First thing you'd need is DSDA, dual SIM dual active. There are countless Androids that do dual SIM, some do more than two. But the usual gotcha is that Android doesn't really support simultaneous network connections, on one modem or several. So it's both halves. And then his interesting claim, the one I want to test: he thinks the easy part is the bonding itself. He names Speedify specifically, says it's a fantastic product, and he believes that if you can get the handset to hold two independent data connections, Speedify would work out of the box even on a smartphone. So the constraint is almost entirely the hardware and the Android configuration.
And then his two closing questions.
Two closing questions. Are there any out-of-the-box phones that ship with true dual SIM networking capability, primed for this use case? And if not, could you cobble together components, or even make your own phone?
It is. So let's take him seriously. Start with what bonding actually is, because there's a version of this conversation where people think it means something it doesn't.
Bonding, precisely, is aggregating multiple independent network paths into one logical link. You take two connections, you split packets across both of them, and at the far end something reassembles them in order. That's it. That's the whole trick.
And the far end is not optional.
It's structurally required, and this is the part people skip. The receiving endpoint has to hold the other half of the tunnel. It has to reorder packets that arrive out of sequence, because they will arrive out of sequence, the two paths have different latencies and that difference wanders. And it has to present a single IP address to the outside world. Without that anchor on the far side, you don't have one connection. You have two connections, which is a different thing.
Two connections is what you already have if you're holding two phones.
And the confusion is that people hear "bonding" and think it covers three different things. Failover is one link active and the other sitting idle until the first one drops. Load balancing is flows pinned to links, so your video call goes down one path and your file download goes down the other, but no single flow is ever split. Neither of those gives you summed throughput. Neither gives you the seamless handoff where you can pull one link out and the session doesn't notice.
Only per-packet aggregation does that.
Only per-packet aggregation, and that's the thing that needs the server.
So the episode's tension, stated once: the bonding software is a solved problem. The phone is not.
The phone is very much not.
So walk me through DSDA, because I want the distinction sharp. Most people who own a dual SIM phone think they already have this.
They have dual SIM dual standby. DSDS. And standby is the honest word in that acronym. What it means is that the two SIMs share a single modem and radio chain. One subscription can hold an active data session at a time. The other one is parked on a paging channel, listening for incoming calls and messages, but not doing data.
So the second SIM is awake, it's just not working.
It's on call. It's not on shift. And you've seen this behavior. You go into settings, you pick which SIM carries data, and the other one goes quiet for data while still receiving calls. That's DSDS doing exactly what it was designed to do.
And DSDA is different hardware.
Different. Two independent transmit and receive chains. Two simultaneous active connections. Not one radio time-slicing between two subscriptions, but two radios, or at minimum two full signal chains, running at once. That's a materially different board design. It costs silicon, it costs board space, it costs antenna complexity, and it costs battery.
Which answers the question of why it isn't everywhere.
It's a power and cost decision, not an oversight. A second always-on radio chain is expensive in every dimension a phone manufacturer cares about. And the use case the industry was designing for was voice reachability. You want to be reachable on your work number and your personal number. You do not need both of them pulling down data at the same time to be reachable. So standby is the compromise that got settled on, and it's a perfectly rational one.
Until someone wants to bond two cellular links.
Until then, yes. And here's where the hardware half ends and the software half starts, and the software half is worse.
Lay it out.
Android's connectivity stack is built around a single default network. One route for general traffic. There are exceptions, per-app binding, per-feature binding, but the architecture assumes there is one network that general traffic goes out on. There is no first-class concept of two simultaneously active default data paths being aggregated into one.
So even if the silicon is there, the OS doesn't know what to do with it.
The mechanism is worth naming because it explains everything downstream. You have ConnectivityService, which is the system service that tracks networks. Each network gets a NetworkAgent, and each gets a netId, a numeric identifier. Sockets get bound to a netId. Routing rules get written per netId. So the OS absolutely can have multiple networks registered at once. That part works.
Then where does it break?
It breaks on aggregation. Apps can be bound to a specific network. You can say, this app goes out over the cellular network, that app goes out over Wi-Fi. But the OS does not present an aggregated interface to unmodified apps. There's no virtual interface that says, here is the sum of your two cellular links, send your packets here and we'll sort out which one each packet goes down. That concept doesn't exist in the stack.
So the closest Android gets is per-app network binding.
Which is useful, and it is not bonding. It's assignment. You're telling a flow which road to take. You're not splitting a flow across two roads and reassembling it at the other end.
And the failover behavior is real, Android does do that.
It does. If your Wi-Fi drops, Android will move you to cellular. But that's one path at a time, sequentially. It's not two paths live at once. The OS will happily let you choose which SIM carries data, and it will fail over between them. It will not run both as live data paths simultaneously for general traffic.
So Daniel's framing is right, and I want to say that plainly because it's the spine of the whole episode. You need DSDA silicon and an OS willing to keep both paths up, and the second one is the harder half.
The second one is much harder. The silicon is a bill of materials problem. The OS is an architecture problem, and architecture problems in a platform with billions of users move at the speed of a glacier.
There's a nice detail in the history here, which is that the stack was designed when one active data path was simply the reality. There was no second path to aggregate. The assumption wasn't wrong, it was just early.
And assumptions that were correct when they were made calcify. That's not a criticism of anybody, it's just how platforms age. The single-default-network model is load-bearing for a lot of things, and changing it means touching routing, means touching the permission model, means touching how apps are told what network they're on. It's not a patch.
So the OS won't do it. But Daniel's claim is that if you could get two live connections, Speedify would just work. Let's test that, because I think he's more right than people would expect.
He's right, and Speedify's own support documentation addresses the dual SIM question directly. The answer is essentially yes. If the phone will actually keep two cellular data connections live at the same time, Speedify can bond them. The bonding layer is not the blocker.
Say what Speedify actually needs from the OS.
Two usable network interfaces with independent routes, and the ability to bind its own traffic to each. That's the requirement. It needs to be able to say, this packet goes out interface one, that packet goes out interface two, and it needs both interfaces to be live so the packets actually go somewhere. On a handset where the OS only ever exposes one active cellular data path, there is nothing to bond. Not because the software can't do it, but because there's only one road.
And here's the contrast that proves the point. Speedify does support bonding Wi-Fi and cellular on Android.
It does, and that's the cleanest proof in the whole episode. Wi-Fi and cellular are two separate interfaces that the OS is willing to run concurrently. Android has no problem with you being on Wi-Fi and having cellular up at the same time. So Speedify bonds them, and it works. Which isolates the cellular-to-cellular case as the specific problem. It's not bonding that Android objects to. It's two cellular data paths.
Because Wi-Fi is a different interface with a different netId and the OS treats it as a separate network, no problem. Two cellular subscriptions on one modem chain, and the OS has no second active path to hand over.
That's exactly the shape of it. The constraint is the cellular-cellular case specifically.
So the out-of-the-box phone question. Daniel asks whether anything ships with true dual SIM networking primed for this. What's the honest answer?
The honest answer is no, not as a marketed feature, and the marketing language has made this worse rather than better. "Dual SIM dual active" has been used loosely enough in spec sheets and reviews that a buyer should not assume it means two concurrent data sessions. Sometimes it means two concurrent voice standby paths. Sometimes it means the phone can receive a call on either SIM while the other is on a call. That's a real capability and it is not what Daniel wants.
A phone can honestly claim DSDA and still not give you two live data paths.
It can, and that's the trap. The term describes a family of behaviors, not one spec. If you want to know whether a specific handset will hold two cellular data connections simultaneously, the spec sheet will not tell you. You'd have to test it, or find someone who has.
Which is a miserable answer for someone who just wants to buy the thing.
It is. And I'd add, even on a handset that does hold two active cellular connections, you're still relying on the OS layer to keep both up and expose them. So you've got two gates to get through, and the second one is the one that usually closes.
The DIY path. Daniel asks whether you could cobble together components. Let's walk it honestly, because I think the answer is yes, and I think the answer also tells you why nobody sells it.
The DIY build has three parts. You need a platform with two independent cellular data paths. You need an OS or firmware layer that will keep both up and let you control the routing table. And you need a bonding client on top. The third part is the easy one. It's the first two that decide whether the project works.
The second one is where a stock handset fails.
A stock Android handset fails at layer two. You don't control the routing table in any meaningful sense. You can't tell the OS to keep both cellular paths live and route packets across them. So the DIY path almost immediately means leaving stock Android.
Which means going to something like a single-board computer with two cellular modems, or a Linux-based stack where you own the routing table.
That gets you much closer. Much closer. A small computer with two modems and a Linux stack you control will do this. You write the routing rules, you run the bonding client, you're done. The problem is you've now built a device rather than bought one, and you've left the phone form factor behind.
The "make your own phone" branch is real, it's just that the thing you make is not a phone.
It's a box with a battery that can make calls if you bolt a voice stack onto it. Which is not nothing. But it's a project, not a product.
This is the second-order point I want to land, because I think it's the actual answer to Daniel's question. The reason this doesn't exist as a product is not technical impossibility. Every piece exists. The reason is that the market for concurrent dual-cellular data on one handset is tiny, and the cost is a second always-on radio chain in every unit sold.
You'd be charging every customer for a capability almost none of them want, to serve the few who do. That's the calculation, and it's a losing one for a mass-market handset.
Which is why the capability shows up in the places where the calculation flips. Mobile routers, bonding appliances, field kits. Things sold to people who specifically need this.
Where the buyer is already paying for the specialized box, so the second radio chain isn't overhead, it's the product.
There's a version of this where the phone becomes the box eventually, because phones keep adding radios. More modem chains, more independent paths. And then the OS-level single-default-network assumption becomes the last thing standing in the way.
That's the right way to see it. The silicon trend is toward more independent radios, not fewer. The software assumption is the lagging piece.
This is not a new problem. People have been bonding links in the field for a long time.
Hilbert: The box was about the size of a car battery and it weighed more than one. We'd mount it in the crawlspace next to the electrical panel, run the DSL pair in on one side, the cellular antenna out through a hole we drilled in the rim joist, and the customer's router plugged into the front. Two lights on the front, one for each link. When both were green you knew you were fine.
How many of these did you install?
Hilbert: I did forty-one in one summer. The bonding itself never failed. What failed was the reordering. If one link's latency drifted, and cellular drifts constantly, the box would hold packets waiting for the slow one to catch up, and you'd see it on a video call as a stutter. Not a drop. A stutter. Every four or five seconds the picture would freeze for maybe three hundred milliseconds and then jump forward. The customer would call and say the internet was broken. The internet was working perfectly. The box was doing exactly what it was supposed to do.
That's the reordering buffer doing its job badly.
Hilbert: It was doing its job correctly. The buffer was too small. There was a setting for it in the config file and the manual said to leave it at default unless you knew what you were doing. I did not know what I was doing for the first six months.
What did you do?
Hilbert: I read the manual. There was a section on latency tolerance, and it said if the two links differ by more than a certain amount, the buffer needs to grow, and if it grows too much, the call quality suffers anyway because you're adding delay. There's no setting that fixes a link that's wandering. You just pick which failure you'd rather have.
That's the honest version of the tradeoff. You can have low latency or you can have smooth reordering, and you can't have both if one path is unstable.
Hilbert: The manual had a table. I photocopied it and kept it in the van. I still have the photocopy somewhere. The manual itself I gave to the next guy when I left.
The box worked because it was a box.
Hilbert: It worked because it had its own radios, its own routing, and nobody was asking a phone to do it. We weren't fighting the operating system. The operating system was ours. That's the whole difference. The thing I used to install is now something people expect a handset to do for free, and I don't know why they expect that. It was a two thousand dollar box and it needed a guy to come out and set it up.
The most common wrong belief here is that dual SIM means two active data connections. Almost every dual SIM phone is dual SIM dual standby, one radio chain, one active data path, and the second SIM parked on a paging channel.
The correction is that standby is the honest word in the acronym. You're reachable on both, you're only ever on data on one. If you want two live data paths you need two independent radio chains, and then you need an OS willing to keep both up, and that second gate is the one that usually closes.
Where does that leave Daniel's question? If the bonding software is ready and the silicon exists, is the missing piece purely a product decision? Is it just that nobody thinks enough people want it?
I think that's most of it. The technology is not the hold-up. The hold-up is that the customer who needs concurrent dual-cellular data on one handset is a rounding error, and the cost of serving them lands on everybody.
The second question, which I find more interesting. Does the DIY path actually count as doing it on the handset, or does building your own device just relocate the problem?
It relocates it. You've moved the constraint from the phone to the thing you built instead of the phone. Which is a real solution to a real problem, it's just not the solution Daniel asked for.
As phones add more independent radios, the OS-level single-default-network assumption becomes the last thing standing. That's the thing to watch.
It's the lagging piece, and it's the piece that's hardest to move.
That's the episode. Thanks to Hilbert Flumingtop for producing. This has been My Weird Prompts, the human-AI collaboration podcast. If you've got a prompt, send it in, and if you enjoyed this one, a review helps more than you'd think. We'll be back soon.
See you then.
