Why your number sometimes doesn't show up on an international call

You've placed a call to Tokyo, Paris, or São Paulo. Your number is set correctly in your account. The call rings briefly — then a recorded voice in the local language tells the recipient to "please call again with your number displayed," and the line cuts. Or maybe the call connects but your number shows up as Unknown, Private, or some unrelated string of digits on the other end.

This isn't a bug in our service, and it's not unique to us. It's one of the most persistent quirks in the global telephone network, and it's worth understanding — because how voice calls cross borders is genuinely different from how email or web traffic cross borders.

What a "caller ID" actually is

When your phone rings, the number you see on the screen comes from a signaling field that the originating network attaches to the call. The technical term is CLI — Calling Line Identification. The international format follows ITU-T Recommendation E.164: a country code, a national destination code, and a subscriber number. (Wikipedia: E.164)

For domestic calls — say, a Tokyo number calling another Tokyo number — the CLI rides cleanly from one carrier to the other through a chain of in-country exchanges that all trust each other's signaling. The number you sent is the number that appears.

International calls are a very different story.

The international handoff is a trust boundary, not a wire

If you dig into the history and technicality of the CLI itself, it's actually a pretty interesting story. I'll take the example of how an international call works (what PuchiDen does best) to show you how we cooperate across border (or the lack of it) to make it work.

A call leaving country A and terminating in country B passes through one or more transit carriers, then is handed off to a terminating carrier in country B. At each of those handoffs, signaling is re-mapped: the originating CLI is rewritten into the protocol the next carrier speaks, and policy decisions are made about whether to preserve it, modify it, or drop it altogether.

