T-Mobile **004* Conditional Call Forwarding — Silent-Failure Analysis

What **004* actually is

**004* is the GSM combined-conditional Call Forwarding registration code defined in ETSI ETS 300 952 / 3GPP TS 24.082. It is not a single rule. It is syntactic sugar for setting the same forward-to number against three independent supplementary services in one transaction:

The grey "Forwarding Successful" overlay on iPhone is a local handset UI. iOS shows it as soon as the MMI string is well-formed and the modem ACKs the dial — before the network's MMTel Application Server has actually committed the supplementary-service registration. There is no iOS UI for conditional forwarding at all (Settings → Phone → Call Forwarding only exposes the unconditional CFU rule), so you have no native way to see which legs actually took.

The only way to confirm what's truly registered is to query each leg directly:

*#61#    →  reports the active CFNRy destination (or "not active")
*#67#    →  CFB
*#62#    →  CFNRc
*#004#   →  reports all three at once

If you dial *#004# after a **004*[number]# attempt on an affected line, you'll typically see only CFNRy showing your number, with CFB and CFNRc either absent or still pointing at T-Mobile's internal voicemail (+1 805 637 7243).

Pattern A: entitlement gap

T-Mobile USA has been fully IMS-native since the post-2020 modernization push. Call control runs through their MMTel Application Server, which evaluates supplementary services using flags on each subscriber's HSS profile. Each of the four call-forwarding services (CFU, CFNRy, CFB, CFNRc) is a separately entitled feature. They are not always all provisioned per line. When **61* works individually but **67* and/or **62* silently fail to register, that almost always means the corresponding CFB and/or CFNRc service is not entitled on the subscriber profile.

Why CFNRy works for everyone: T-Mobile's carrier voicemail is itself implemented as an internal CFNRy rule pointing to +1 805 637 7243 (their TVM platform — that's the number you'll see if you query *#61# on a fresh line with no user-set forwarding). Voicemail couldn't function without it, so CFNRy has to be entitled on every line. CFB and CFNRc, by contrast, are only needed when a customer wants to override default behavior, and historically didn't ship with every subscriber template.

Accounts that disproportionately have the CFB/CFNRc gap, in rough order of likelihood:

1. Sprint-migrated lines. Different HSS lineage; the migration tool didn't always re-emit the full MMTel SS template. This is the single biggest predictor.
2. Pre-2020 grandfathered postpaid plans that pre-date the unified MMTel profile rollout.
3. Lines ported in many years ago with a tariff template that was current then but is missing flags now considered default.
4. Some Metro by T-Mobile prepaid lines and certain BYOD eSIM activations.
5. Anything that's been through a major plan migration without a SIM swap, since the re-push of the MMTel template is most reliably triggered by an activation event.

Pattern B: combined-form rejection (all three legs entitled)

The second failure mode shows up on lines where all three supplementary services are correctly entitled. Per-condition registration via **61*, **67*, and **62* each succeed individually — *#61#, *#67#, and *#62# all confirm the destinations after each per-leg dial. But when the combined **004*[number]# form is dialed, the network rejects the transaction atomically. *#004# immediately afterward reports either no active forwarding or only the carrier-default voicemail rule.

This is direct evidence — observed on a line freshly ported from AT&T to T-Mobile in April 2026 — that Pattern B is its own population, distinct from Pattern A. The same iPhone had been running **004* cleanly on AT&T immediately before the port. Within hours of activation on T-Mobile, **004* began silently failing while the per-leg codes continued to work. That isolates the change to the network side.

The most likely root causes for Pattern B, in rough order of likelihood:

