...which is why the coverage map and the actual experience of using the network have never really been the same thing.
Right, and that gap is exactly where today's question lives. Because the thing that makes all that competition possible, the thing that lets you actually leave when the coverage disappoints you, is number porting.
Here's what Daniel wrote in this week. He's been chewing on this one for a while. Israel deregulated telecom, virtual operators showed up competing on price and quality, and the promise that makes all of it real is "keep your number." He knows that means the prefix and the number get transferred between subscribers, which is porting. What he's always wondered is why the instruction is "disconnect the old SIM, wait thirty minutes," and sometimes it's hours. Why is there any delay at all if this is just a subscriber ID moving between companies? Why do backlogs happen? And then he gets to the part he really cares about. He bought a data plan from a network with terrible customer service, he can't get through to anyone, and because it's data only he can't even activate the SIM. He figures the cleanest exit is to eat the cost, cancel, and sign up with a bundle on a virtual provider. But then: wouldn't his porting request be in some kind of limbo? If he opens a new subscription with a third provider because the transfer between the first and second never actually completed, what happens inside the infrastructure?
That last question is good. That's not a consumer question, that's an engineering question.
So today we're going to trace what actually happens when a number moves between networks. And what happens when it doesn't.
Let's start with what porting actually is, because the consumer version and the technical version barely resemble each other. Mobile number porting is a legally mandated right in Israel, and it's standardized globally by 3GPP. There's a stage one document, TS 22.066, that defines the service requirements, and a stage two document, TS 23.066, that defines the technical realization. So this isn't something carriers invented as a courtesy. It's a spec.
And the consumer-facing version of that spec is a sentence on a piece of paper. Disconnect the old SIM and wait thirty minutes.
Which is a fiction. A useful one, but a fiction. The thirty minutes comes from the original Israeli numbering plan, which allowed service interruption of up to half an hour during a port. That's the number Daniel's quoting. But the actual wait in practice was never thirty minutes, because the routing isn't what takes time.
Give me the Israeli timeline, because this market went through a very specific sequence.
The porting law passed in March 2005, took effect September 2006, but most providers weren't technically ready, so the Ministry set December 2007 as the date when enhanced financial penalties would kick in. That became the de facto launch. Then 2012 is the year that matters for Daniel's question, because that's when Golan Telecom and Hot Mobile arrived. Two disruptive entrants, and suddenly porting went from a curiosity to a mass-market competitive weapon. Hundreds of thousands of people moving.
And that's the moment the thirty-minute promise starts colliding with reality. Because if you're a carrier and your entire business model is "we're cheaper than the incumbent," the port has to work, or your customer is stuck paying the incumbent anyway.
So let's get into the machinery, because the machinery is where Daniel's question actually gets answered. When someone calls a ported number, the originating switch has no idea the number moved. It looks at the prefix, decides which network owns that range, and sends a query. In the MAP protocol, that query is called Send Routing Information. SRI. It's asking, essentially, "where is this subscriber right now, so I can route the call."
And the switch is asking the wrong company.
It's asking the company that used to own the number. Which is why 3GPP Release 4 introduced something called the MNP Signalling Relay Function, the SRF. The SRF sits in the signalling path, usually at a signal transfer point, and it intercepts that SRI query before it reaches the donor network. It looks the number up in a Number Portability Database, the NPDB, and if the number has moved, it rewrites the destination Global Title. That's the routing address. It changes it from the donor's home location register to the recipient's home location register, then forwards the query on.
And the originating switch never knows any of that happened.
Never knows. It sends a query, it gets back a routing instruction, it routes the call. The rewrite is transparent. That whole operation takes milliseconds. It is not where the delay lives.
So the thirty minutes is not a routing limit.
It is not a routing limit. Routing is near-instant. The delay is administrative and contractual, and we can prove that from the Israeli record. In 2012, Globes reported on the three-hour window that was mandated at the time, and they broke it down. Two and a half hours of that was administrative delay for mobile, two hours for landline. The Ministry's own stated rationale was identity verification. Confirming the identity of each customer requesting disconnection from the old carrier.
So the two and a half hours is two companies arguing about whether you are who you say you are.
That's the honest version, yes. And Globes noted the process could sometimes last several days. Which is why the Ministry's fix in 2012 was to let the receiving company verify success at the point of sale. Call the ported subscriber, or send an SMS, while they're still standing in the service center.
Which is a lovely idea and also tells you the system had no reliable way to tell anyone when the port actually completed.
Correct. And that's the thread that runs through everything Daniel's asking. The system knows the port happened in the routing layer. It's much worse at telling everyone else.
Before we get to what goes wrong, I want the routing models, because there are two and they behave differently.
Direct routing and indirect routing. Direct routing is the efficient one. The originating network queries a local copy of the portability database, gets back a routing number, and routes straight to the recipient network. One lookup, done. Indirect routing is the older approach. The call goes to the donor network based on the prefix, and the donor has to redirect it to the recipient. That creates a loop, what the industry calls tromboning, where the call travels to a network that doesn't own the subscriber anymore and then gets bounced onward.
Which adds latency to every single call to that number, forever, until the database catches up.
And it's not a small effect. Intecracy published work on this in July, and they found that in hybrid networks, where you've got a mix of direct and indirect routing, up to fifty-three point seven percent of call-setup delays can be traced to signalling protocol translation at the interface with legacy donor MNP databases. That's not a rounding error. That's more than half of the setup delay in those networks coming from one legacy interface.
Fifty-three point seven percent. That's a very specific number for a very unglamorous problem.
That's the whole topic in one figure. Nobody writes press releases about the interface between a modern signalling system and a legacy donor database. But it's where the time goes.
So the real hard problem isn't the rewrite. It's keeping all the copies of the database in sync.
That's the synchronization problem, and it's the answer to Daniel's first question. Every operator keeps a local copy of the portability data so they can route efficiently. Those local copies have to stay in near-real-time sync with a central reference database. On legacy monolithic billing and operations systems, that sync happens by batch processing. Batches run on a schedule, and the delay between batches can be hours.
Hours.
Hours. On modern event-driven architectures, the sync is real time. So you have two carriers in the same market, one running batch and one running event-driven, and the experience of porting between them depends entirely on which side of that divide they're on.
And that explains why the same process feels instant one week and takes a day the next. It's not the network. It's whose batch window you landed in.
Which brings us to the regulatory picture, and I want to flag something here rather than smooth it over, because the sources disagree. The 2010 directive required porting within three hours. SmartCut still cites that three-hour figure. But Ze Baduk, writing this year, says the requirement is one business day, with the actual port usually taking a few hours. And LeadClient says three to five business days for mobile, up to ten for landline.
Those are not compatible numbers.
They're not. One business day, three hours, three to five days. Either the regulation has changed and some guides haven't caught up, or different sources are describing different things, the legal limit versus the typical experience versus the worst case. I don't know which it is, and I'd rather say that than pick one and sound confident.
Fair. And the honest read is that the consumer-facing number has always been softer than the regulation. The original plan said porting within three to four hours and service interruption under half an hour. What people actually experienced was whatever the two carriers' back offices managed that day.
Right. So that's the machinery. Now let's talk about what happens when it breaks down.
Because Daniel's asking two separate things and I want to keep them separate. There's "why do backlogs happen," which is a known problem with known causes. And there's "what happens in a three-way race condition," which is not documented and which I suspect nobody has a clean answer for.
Agreed. Backlogs first. The causes are boring and specific. Mismatched customer details. Your name, your ID number, or your customer number doesn't match what the old provider has on file. That's the most common one, and it's the direct descendant of that identity-verification requirement we talked about. The line being blocked, for debt, or because it was reported stolen or lost. Trying to port a line that isn't actually a mobile line. And then technical faults or abnormal load on the carriers' systems.
Abnormal load. Meaning a lot of people are porting at once.
Meaning a promotion just launched, or a competitor just undercut everyone, and the porting queue backs up the way any queue backs up. And here's the tension that the Israeli story makes very concrete. In early 2008, the Ministry eased the data-verification step to speed things up. And ten days later, TheMarker reported that dozens of customers across the four carriers had been ported without their knowledge. The estimate was sixty to seventy subscribers who discovered their number had been disconnected and transferred to another customer at another company.
Sixty to seventy people whose phone number quietly became someone else's.
Because the verification step was the thing standing between a fast port and a port that shouldn't have happened. Loosen it and you get speed. Loosen it too far and you get people waking up to a dead phone and a stranger answering their calls.
That's the whole speed-versus-security trade in one incident. And you can see why the Ministry keeps fiddling with the rules. Every time they speed it up, something goes wrong. Every time they slow it down, the carriers get accused of using the delay to hold customers hostage.
Both accusations are usually true. That's what makes it a hard problem rather than a solved one.
Now the grey window. This is the part of Daniel's question I think is actually the real answer, even though he didn't use the word.
The grey window is the interval between the actual moment of porting and its update in the billing systems. The number is live in the routing database. Calls route correctly. But billing, SMS routing, and fraud systems haven't caught up yet. So the number exists in two states at once, depending on which system you ask.
That's the limbo. That's what he's describing without knowing the term for it.
And it's not just an inconvenience. Intecracy's line on this is that a delay in updating routing information by even a few minutes can lead to loss of signalling traffic, incorrect billing, and the creation of vulnerabilities that attackers exploit. The grey window is a documented fraud vector. Fraudsters use it to intercept access or to organize bypass routing, because for that window, the systems disagree about who owns the number, and disagreement is exploitable.
How much money are we talking about?
Global telecom fraud losses were estimated at forty-one point eight two billion dollars in 2025, up from thirty-eight point nine five billion in 2023. Subscription fraud alone runs about five point three one billion a year. The grey window isn't the whole of that, obviously. But it's one of the seams that fraud lives in.
So the thirty-minute instruction is hiding a window that costs the industry billions. That's a hell of a gap between the consumer sentence and the engineering reality.
And it gets worse in hybrid networks, which is most of them during a transition. That fifty-three point seven percent figure for call-setup delays from legacy donor interfaces, that's a grey-window problem too. The modern system and the legacy system are both running, and they don't agree.
Okay. Now the three-way race condition. Port from A to B never completes. Subscriber signs up with C. What happens?
I looked for this, and I want to be straight with you. Nobody documents it. Not in the 3GPP specs, not in the Hebrew sources, not in practitioner forums. I searched for it specifically.
So the honest answer is "we don't know."
The honest answer is "the closest documented facts are these, and they don't fully cover it." The closest facts are the grey window, which we just described, and one rule that's well established: a number cannot be ported after it has been disconnected. Once it's disconnected, it returns to the carrier's pool and can be reassigned to another customer.
Which is the scary version of Daniel's scenario. If the port from A to B never completes and something disconnects the line in the meantime, that number goes back in the pool. And someone else can get it.
Someone else can get it. Which means the question "what happens in the infrastructure" has a boring answer and a bad answer. The boring answer is that the request sits in a queue with a status that doesn't match reality, and eventually someone at one of the carriers resolves it manually. The bad answer is that the number gets recycled and Daniel's contacts start reaching a stranger.
And the reason nobody documents the three-way case is probably that it's rare enough that it never got written up, not that the system handles it gracefully.
That's my read. It's not that the infrastructure has a clean procedure for it. It's that the infrastructure mostly doesn't encounter it, and when it does, a human sorts it out.
Which is a very unsatisfying answer to a very good question. But I think it's the true one.
It is. And it connects to the MVNO angle, which is worth a minute. Golan, Hot Mobile, Wecom. These are virtual operators. They don't own infrastructure. Their entire pitch is price and quality of service. But every port into or out of them runs on the incumbents' signalling machinery. Their home location registers, the portability database, the SRF.
So a virtual operator can offer you a great price and still be hostage to how well the incumbent's database cooperates.
Completely. The MVNO's quality of service is bounded by the incumbents' plumbing. They can compete on price because they don't carry the infrastructure cost. But they can't compete on porting reliability, because they don't control it. And that's the irony of deregulation. It created the competition, but it didn't create the rails the competition runs on.
The rails are still the incumbents'. The new entrants just rent time on them.
When the rails glitch, the virtual operator is the one who can't fix it, because it's not their database.
To pull Daniel's question together. Why the delay? Because the routing is instant and the administration isn't. Why backlogs? Mismatched records, blocked lines, and load. What happens in the three-way race? Nobody's documented it, and the closest thing we have is a grey window and a recycling rule.
The thirty-minute instruction is a consumer-facing fiction layered over all of it. The routing is real. The delay is human.
Which is a good place to stop and let Hilbert say whatever he's been sitting on.
Hilbert: Nokia DX 200. That's the switch. Six thousand shekels, roughly, for the rack unit we bought used.
Used switch.
Hilbert: Used. This was a small virtual operator, maybe four thousand subscribers. I was in retention. Six weeks. My job was to call people who'd requested a port-out and talk them into staying.
And the dashboard.
Hilbert: There was a screen. It showed pending port requests in real time. It was almost never right. It would show a port as pending for hours after the customer had already walked out of the store with a new SIM. Or it would show a port as completed while the customer was still sitting in the service center waiting.
The dashboard was a fiction.
Hilbert: Everyone on the retention team knew it. We had a workaround. We'd call the customer's old number. If it rang, the port hadn't gone through. If it went straight to voicemail, the port was probably done. We used the phone itself as the source of truth. Not the dashboard.
That's the grey window, from the inside.
Hilbert: That's what it looked like. You'd have a customer on the line, and the screen says one thing, and the phone says another, and you trust the phone.
The retention calls. Did they work?
Hilbert: Sometimes. Mostly the person had already decided. You're calling someone who's already left the store. The port was the last step. They'd made up their mind weeks earlier.
So the six weeks.
Hilbert: Six weeks. There's an appointment I'm already late for.
Go.
The thing I keep turning over is that Hilbert's team had to build their own truth. The dashboard was the official system of record, and it was wrong often enough that the people whose job depended on it stopped trusting it and used the phone instead. That's not a bug in a screen. That's a system where the ground truth lives somewhere other than where it's supposed to.
That's the whole episode in a sentence, isn't it. The number you keep isn't a number. It's a record in a database that somebody has to move, and the moving is done by people who don't always agree on what state it's in.
Which is why I don't think the grey window closes. It shrinks. As carriers move to event-driven architectures and API-first designs, the sync gets faster and the window gets narrower. But it doesn't disappear, because there are always two systems that have to agree, and agreement takes time.
The three-way race condition stays undocumented, which means the honest answer to Daniel is that we don't know what happens, and the people who'd know probably resolve it by hand when it comes up.
That's the answer. The infrastructure is real, it's fragile, and it's full of human workarounds. The thirty-minute instruction is a fiction, but the machinery underneath it isn't.
Thanks to Hilbert Flumingtop for producing. This has been My Weird Prompts, the human-AI collaboration podcast. If you want to send us a question, email us at show at my weird prompts dot com.
We'll be back soon.
See you tomorrow.