The CEPT (the European telecom regulators' body) summarises the underlying problem bluntly: CLI was "originally introduced as an informative service to recipients of voice telephony services. The use of CLI has been gradually extended to commercial purposes (e.g. billing), security purposes (caller identification, identification of malicious calls) and even technical purposes." The same number is being asked to carry trust it was never designed to carry — and on cross-border transit, that trust collapses. (CEPT/ECC Report 133 on Trust in CLI)

Industry consortia have been trying to harmonise this for years. The i3forum's CLI Management Guidelines (the de facto rulebook for wholesale voice operators) explicitly tells transit operators that "CLI should not be unnecessarily modified in network-network interfaces till the destination network" — but the document exists precisely because, in practice, it routinely is. (i3forum CLI Management Guidelines, June 2019, PDF)

Common things that happen at the border:

• The terminating carrier strips the CLI because its local rules require an authenticated origin and the foreign CLI isn't authenticated.
• The terminating carrier replaces the CLI with a generic gateway number ("0000…", or a route identifier) so it can still complete the call without misrepresenting it.
• The terminating carrier rejects the call outright if its local regulator forbids in-country numbers from arriving via international routes — a defence against fraudsters spoofing local numbers from abroad.

The last bullet is no longer theoretical. Belgium, the Czech Republic, Ireland, Malta, and Sweden introduced rules in 2024 requiring carriers to block international calls presenting local caller IDs unless they can be cryptographically verified. The UK's Ofcom now requires operators to block inbound international calls that display a UK number, with narrow exceptions for genuine roaming. (Global Call Forwarding: Europe Caller ID Regulations)

Japan's "Please display your number" service

Japan has a particularly strict and particularly visible version of this. Every major Japanese carrier offers a free service that intercepts incoming calls with no displayed number before they reach the subscriber, plays a recorded announcement asking the caller to redial with their number displayed, and terminates the call automatically.

NTT DoCoMo's version is called 番号通知お願いサービス ("Please Notify Your Number Service"). Their support pages describe the behaviour exactly:

• It blocks calls where the number is hidden at the network exchange, not on the handset.
• Blocked calls do not appear in the recipient's call log.
• It works even when the subscriber's phone is off or out of coverage. (NTT DoCoMo: 番号通知お願いサービス)

DoCoMo also calls out the exception that matters here: the service still passes through calls from public phones and from international origins where the caller can't control whether their number is displayed. In other words: if the international handoff strips your CLI before it reaches DoCoMo, the service treats your call as inherently un-notify-able and may let it through — but in practice many subscribers also enable the general anonymous-call rejection on their handset, which is what produces the announcement and disconnect users experience.

The Japanese phrase you may hear is:

恐れ入りますが、お客様の電話番号を通知しておかけ直してください。 "We're sorry — please display your phone number and call again."

From PuchiDen's standpoint, that's not a refusal by us. It's the destination network telling the caller it can't trust where the call came from.

STIR/SHAKEN doesn't solve this (yet)

If you've followed the anti-robocall conversation in the United States, you've heard of STIR/SHAKEN — a cryptographic framework that lets a terminating carrier verify that a caller ID was legitimately issued to whoever is using it. The US Federal Communications Commission has mandated it for most US carriers as part of its caller-ID-authentication push. (FCC: Combating Spoofed Robocalls with Caller ID Authentication)

The catch — and this is the heart of the problem — is that STIR/SHAKEN currently does not cross borders well. Each country runs its own trust anchor (its own what is called Certificate Authority list), and the certificate that signs a call in one country isn't recognised in another. Even the US–Canada border, between two countries that have both deployed the standard, required a dedicated bilateral effort to make signatures mutually verifiable. (Wikipedia: STIR/SHAKEN, Numeracle: Cross-Border Communications with STIR/SHAKEN)

Japan, like most of the world, is not yet inside any STIR/SHAKEN trust zone. So even if our outbound network signs your CLI flawlessly on the originating side, the Japanese terminating carrier has no cryptographic basis to trust the signature — and falls back on whatever default policy it applies to unauthenticated foreign-origin CLI. Which is, very often, strip or reject.

What this means in practice, for you

If you're calling a Japanese number, especially a landline, or a mobile owned by someone careful with their phone and the call doesn't go through, here are the realistic options:

1. Ask the recipient to temporarily disable the anonymous-call rejection (in DoCoMo's case, dial 1480 from their phone). This is the most reliable fix when you genuinely need to reach them.
2. Use Japan's 186 prefix on the recipient's side. This is a domestic Japanese convention for "send my number" — it doesn't help an international caller because we have no domestic dialler, but it's why the recorded announcement specifically mentions it.
3. Send a message first. A short SMS, message, or email warning the recipient that an international call is coming often lets them temporarily disable the block.
4. Some destinations are not reachable this way at all, especially landlines belonging to elderly users whose phones are configured to reject anything that isn't an obviously local number. For those, a different communication channel may be the only path.

We do not have a setting you can flip in your account to "make the caller ID work." If we did, every international calling service would have one. The honest answer is that international CLI is governed by inter-carrier agreements and national regulation on the receiving side — and we sit on the wrong side of that line, the same way every other internet-based international calling service does unless it has direct, in-country regulatory interconnect.

Why we'd rather tell you this than hide it

You're using a privacy-first calling service. We owe you an explanation when something doesn't work, not a generic "call failed" error. The truth is: the global voice network was designed in an era of national monopolies and trusted bilateral interconnects, and it has been retrofitted — imperfectly — for an internet age in which anyone can originate a call from anywhere. The friction you sometimes feel calling Japan, or France, or the UK, is the network's anti-fraud immune system doing exactly what regulators have asked it to do.

We're not happy about it either. But we'd rather you understand the limitation than think your call "just failed."

---

Sources

• Wikipedia — E.164
• Wikipedia — STIR/SHAKEN
• Wikipedia — Voice over IP
• ITU-T Recommendation E.164 — The international public telecommunication numbering plan
• ITU-T Recommendation E.157 — International calling party number delivery (PDF)
• i3forum — CLI Management Guidelines, Release 1.0, June 2019 (PDF)
• CEPT / ECC Report 133 — Increasing Trust in Calling Line Identification (PDF)
• FCC — Combating Spoofed Robocalls with Caller ID Authentication
• FCC — Adoption of Caller ID Authentication Technology for Combatting Robocalls Outside the US (PDF)
• Numeracle — Trusting International Calls with STIR/SHAKEN
• Global Call Forwarding — Why Europe is Cracking Down on In-Country Caller ID via International Routes
• NTT DoCoMo — 番号通知お願いサービス
• NTT DoCoMo — 番号通知お願いサービス ご注意事項
• NTT West (フレッツ光) — ナンバー・リクエスト
• DialVia — Does *67 Work When Calling Internationally?