1. AS-side combined-transaction guard. T-Mobile's MMTel Application Server appears to have a transaction-level policy that rejects (or partially rejects) a combined CF registration whose CFNRy leg would overwrite the carrier-default voicemail rule. Per-leg **61* requests are evaluated discretely and pass; the combined **004* arrives as a single SS Register transaction with three service codes and is refused atomically. This is consistent with the AT&T-vs-T-Mobile observation, since AT&T's IMS core does not appear to enforce the same guard.
2. Carrier-voicemail collision. A weaker variant of the above: the AS specifically refuses to replace the carrier-voicemail CFNRy rule when it comes in as part of a **004* combined transaction (because that would orphan voicemail), and rolls back the entire combined registration on conflict. The explicit per-condition **61* path is exempted because it represents an unambiguous user override.
3. Modem-side message aggregation. Per 3GPP TS 24.082 the handset is supposed to expand **004* into three separate SS Register messages. Some baseband implementations instead pack all three legs into a single MAP REGISTERPROCEDURE with multiple service codes. T-Mobile's AS may accept the per-leg form but reject the batched form. The AT&T-port evidence makes this unlikely as the dominant cause — the same modem produced the same MMI string for AT&T's AS and was accepted — but it's still possible if T-Mobile's AS is stricter about the combined message format.

For diagnostic purposes you don't need to pick between these — they all produce identical user-visible symptoms and all have the same fix (just dial the three per-leg codes). What matters is recognizing that this pattern doesn't need an entitlement re-push, so the typical Pattern A remediations don't apply.

Customers who can **004* cleanly almost certainly have postpaid Magenta/Go5G lines activated post-2022 with no Sprint heritage, no plan-migration history, and are not behind whatever AS-side policy gates Pattern B. The intersection of "no Pattern A" and "no Pattern B" is narrower than one might expect, which is why a sizable fraction of T-Mobile users see one or the other failure mode even on otherwise current postpaid plans.

How to diagnose which pattern you have

Run this sequence on the affected line, recording the response after each dial:

1. Dial ##004# to clear any existing user-set forwarding.
2. Dial **61*[fwdnum]#. Then dial *#61# — note whether it reports your forwarding number.
3. Dial **67*[fwdnum]#. Then dial *#67# — note whether it reports your forwarding number.
4. Dial **62*[fwdnum]#. Then dial *#62# — note whether it reports your forwarding number.
5. Dial ##004# again to clear, then dial **004*[fwdnum]#. Then dial *#004# — note which (if any) legs come back active.

Then compare the results against this table:

The per-leg test is the central diagnostic: it tells you whether you have an entitlement problem (Pattern A) or a combined-transaction problem (Pattern B). The combined test confirms the diagnosis but isn't strictly required to act — if all three per-leg codes work, the per-leg setup is the answer regardless of why the combined form fails.

How to actually get this fixed

Front-line T-Mobile Care cannot fix either pattern. There is no button in their tools labeled "re-provision MMTel SS template" or "relax combined-CF transaction guard". The right path depends on which pattern you have.

Pattern A — entitlement gap

Two paths work:

Path A1 — Engineering-tier escalation

Open a ticket and explicitly ask for it to be routed to T-EX (Technical Experts) or Engineering Services. Use this phrasing — mentioning MMTel, HSS, and supplementary services flags you as someone technical and shortcuts the "have you tried turning off Wi-Fi Calling" loop:

Please open a technical ticket to provisioning. My MMTel supplementary-service profile is missing CFB and CFNRc entitlements. Combined **004* MMI registration shows local handset success but only the CFNRy leg is registered on the network — *#67# and *#62# return inactive after registration. Per-condition **61* works correctly, which confirms the CFNRy entitlement is present and only CFB / CFNRc need to be re-pushed from the current default MMTel template. Please run an HSS audit and a profile re-push.

Path A2 — SIM swap (often faster)

