[Feature]: Feature request: Make leading + normalization before outbound routing configurable

[emericv]

Problem or Motivation

This feature request follows issues #1111 and #1112.

The current behavior has been confirmed as intentional: MikoPBX strips a leading + before outbound route matching, and administrators are expected to add it back in outbound route transformations when required by the provider.

The problem is that this normalization happens before route matching, which destroys information that may be needed by the routing logic.

For example, in a mixed dial plan, the following formats may coexist:

1064
0123456789
+33123456789
33123456789
+442012345678

With the current behavior:

+33123456789

is transformed into:

33123456789

before outbound routes are evaluated.

As a result, these two originally different inputs:

+33123456789
33123456789

become indistinguishable during route matching.

This prevents routing policies from using the original dialed format.

The current workaround is to recreate the + in the outbound route, for example:

Number begins with: 33
Trim from beginning: 0
Prepend: +

This works for simple cases, but it assumes that every number beginning with 33 should be reconstructed as +33..., even though the original input may actually have been:

33123456789

rather than:

+33123456789

It also becomes problematic when national numbers, short service numbers and international numbers coexist.

For example, a generic rule adding + can incorrectly transform:

1064

into:

+1064

which is what originally exposed this issue in my configuration.

The underlying problem is therefore not provider formatting itself, but the fact that the original dialed number is irreversibly normalized before route selection.

Proposed Solution

Please make the removal of the leading + before outbound route matching configurable.

For example:

Strip leading "+" before outbound route matching:
[Enabled / Disabled]

The current behavior could remain enabled by default for backward compatibility.

When enabled:

+33123456789
    -> 33123456789
    -> outbound route matching

When disabled:

+33123456789
    -> +33123456789
    -> outbound route matching

The outbound route could then explicitly decide whether to preserve, remove or transform the + depending on the selected provider.

For example:

+33123456789
    -> E.164 route
    -> provider A requires "+"
    -> send +33123456789

or:

+33123456789
    -> E.164 route
    -> provider B requires no "+"
    -> send 33123456789

This would preserve the current behavior for existing installations while allowing administrators to keep the original dialed format when needed.

As an alternative, if making the normalization configurable is not desirable, MikoPBX could preserve the original dialed number in a channel variable before normalization, for example:

ORIGINAL_DIALED_NUMBER=+33123456789
NORMALIZED_NUMBER=33123456789

This would at least allow custom routing logic to distinguish the original input.

The goal is simply to make it possible to distinguish:

+33123456789

from:

33123456789

without changing the default behavior for existing installations.

Alternatives Considered

No response

Area

None

Additional Context

No response

[miko-service-bot]

Triage

Classification: Core (dialplan generator), feature request. This is the properly-scoped follow-up to #1111 (closed as expected behavior) and #1112 (closed with @boffart's own suggestion — comment — that the underlying request be re-filed as a feature rather than a bug). So this issue is exactly what was asked for, not a re-open of the same argument.

Recap of the technical situation (unchanged since #1112)

OutgoingContext::makeDialplan() emits the strip rule unconditionally at OutgoingContext.php#L47-L51:

$conf .= 'exten => _+.!,1,NoOp(Strip + sign from number)' . " \n\t";
$conf .= 'same => n,Goto(${CONTEXT},${EXTEN:1},1);' . " \n\n";

generateRegexPatternsContextNames() walks OutgoingRoutingTable and emits per-route REGEX("^…" ${EXTEN}) checks after that block, so route matching never sees the leading +. That is the information loss the author is asking to make optional.

Status in develop

Code analysis only, no live build. Fetched the file on both refs via the GitHub API:

• master → SHA 05dd3c8f6d756884879f8953f846b88f85446c05
• develop → identical byte-for-byte for both the strip block and generateOutgoingRegexPattern() (the latter still escapes + in the route regex — which remains unreachable while the strip block runs first).

git log on OutgoingContext.php in develop shows no commits touching the + handling. No fix is pending in develop. Author's version is 2026.3.40; nothing newer would change this.

Design space

The author's three suggestions map onto three distinct schema/behavior surfaces. Summarizing so the maintainer decision is single-shot:

Option	Surface	Default	Effort
A. Global toggle — a PbxSettings flag gating whether the _+.!,Goto(…,${EXTEN:1},1) block is emitted at all.	1 setting, 1 conditional in makeDialplan().	On (current behavior).	Smallest.
B. Preserve original number — set an inheritable _ORIGINAL_DIALED_NUMBER=${EXTEN} at the top of [outgoing] before the strip, and expose it to -custom sub-contexts and (if desired) to route regex matching.	No schema change; adds one dialplan line. Docs to explain the variable.	Original always exposed.	Small, but only unlocks the semantics for customization-script users — routes still match on the stripped number.
C. Per-route + policy — new strip_plus / plus_policy column on OutgoingRoutingTable; routing runs against the un-normalized ${EXTEN}.	Schema migration + UI + generator changes; cleanest fit for the existing per-route trim/prepend model.	Existing routes: preserve current behavior.	Largest.

A + B are additive (both could ship: A gates the global strip, B lets custom sub-contexts see the original regardless of A). C subsumes both but is a real feature.

The author's own comment on #1111 — a catch-all "prepend +" fallback route turning 1064 into +1064 — is a concrete symptom that A/B would already resolve without introducing a new column.

Test coverage

Still no-tests — grep -R OutgoingContext tests/ is empty; no unit or integration test asserts on the shape of the [outgoing] block or on route regex ordering. makeDialplan() is a pure string return, easy to fixture; whichever option lands is a good moment to add a generator-output snapshot test (both defaults on/off, and per-route policy variants for option C).

Cross-check

• [Bug]: Remove rule that strip '+' before any numbers in extension.conf file #1111 (closed, "expected behavior") — same author, framed as provider format.
• Outbound routing loses information by stripping leading + before route matching #1112 (closed, "feature request rather than a bug") — same author, framed as routing/design.
• Call back to a number that begins with + #827 (closed, workaround: prepend +) — same reconstruct-what-was-just-discarded pattern.
• No open or merged PR touches OutgoingContext.php in this area.

Reach & severity

• Severity: medium. Blocks clean mixed dial-plans (short + national + E.164 + international) — common in EU deployments. Workaround exists (per-route Prepend = + on international patterns, plus more specific short-number routes ahead of them) but is leaky, as the 1064 case shows.
• Reach: low-volume in issue history (Call back to a number that begins with + #827, [Bug]: Remove rule that strip '+' before any numbers in extension.conf file #1111, Outbound routing loses information by stripping leading + before route matching #1112, this one), but structural — anyone building E.164-aware routing hits the same wall.

Recommendation

ready-for-maintainer-review as a product decision between Options A / B / C / "wontfix with clearer docs". Per the triage guide, no PR without explicit maintainer request — the author has already been sent to the workaround twice, so any implementation should be picked deliberately, not drive-by.

Suggested labels: enhancement, area/core, area/dialplan, severity/medium, no-tests, code-analysis-only, ready-for-maintainer-review.

(Public-repo reminder: reproducible purely from the generator — no logs or configs required, no sensitive-data risk on this thread.)

---

Generated by Claude Code

[emericv]

@boffart

This issue was opened specifically as a feature request, following the classification given in #1112.

It does not ask to change the current default behavior or break backward compatibility. It only proposes making the current normalization configurable, or alternatively preserving the original dialed number.

Could you please explain why this feature request was closed?

If the feature is considered undesirable, I would appreciate the technical or product rationale, especially regarding the loss of distinction between +33123456789 and 33123456789 before outbound route matching.