Rufnummernunterdrückung (*5) wird nicht verarbeitet – NFON-Trunk, V20 U9

[denko2k]

Hallo zusammen,


ich komme bei der ausgehenden Rufnummernunterdrückung nicht weiter und hoffe auf Erfahrungswerte aus der Community.

Umgebung​

• 3CX-Version: 20.0 Update 9 (Build 995 Release)
• Provider: NFON (nconnect Voice), SIP-Trunk über TLS/5061
• Trunk-Vorlage: Da weder 3CX noch NFON eine fertige Vorlage bereitstellt (leider), wurde der Trunk mit der aktuellen generischen Vorlage GenericVoipProvider.pv.xml angelegt.

Ziel​

Bei ausgehenden Anrufen soll die eigene Rufnummer unterdrückt werden – vorgesehen über den Wählcode „Ausgehende Rufnummer unterdrücken" = *5 (Block Outbound Caller ID).

Symptom​

Beim Wählen von z. B. *50171XXXXXXX wird *5 nicht als Funktionscode erkannt und entfernt. Die vollständige Zeichenkette landet ungestrippt im Routing, sodass keine passende Regel greift bzw. keine Leitung aufgebaut wird. Der Anruf wird sofort beendet.


Zwei Meldungen aus dem Log (in unterschiedlichen Testläufen):



Failed to create outbound lines to call *50171XXXXXXX
destination failed, reason DestinationIsNotReachable
no more destinations available

There was no user or outbound rule found for the number *50171XXXXXXX that Ext.2XX dialed.

Erwartet wäre, dass *5 vor dem Regelabgleich konsumiert wird und nur 0171XXXXXXX ins Routing geht. Stattdessen bleibt *5 als Präfix erhalten.

Bereits geprüft / ausgeschlossen​

• Wählcode unter Einstellungen → PBX → Wählcodes: „Ausgehende Rufnummer unterdrücken" steht korrekt auf *5, ohne führendes/abschließendes Leerzeichen.
• Keine Kollision: kein weiterer Code beginnt mit *5, es existiert keine Outbound-Regel mit *-Präfix.
• Wählcode testweise geleert, gespeichert, neu gesetzt, gespeichert.
• Alle Clients betroffen: 3CX Desktop-App, 3CX Web-App und Snom-DECT (M-Serie) – Endgerät als Ursache damit ausgeschlossen.
• Neustart des Servers/OS durchgeführt – ohne Erfolg.

Damit sieht es nach einem Problem in der Dialcode-Verarbeitung selbst aus und nicht nach einem Konfigurations- oder Providerfehler.

Meine Fragen an die Community​

1. Ist dieses Verhalten bekannt? Hat jemand unter V20 Update 9 die Rufnummernunterdrückung per *5 erfolgreich im Einsatz, oder wird *5 bei euch ebenfalls nicht gestrippt? Gibt es einen bekannten Workaround oder einen Bugfix-Stand?
2. Anrufer-ID-Kontrolle beim NFON-Trunk: Was muss unter „Anrufer-ID-Kontrolle" korrekt eingestellt sein, damit CLIR sauber funktioniert und der Trunk NFON-konform bleibt? Konkret die Werte für From: Display Name / User Part, Remote Party ID und P-Asserted Identity – gerade weil der Trunk mangels Vorlage nur auf GenericVoipProvider.pv.xml basiert. NFON erwartet für CLIR bekanntlich „Anonymous" im From-Display bei gleichzeitig gültiger, trunk-eigener Rufnummer im PAI. Wie habt ihr das in V20 konkret in der Anrufer-ID-Kontrolle abgebildet?

Über Hinweise, funktionierende Konfigurationen oder eine passende NFON-Trunk-Vorlage würde ich mich sehr freuen.


Vielen Dank und viele Grüße

 

[denko2k]

Update & Technischer Nachweis zum Bug

Hallo zusammen,

ich konnte das Verhalten nach weiteren Tests und SIP-Trace-Analysen eindeutig eingrenzen. Es handelt sich um ein Zusammenspiel aus zwei Software-Bugs in der v20 (Build 20.0.9.995):

1. Technischer Nachweis: Header-Bruch bei dynamischer CLIR-Verarbeitung
Setzt man die von 3CX dafür vorgesehene Trunk-Einstellung "EnforcedOutboundCallerId" To be used when you want to send Anonymous via PAI, erzeugt 3CX einen fehlerhaften, widersprüchlichen From-Header im ausgehenden INVITE:
Plaintext

From: "0991XXXXX"<sip:[email protected]:5061;transport=TLS>;tag=0ed31672

• Fehler im Detail: 3CX anonymisiert zwar die URI (sip:anonymous@...), belässt aber im Display Name die Klartext-Rufnummer ("0991XXXXX").
• Auswirkung: Streng nach RFC prüfende Gateways (wie NFON) blockieren solche inkonsistenten Header richtigerweise mit 403 Forbidden (Spoofing-/Integritätsschutz).