Walk into a T-Mobile store and ask to be issued a fresh SIM (physical or eSIM, doesn't matter) on the same line. The activation event almost always triggers a re-push of the current default MMTel profile from the HSS, which has all four CF services entitled. After the swap, factory reset the device, re-activate, and try **004* again. About 70% effective in user reports, and free.

Pattern B — combined-form rejection

The good news: there is nothing wrong with your line's provisioning. All three supplementary services are entitled and all three register correctly when dialed individually. The fix is just to use the per-leg triple as your permanent setup:

**61*[fwdnum]#        ← No answer
**67*[fwdnum]#        ← Busy
**62*[fwdnum]#        ← Off / out of service

Verify each with the corresponding *# query (*#61#, *#67#, *#62#) — each should report your forwarding destination. The end-state is identical to a successful **004* registration; the only difference is three dials instead of one. There is no functional downside.

Why SIM swap probably won't help Pattern B. The SIM-swap remedy works for Pattern A because the activation event re-pushes a current-default MMTel profile to the HSS, restoring the missing CFB/CFNRc entitlements. In Pattern B nothing is missing — the profile is already correct. Re-pushing the same profile fixes nothing. Multiple attempts at this on freshly-activated SIMs in 2026 have not changed Pattern B behavior.

Why Engineering escalation is harder for Pattern B. The defect, if it is one, sits at the AS-policy or AS-implementation layer rather than the per-subscriber HSS profile. Front-line T-EX has visibility into HSS profile contents and can request re-pushes; they typically have no tooling to alter or test transaction-handling policy on the MMTel AS itself. If you do escalate, the evidence you have (same iPhone, same modem, working **004* on the prior carrier, broken **004* on T-Mobile, all three per-leg codes registering correctly) is the strongest possible diagnostic packet — but expect it to land with someone who isn't sure what to do with it. Suggested phrasing if you try anyway:

CFNRy, CFB, and CFNRc are all correctly entitled on my line — **61*, **67*, and **62* per-condition registrations all succeed and *#61# / *#67# / *#62# correctly report the registered destinations. However, the combined **004*[number]# registration is silently dropped: *#004# after the combined dial reports no active forwarding. The same iPhone was running **004* cleanly on AT&T immediately before this line was ported to T-Mobile, which isolates the change to the network side. This appears to be a combined-MMI transaction handling issue on the MMTel Application Server, not an entitlement gap. Please escalate to whoever owns AS-side supplementary-service transaction policy.

Implications for apps that rely on Conditional Call Forwarding

For any app — call screening, virtual receptionist, voicemail-replacement service, etc. — that relies on the user setting up CCF as part of onboarding, this issue has a few practical consequences:

• The dialer's "Forwarding Successful" overlay must not be trusted as a setup signal. A test call placed to the line and routed through the platform is the only reliable confirmation that all three legs registered.
• When a test call fails on T-Mobile, the right next step is the per-leg triple, not retrying **004*. For Pattern B users this gives full coverage — identical end-state to a successful combined registration, just three dials instead of one. For Pattern A users it still gives partial coverage on the legs that are entitled, which is meaningfully better than nothing while a SIM-swap or escalation is in flight.
• A diagnostic mode that runs *#61# / *#67# / *#62# and surfaces which legs registered would resolve a meaningful fraction of "my forwarding doesn't work" support tickets in seconds, and would also distinguish Pattern A from Pattern B without any user-facing jargon — the UI just needs to say "your forwarding is set up via three rules instead of one, and it's working."
• The affected T-Mobile population is broader than just Sprint migrations. Pattern A skews toward Sprint-migrated and grandfathered lines (millions of lines, but a specific demographic). Pattern B has been observed on a fresh AT&T-to-T-Mobile port — i.e., a brand-new T-Mobile subscriber on a current postpaid plan with no migration history at all. If Pattern B is widespread among ported-in lines (the diagnostic data isn't there yet), it means even fresh activations are at risk and the onboarding flow cannot assume **004* will work.
• Defaulting to the per-leg path on T-Mobile is a strong heuristic. Both patterns are fixed by it, the user-visible flow is barely longer, and there is no downside on lines where **004* would have worked anyway. An onboarding flow that detects T-Mobile via CTCarrier (or the IMSI MCC/MNC) and routes to the per-leg triple by default would sidestep both patterns without needing to diagnose which one any given user has.