You declined a call. Or you let it ring out. Either way, you expected Robin to step in, take it, and deal with whoever was on the other end. That's the whole point. You don't want to talk to an unknown number, so Robin does it for you.

Except sometimes the call never reaches Robin at all. It rings on the caller's side, drops into the network, and quietly dies. No handoff, no screening, nothing.

If you're here from a notification saying a call couldn't be connected, this post explains what went wrong. The gist: hiRobin works by handing your unwanted calls to your carrier's call-forwarding system, and that system, built decades ago and patched ever since, fails more often than anyone would like. Below is what call forwarding is, how hiRobin sets it up, how often it breaks on each of the three major Indian carriers, and what you can do about it.

In this article

• What call forwarding actually is

• How hiRobin sets up forwarding

• How often forwarding silently fails

• Why this happens: the legacy plumbing

• How to check whether your forwarding is active

• How to re-enable forwarding

• How to turn forwarding off completely

• What we're doing about it

What call forwarding actually is

Call forwarding is a service baked into the mobile network itself. It isn't an app feature. It's a rule that lives inside your carrier's switching infrastructure and says, in effect: when a call arrives for this number under a certain condition, send it somewhere else instead.

There are four kinds:

Unconditional forwarding sends every call onward, no matter what.

On-busy forwarding kicks in only when you're already on a call, or when you decline a call, which most networks treat as busy.

On-no-reply forwarding kicks in when you don't pick up within a set number of rings.

On-unreachable forwarding kicks in when your phone is switched off or out of coverage.

Robin never touches the first one. You keep answering the calls you want. Robin only steps in for the other three: the calls you decline, the ones you let ring out, and the ones that come in when you're unreachable.

How hiRobin sets up forwarding

When you onboard, hiRobin registers three conditional forwarding rules that point at its own dedicated line. That way, any call you don't want goes to Robin instead of sliding into voicemail or dropping entirely.

These rules are set using MMI codes, the star-and-hash sequences you sometimes dial for network settings. Each one maps to a condition:

Busy or declined calls use *67[robin number]#

No reply or missed calls use *61[robin number]#

Unreachable uses *62[robin number]#

The declined case is the subtle one. When you tap reject, most networks report it as busy, which is why declined calls follow the busy rule rather than the no-reply rule. A call you simply don't answer follows the no-reply rule, and you can even control how long it rings before forwarding by adding a timer to the end:

*61[robin number]**[seconds]#

where the seconds value is one of 5, 10, 15, 20, 25, or 30.

All three rules can also be set in one shot with a combined code:

*004[robin number]#

You never dial any of this yourself. hiRobin handles it during setup. But it's worth knowing, because this handoff is exactly where things sometimes break.

How often forwarding silently fails

Here's the uncomfortable part. We looked at calls that should have been forwarded, meaning calls you declined or missed on numbers where forwarding was set up and confirmed, and measured how often the call never reached its destination.

It isn't rare, and it varies a lot by carrier. On Airtel, the forwarding failure rate is 36.8%. On Jio, it's 25.1%. On Vi, it's 23.6%.

To put that plainly: on Airtel, more than one in three declined-or-missed calls that were supposed to forward didn't complete the handoff. Jio and Vi do better, but a quarter is still a quarter.

The frustrating part is that from your side, everything looked fine. Setup completed. The rule registered. Your phone reported success. And the call still didn't land where it was meant to. This isn't a hiRobin bug or a missing permission. It's the forwarding layer itself dropping the ball after everything on our end was done right.

So why does a feature that has existed for thirty years still behave like this?

Why this happens: the legacy plumbing

Call forwarding was designed for the GSM era in the early 1990s, when a phone call meant a circuit-switched voice call and nothing else. Back then your forwarding rules lived in a database called the HLR (Home Location Register) and were enforced by switches called MSCs (Mobile Switching Centers). A call came in, the switch checked the condition, looked up your rule, and routed the call. It was simple, rigid, and it mostly worked, because there was only one kind of network.

Then the network changed and the old design never fully caught up.