2. Gegenprobe: Manuelles Custom Field funktioniert sofort
Wird derselbe Trunk testweise manuell konfiguriert:

• From : Display Name: Custom Field -> anonymous
• From : User Part: Custom Field -> anonymous
• P-Asserted Identity: "EnforcedOutboundCallerId" (überträgt die autorisierte E.164-Nummer 49991XXXXX zur Legitimation)

akzeptiert NFON den Call ohne Beanstandung und stellt das Gespräch vollständig anonymisiert an das Zielnetz zu.
3. Parsing-Fehler beim Wählcode *5
Zusätzlich bestätigt sich, dass der Wählcode *5 (bzw. **5) nicht vor der Regelauswertung konsumiert wird. Die Zeichenkette läuft ungefiltert in die Outbound-Engine, wo sie mangels passender Wählregel im Fehler DestinationIsNotReachable bzw. no user or outbound rule found endet.
Fazit & Bitte an das 3CX-Entwicklerteam
Die Gegenprobe belegt zweifelsfrei, dass weder der Provider noch das SIP-Gateway die Ursache sind:

1. Der Dialcode-Parser konsumiert *5 in v20 fehlerhaft.
2. Der interne Variablen-Parser für EnforcedOutboundCallerId erzeugt fehlerhafte SIP-Header (Display Name wird nicht auf anonymous gesetzt).

Aktuell bleibt als Notlösung nur ein unschöner Workaround über einen zweiten, separat registrierten Trunk mit fest verdrahtetem Custom Field: anonymous und manueller Präfix-Regel.

Ich bitte das 3CX-Produktmanagement / Support-Team um eine offizielle Prüfung und eine zeitnahe Behebung dieses Routing- und Header-Parsing-Bugs im nächsten v20-Maintenance-Release.

 

[avraammich_3CX]

Hi @denko2k,

Ich bitte das 3CX-Produktmanagement / Support-Team um eine offizielle Prüfung und eine zeitnahe Behebung dieses Routing- und Header-Parsing-Bugs im nächsten v20-Maintenance-Release.

verwende einen 3CX SIP Trunk welcher unterstützt wird + Unterstützung anonymous.

3CX unterstützte SIP-Trunks / VoIP-Anbieter in Deutschland

Finden Sie hier die von 3CX unterstützten SIP-Trunks / VoIP-Anbieter in Deutschland und gewähren Sie bestmögliche Kompatibilität für Ihre Telefonanlage.

www.3cx.de

Ein Telekom Company Flex Trunk in Verwendung mit *5 (anonymus) klappt wie zu erwarten.

deutsche-telekom-companyflex;

EnforcedOutboundCallerId wir im SIP FELD PPI (user Part) verwendet (Default Template unterstützter Trunk von 3cx + Unterstützung anonymous).

 

[bitn2]

Ich kann das Problem hier auch nicht nachvollziehen. Hier mit einem HFO/Gamma Trunk.

 

[fxbastler]

Provider: NFON (nconnect Voice), SIP-Trunk über TLS/5061

Lautet der geforderte Registrar siptrunk.cloud-cfg.com?

Wenn ja, dann ist das aktuell ein NFON SIP Trunk flexx. Dafür gibt es Vorlagen, entweder bei NFON im Portal oder auch von NFON selber (wenn man es nicht findet und die nett fragt). Da muss man nicht den generic Trunk der 3CX nehmen.
Man kann auch einfach den akt. 3CX Plusnet Trunk nehmen und dort nur den Registrar in siptrunk.cloud-cfg.com ändern.

Wenn dem so ist (Registrar, s.o.), dann kann ich bestätigen, dass das funktioniert: sowohl der Trunk als auch die anonyme Wahl mit *5.

 

[bitn]

Ich würde zuerst testen mit der SIP Trunk Vorlage aus diesem Beitrag evtl. klappt es ja damit.

N

Beitrag im Thema 'NFON SIP-Trunk not Working'

19. Februar 2026

Nfon hat uns Template zugeschickt.
Für alle, die es interessiert, mit diesem Template läuft der NFON Trunk direkt in V20.
Als DID muss aber das nationale Format 06xxxxx) verwendet werden und NICHT +496xxxx

• njullmann

• 

Da dieser Trunk seitens 3CX nicht supportet ist bleibt nur eigenes testen.

 

[denko2k]

Danke! Mit dem nfon Trunk (ehemals DTS) klappt es!
Damit Clip-No-Screening auch bei der internen 3CX-Umleitung (z. B. auf ein Mobiltelefon) klappt, muss man im Trunk noch folgende Anpassung machen:
From : Display Name >> "OriginatorCallerId" Original Caller number will be sent