Since 4 September 2026 Twilio rejects an inbound call that is forwarded internationally while still presenting a Spanish or French domestic caller ID. The leg fails with SIP 403 and Twilio error 32224. Domestic forwarding is unaffected. The fix is a caller ID that matches the true country of origin.
This is not a platform outage and nothing in your configuration broke on its own. It is a carrier-side enforcement change implementing rules the Spanish and French telecoms regulators wrote first: the rule sits above Twilio, in the Spanish numbering order and in the French numbering plan. If you run a Spanish or French local number with the agent terminating somewhere else — a very common AI voice agent shape — it applies whether or not anyone told you.
Our forwarded calls showing a Spanish number stopped connecting — did something change?
Yes, and it is dated. Twilio published a changelog entry on 4 September 2026 titled International Call Forwarding — Compliance Blocking for Spain & France. Its own wording: In Spain and France, an incoming call intended for a non-Spanish or non-French destination that is then forwarded internationally while presenting a Spanish or French domestic caller ID is now blocked, in line with local regulatory requirements. The calls will be rejected with SIP response code 403 and Twilio debug error code 32224. Domestic Call forwarding is not impacted.
The entry is tagged against both Voice API and Elastic SIP Trunking, and marked GA.
Read the condition carefully, because three things have to be true at once and most people only check one. The call has to be forwarded; the forwarded leg has to be international; and the caller ID on that leg has to be a Spanish or French domestic number. Remove any one of those and the call goes through. That is why the same platform, the same account and the same TwiML can fail for one route and succeed for another in the same minute.
The default behaviour of Twilio <Dial> is why so many deployments were caught. Twilio documents it plainly: When you use <Dial> in your response to Twilio’s inbound call request, the dialed party sees the inbound caller’s number as the caller ID.
Forward a Spanish caller to an agent endpoint outside Spain and the outbound leg presents that caller’s Spanish number. Nobody configured it. It is what happens when you do nothing.
What to check in the next 24 hours
All four of these are free and none of them involve us.
- Filter the Twilio error logs on 32224. If you see it, the diagnosis is settled and you can stop looking. Twilio’s own error page for error 32224 names it Forwarded Call blocked by Twilio and gives the cause as
You are attempting to forward a call that received on a domestic number to an international number.
- Confirm the SIP response code is 403, not 503, 486 or 487. A 403 with 32224 is this change. A 503 is capacity or trunk reachability. A 486 or 487 is a busy or cancelled leg and has nothing to do with numbering rules.
- Write down two countries per route: the country of the number you present, and the country the outbound leg physically terminates in. Do this on paper for every number you own in Spain and France. Most teams discover at this step that they cannot answer the second question without asking their platform vendor, which is itself the finding.
- Run the rule-out test below. It takes one call.
The one test that rules this in or out
Place the same forwarded call twice, changing exactly one variable: on the second attempt, set callerId on the forwarding leg to a number you own in the country the leg terminates in, rather than letting the Spanish or French number pass through.
- Second call connects, first call did not. The block is caller-ID driven. This change is your cause.
- Both calls fail, and the error is not 32224. This is not your cause. Look at trunk registration, concurrency limits or your termination provider instead — the same symptom is produced by a saturated trunk, and the triage for that is in our guide on connecting an AI agent to your SIP trunk.
- Both calls connect. You were never presenting a domestic Spanish or French caller ID on an international leg, and you can stop here.
That third branch matters: a blocked forwarding leg looks identical to half a dozen unrelated failures. If your agent drops transfers rather than inbound legs, the mechanism is different again and is covered in why AI voice agent transfers to a human fail.
Which call flows are blocked, and what to change
This is the table to work through route by route. Blocked means the outbound leg is rejected with SIP 403 and error code 32224 as at 14 September 2026.
| Call flow | Caller ID presented on the outbound leg | Blocked? | What to change |
|---|---|---|---|
Spanish local number rings, forwarded to an agent endpoint outside Spain, default <Dial> behaviour |
The caller’s Spanish number | Yes | Set callerId to a number in the terminating country, or move termination into Spain |
| Spanish local number, forwarded to an endpoint inside Spain | Spanish | No — Twilio states domestic call forwarding is not impacted | Nothing |
| Spanish local number terminated locally on a Spanish trunk, agent media reached from inside Spain | Spanish | No — there is no international forwarded leg | Nothing; keep termination in-country |
| Direct SIP from the agent stack to a Spanish trunk, no second leg | Spanish | Out of scope of this change | Nothing, but see the outbound row |
| Outbound campaign dialled from outside Spain presenting a Spanish number | Spanish | Blocked at the Spanish network, separately from Twilio, under the 2025 numbering order | Originate in-country with an authorised number, or apply for the published exemption |
| French fixed number (01 to 05, or 09) forwarded internationally | French fixed | Yes, and the French network cuts an unauthenticated French fixed CLI arriving from abroad | Move termination in-country, or obtain level A attestation through display delegation |
| French mobile number (06 or 07) presented from abroad without authentication | French mobile | Not cut at the French network — the caller ID is masked instead | The call connects with no number shown; expect answer rates to fall, and plan accordingly |
| Original caller ID preserved on the forwarded leg using a Twilio CallToken | The original caller | Not stated either way | Neither the 4 September changelog nor the error 32224 page carves out CallToken as at 14 September 2026; assume no exemption until Twilio publishes one |
The CallToken row is worth its own sentence. Twilio documents CallToken as the way to maintain the original caller’s CallerID for the forwarded leg of the call and facilitate SHAKEN/STIR verification
, and the agent stacks are already colliding with it: livekit/sip issue 789, opened 13 August 2026 and still open when we checked it on 14 September 2026, reports that CreateSIPParticipant rejects valid Twilio X-Twilio-CallToken values over 1,024 bytes because the token may carry SHAKEN/STIR and DIV passports. The provenance mechanism and the agent framework are being built at different speeds.
Spain and France are not running the same rule
Twilio collapses both countries into one behaviour and one error code. The regulators did not. If you only fix for the Twilio symptom you will get Spain right and France half right.
| Jurisdiction | Domestic caller ID on a call arriving from abroad | What the network does | In force | Instrument |
|---|---|---|---|---|
| Spain | Not permitted unless the call is international roaming | Block | Order in force 7 March 2025; article 5.1 obligation due within three months, so 7 June 2025 on our arithmetic, not a date the order prints | Orden TDF/149/2025, article 5.1 |
| France — fixed 01 to 05 and 09 | Permitted only with a level A attestation under the numbering authentication mechanism | Cut the call; the regulator states no exception exists as there is for mobile | 1 January 2026 | Loi Naegelen of 24 July 2020 via article L. 44 CPCE, plus Arcep decision 2025-2215 of 27 November 2025 |
| France — mobile 06 and 07 | Permitted only with a level A attestation; roaming subscribers are not excluded, and the only exception Arcep publishes is Saint-Martin, deferred to 1 January 2028 | Mask the caller ID and let the call proceed | 1 January 2026 | Same instruments |
| United Kingdom | Landline presentation numbers from abroad not permitted except in a limited number of legitimate cases | Block | 29 January 2025 | Ofcom strengthened CLI guidance |
| Australia | Industry code note says providers should not deliver an inbound international call showing an Australian number, unless exceptions apply | Discretionary; the hard obligation is against calls with no caller ID at all | Code dated July 2022 | C661:2022, clause 4.2.5 note 3 and clause 4.2.6 |
Two things fall out of that table. France distinguishes fixed from mobile and Spain does not, so a French mobile deployment survives the leg but arrives anonymous — a silent conversion problem rather than a loud technical one. And Australia is the outlier in the other direction: a code note with the word should and a published exceptions list, which is why Australian deployments have not felt this yet. The authentication machinery underneath France is STIR/SHAKEN, the same family we cover in STIR/SHAKEN for AI voice agents in Australia.
The Presentation-Origin Rule
Here is the durable version of all of the above, and it is the thing worth writing on the architecture diagram rather than in a ticket:
A local number is a presentation, not an address. When the presentation and the origin of the leg disagree, the carrier resolves the disagreement — not you.
To test whether a deployment is exposed, apply the two-country test: write down the country of the number you present and the country the leg physically originates from. If they differ, you are relying on a presentation the terminating network cannot verify, and you are exposed to whichever rule that country adopts next. Spain answered with a block, France with a block for fixed and a mask for mobile, the United Kingdom with a block for landlines. The direction of travel is one way.
The generalisable point: buying a local number in every market and pointing it at one central agent is the exact pattern regulators are closing. It was cheap because it separated presentation from origin, and that separation is what caller ID authentication exists to detect.
The next 7 days, and then the permanent fix
Days 1 to 7. Set callerId explicitly on every forwarding leg, using a number you own in the country the leg terminates in, rather than relying on the default pass-through. Connectivity is restored immediately and the change is reversible. Accept that the called party now sees a number from the wrong country and measure what that does to answer rates rather than assuming it. For France, check separately whether mobile-presented traffic is arriving masked: it raises no error at all, only a quiet fall in pickups — the same class of silent degradation as a number showing as Scam Likely, though that mechanism is US call labelling rather than an EU numbering rule.
The permanent fix: terminate locally. Stop forwarding the leg out of the country. Put the agent media endpoint inside the market, so the Spanish number is answered by something genuinely in Spain and there is no international forwarded leg for a carrier to inspect. That is more work than it sounds: a termination point per market, per-market trunk contracts, routing and observability for each, and someone who can read the local numbering rules when they change again.
If you need the number to keep working exactly as it is, the answer is a regulator process, not a vendor ticket. Spain publishes one: article 5.3 of Orden TDF/149/2025 allows the Secretary of State for Telecommunications and Digital Infrastructure to exempt duly justified cases by resolution, expressly including scenarios where the PAI and From fields are permitted not to match. Exemptions are notified to the CNMC and published on the Secretary of State portal. France has no equivalent carve-out for fixed numbers; the route there is display delegation, an inter-operator process run through the APNF, so that the originating operator can attest the number at level A on your behalf. Both of those are conversations with your carrier and the regulator. A software vendor cannot grant either, and any vendor that says it can has misread the instrument.
Doing this yourself versus handing it over
The method above is complete and anyone with carrier relationships and a SIP background can execute all of it. The honest cost is what gets underestimated, so here it is as a threshold rather than an argument.
| Your situation | Do it yourself | Hand it over |
|---|---|---|
| One or two markets, one number each | Yes — set callerId, done in an afternoon |
Not worth it |
| Local numbers in 5 or more countries pointed at one central agent | Only with in-house SIP and carrier-contract capability | Worth pricing — you are maintaining a termination footprint, not a phone number |
| Compliance exposure that needs an exemption filing or display delegation | No — this is your carrier and the regulator, not your platform | Neither — go to the carrier directly |
| You need the agent itself deployed inside the market for data or numbering reasons | Possible but expensive per market | Yes, if the platform supports private model deployment on your own infrastructure |
That last row is where Zian AI sits inside this problem rather than around it: it runs live phone, SMS, email and WhatsApp outreach in 30+ languages and supports private model deployment on customer infrastructure, which is the configuration that lets the agent live inside the market the number belongs to instead of forwarding out of it. Its orchestration layer, SmartReach AI™, already selects message, channel and timing by country — the same axis this numbering problem runs along. More architecture questions are collected in the Zian AI FAQ on autonomous sales agents.
Frequently asked questions
Did Twilio break my calls or did a regulator?
A regulator did, and Twilio is enforcing it at the platform edge. The Twilio changelog entry dated 4 September 2026 describes the block as being in line with local regulatory requirements. The underlying Spanish instrument is Orden TDF/149/2025, which requires operators to block voice calls received from abroad that present a Spanish telephone number as the caller ID, except in cases of international roaming.
Is domestic call forwarding inside Spain or France affected?
No. The Twilio changelog states that domestic call forwarding is not impacted. The condition requires the forwarded leg to be international. A Spanish number forwarded to another Spanish endpoint is outside the scope of this change.
What error will I see, and where do I find it?
The rejected leg returns SIP response code 403 and Twilio debug error code 32224. The error is named Forwarded Call blocked by Twilio, and Twilio lists one cause as attempting to forward a call received on a domestic number to an international number. Filtering the error logs on 32224 is the fastest confirmation available and it costs nothing. See the Twilio error 32224 reference.
Do France and Spain apply the same rule?
No. Spain blocks any call arriving from abroad that presents a Spanish number, unless it is international roaming. France applies its numbering authentication mechanism from 1 January 2026 and splits by number type: an unauthenticated French fixed number arriving from abroad must be cut, while an unauthenticated French mobile number is masked and the call still proceeds. The French regulator states that no exception exists for fixed numbers of the kind that exists for mobile.
Can I get an exemption?
In Spain there is a published route. Article 5.3 of Orden TDF/149/2025 allows the Secretary of State for Telecommunications and Digital Infrastructure to exempt duly justified cases by resolution, including scenarios where the PAI and From fields are permitted not to match, with exemptions notified to the CNMC and published. In France the equivalent for a fixed number you do not hold is display delegation through the inter-operator process, so the originating operator can attest the number at level A. Arcep states that the updated numbering plan explicitly prohibits display delegation of mobile numbers.
How do I know this is not a trunk or capacity problem instead?
Repeat the same forwarded call once, changing only the caller ID on the forwarding leg to a number you own in the country the leg terminates in. If that call connects, the block is caller-ID driven and this change is the cause. If it still fails and the error code is not 32224, the cause is elsewhere and you should look at trunk registration, concurrency or your termination provider.
Where to go next
If you are re-architecting a cross-border voice deployment so the agent sits inside each market rather than forwarding out of it, Apply For Partnership. Zian AI is currently in partnership-application beta.