Modern calls don't ride the old circuit-switched network. They travel over data as VoLTE, run by a newer all-IP core called IMS, with services like forwarding handled by a component called the Telephony Application Server. Forwarding rules now live in IMS and are configured over a protocol called XCAP. But the MMI codes you dial are a legacy interface, and they have to be translated into IMS settings behind the scenes. When that translation works, everything is fine. When it doesn't, you get the worst outcome: your dialer reports success while the IMS side quietly ignores the change. The rule looks set. It isn't.

Jio is all-IP, which cuts both ways. Jio never ran a legacy 2G or 3G voice network, so everything is VoLTE over IMS. That's clean and modern, but it means every forwarding instruction depends on that code-to-IMS translation working perfectly. On dual-SIM phones especially, the code can come back successful without the IMS core ever recording it. One clean architecture with one brittle seam.

Airtel and Vi still run a mix of legacy circuit-switched and VoLTE infrastructure. Which one handles your forwarding depends on how your phone is registered at that moment, and the two sides don't always agree on what your rules are. A rule set while you're on VoLTE may not be honoured when a call comes in over the legacy path, and the other way around.

Dual-SIM phones add more confusion. Most phones in India carry two SIMs, and the forwarding command has to target the right SIM's network. Android's handling of which radio is active for which SIM is famously inconsistent, so a rule meant for one SIM can be applied to the wrong one or simply lost.

Forwarding also decays. Even a rule that registered perfectly doesn't always stay registered. Network events like re-registration, roaming, a SIM re-seat, or a carrier-side config refresh can silently reset or drop conditional rules. You set it once, it works for weeks, and then one day the network quietly forgets, with no notice to you or to us.

Put all of that on top of a thirty-year-old design that was never meant to be programmed by an app, and a failure rate between a quarter and a third stops looking surprising and starts looking almost built-in.

How to check whether your forwarding is active

You can check your own forwarding rules at any time. Dial these and the network reports the current status for each condition:

Busy or declined: *#67#

No reply or missed: *#61#

Unreachable: *#62#

All rules at once: *#002#

If the response shows your calls forwarding to Robin's number, you're set. If it shows "not forwarded" or a blank or voicemail number even though hiRobin looks configured, you've hit exactly the failure this post is about. Re-registering usually fixes it.

How to re-enable forwarding

If a check comes back empty, the simplest fix is to let hiRobin re-run setup, which re-registers all three conditional rules for you. If you'd rather do it by hand, register them directly:

Busy or declined: *67[robin number]#

No reply or missed: *61[robin number]#

Unreachable: *62[robin number]#

Or set all three together with *004[robin number]#. Then confirm with *#002#.

How to turn forwarding off completely

If you ever want to switch forwarding off, whether to stop Robin handling calls or just to clean up before troubleshooting, you can erase the rules:

Turn off busy or declined: ##67#

Turn off no reply or missed: ##61#

Turn off unreachable: ##62#

Turn off all conditional forwarding at once: ##004#

Turn off every forwarding rule, including unconditional: ##002#

After running any of these, dial *#002# to confirm everything is cleared.

What we're doing about it

None of this is something you should have to think about, and that's the point. hiRobin is built around the reality that the forwarding layer is unreliable. Instead of setting forwarding once and assuming it holds, hiRobin watches whether calls are actually arriving and re-registers forwarding when it detects that the network has quietly dropped your rules. The aim is for the plumbing to fix itself before you ever notice.

But your carrier's infrastructure has the final say, and on some networks, Airtel most of all, there's a hard ceiling on how reliable forwarding can be made from the outside. When a call genuinely couldn't be connected, that's almost always the legacy forwarding layer failing, not Robin giving up.

If calls keep slipping through, dial *#002# to see what your network actually has on file, re-register if it's empty, and you'll close most of the gap. The rest, frustratingly, is thirty years of telecom history doing what it does.

Download hiRobin

The failure rates above come from hiRobin's own call telemetry and reflect real-world behaviour on Indian networks. They aren't carrier-published figures. MMI codes are standardised but can vary slightly by handset and region. If a code behaves unexpectedly, check with your carrier.