3CX v20, Telekom Company Flex (Not Acceptable Here (488)

[3cx2]

Hallo,
seid der update auf die neuste 3CX version und Umstellung auf Telekom CompanyFelx kann man keine ausgehende Anrufe tätigen. Die Fehlermeldung lautet:

Call or Registration to +49800xxxx@(Ln.10000@Telekom CompanyFelx) has failed. sip:tel.t-online.de:5061;transport=TLS;lr;maddr= replied: Not Acceptable Here (488)


Was kann das Problem sin, die ausgehende regeln sind es nicht, Server SIP-trunk ist nach der Anleitung als "Telekom CompanyFlex Cloud" eingerichtet.

Danke EUCH

 

[bitn2]

Du scheinst eine 0800er Nummer anzurufen. Die muss wirklich nur mit 0800 gewählt werden und nicht mit +49 davor soweit ich weiß. Ansonsten mal die Telekom fragen was denen nicht gefällt, die Meldung kommt von da.

 

[mbehrens]

Call or Registration to +49800xxxx@(Ln.10000@Telekom CompanyFelx) has failed. sip:tel.t-online.de:5061;transport=TLS;lr;maddr= replied: Not Acceptable Here (488)

Ist die Authentication ID richtig angegeben?

 

[fischeredv-mw]

Problem: Telekom SIP-Trunk CompanyFlex – Ausgehende Anrufe schlagen fehl​

Ja, und wieder einmal stehen wir vor einer undokumentierten Herausforderung, die weder in den 3CX-Webinaren noch auf den offiziellen Telekom- oder 3CX-Seiten schnell aufgeklärt wird.

Wir setzen eine self-hosted 3CX in der Cloud ein und verwenden den Telekom SIP-Trunk CompanyFlex.

Problemstellung:​

• Das Provider-Template „Deutsche Telekom (CompanyFlex - Cloud)“ wurde genutzt.
• Eingehende Anrufe funktionieren einwandfrei.
• Ausgehende Anrufe schlagen mit folgendem Fehler fehl:
  Call or Registration to 08003301000@(Ln.10001@Deutsche Telekom (CompanyFlex)) has failed.
  sip:tel.t-online.de:5061;transport=TLS;lr;maddr=217.0.139.79 replied: Not Acceptable Here (488)
  

Debugging & bisher getestete Maßnahmen:​

• Firewall-Checker in 3CX ist grün
• Die ersten 20 Treffer in der Google-Suche, 3CX-Foren und Telekom hilft geprüft → keine Lösung
• Verschiedene Rufnummernformate getestet → immer Fehler 488 "Not Acceptable Here"

---

Offene Fragen & Konfiguration zur Überprüfung​

Ist das richtige Provider-Template verwendet?​

• Template genutzt: „Deutsche Telekom (CompanyFlex - Cloud)“
• Zum Setup: 3CX läuft nicht über einem Telekom-Anschluss, sondern in einer self-hosted Cloud-Umgebung.
• Frage: Ist das das korrekte Template, oder muss ein anderes verwendet werden?
• (CompanyFlex - VoiceData ist ja nur für den Fall, dass einen Telekom Anschluss nutzt)

Trunk-Hauptnummer im SIP-Trunk:​

• Eingetragen im E.164-Format (+49xxxxxxxxx), genau wie im CompanyFlex-Portal angezeigt. (aber nicht die "echte" Stammrufnummer des Trunks, sondern eben die aus dem CompanyFlex Portal
• Frage: Ist dieses Format korrekt, oder muss eine andere Schreibweise verwendet werden?
• Frage2: Ist das die richtige Rufnummer , mit der Stammrufnummer ist nämlich keine Anmeldung des Trunks möglich!

Authentifizierungs-ID (SIP-Nutzer-ID):​

• Wurde ebenfalls 1 zu 1 so übernommen, wie im CompanyFlex-Portal angezeigt. und wie die SIP-Trunk nummer
• Frage: Muss die Auth-ID vielleicht in einem anderen Format eingegeben werden?

Hauptnummer in 3CX ab V20 nicht mehr konfigurierbar?​

• Versuch, die Hauptnummer unter „Allgemein“ einzutragen, schlägt mit Fehler fehl.
• Frage: Ist es ab 3CX V20 nicht mehr nötig oder erlaubt, eine Hauptnummer für den Trunk zu setzen?

Trunk-Stammnummer vs. registrierte Nummer​

• Die Registrierungsnummer aus dem Telekom-Portal wurde als Hauptnummer verwendet.
• Zusätzlich wurde dann die "echte" Stammnummer des Trunks hinterlegt.
• Frage: War das korrekt, oder muss hier anders vorgegangen werden?

Rufnummernformatierung für ausgehende Anrufe:​

• KEINE spezifischen Formatierungsregeln im Trunk selbst gesetzt.
• Regeln für ausgehende Anrufe im Outbound Routinggetestet:
  • Mit und ohne Formatierungsregeln
  • E.164 (+49xxxxxxxxx)
  • 030xxxxxxxx
  • 0049xxxxxxxxx
• Ergebnis: Alle Varianten wurden mit Fehler 488 „Not Acceptable Here“ abgelehnt.
• Frage: Ist in 3CX eine spezielle Formatierungsregel notwendig?

Standardmäßige Rufnummer für ausgehende Anrufe:​

• Standard-Caller-ID getestet mit:
  • +4930xxxxxx
  • 030xxxxxx
  • 0-99 (wie häufig empfohlen)
• Frage: Welche Konfiguration ist hier korrekt?

Proxy-Server Konfiguration:​

• Ausgehender Proxy: 55.....primary.companyflex.de
• Alternativer Proxy: 55......secondary.companyflex.de
• Frage: Ist diese Einstellung korrekt?

SIP-Trunk Optionen:​

• „Konvertieren in E.164“: DEAKTIVIERT
• Globale E.164-Verarbeitung in 3CX: DEAKTIVIERT
• Frage: Sollte E.164 hier global aktiviert oder deaktiviert sein?

Parameter „Anrufer-ID-Kontrolle“ in SIP-Trunk:​

• Standardwerte sind gesetzt.
• Auch alternative Konfigurationen getestet.
• Frage: Muss hier eine spezielle Anpassung erfolgen?

---

Ziel:​

Wir benötigen eine klare Antwort darauf, wie 3CX korrekt mit Telekom CompanyFlex konfiguriert werden muss, damit ausgehende Anrufe funktionieren.

---

Falls jemand dieses Problem ebenfalls hatte und eine Lösung kennt, bitte gerne teilen!

Telekom & 3CX-Support:​

Falls sich jemand von 3CX oder Telekom mit diesem Setup auskennt – welche Konfigurationen oder Anpassungen sind erforderlich, um die Fehlermeldung 488 „Not Acceptable Here“ zu lösen?

 

[fxbastler]

Mein Wissen (bevor wir auch den letzten von dort wegportiert hatten):

1. ja
2. ja und nein
3. nein
4. nein, die ist nötig und wird benötigt Was genau kommt denn da für eine Fehlermeldung wenn die Trunk-Hauptnummer angegeben wird?
5. siehe 2. und 4. Die (Trunk-)Hauptnummer muss wirklich die Telefonnummer sein die angerufen werden kann.
6. Nein, nur E.164 in der 3CX deaktivieren und die üblichen ausgehenden Regeln für E.164 Telefonate verwenden (00, 0 und lokal)
7. +4930xxxxxx
8. wenn das so im Telekom Portal steht: ja
9. s.o.: E.164 in der 3CX global deaktivieren und das gewünschte Rufnummernformat mit den ausgehenden Regeln einstellen

Parameter Anrufer-ID-Kontrolle: da erst einmal nichts ändern. Das hat nichts mit ausgehenden Anrufen zu tun. Das betrifft ausschließlich eingehende Anrufe. Die funktionieren ja wohl.

Diese Anleitung kennst du und wurde umgesetzt?
https://www.3cx.de/docs/adminhandbuch/sip-trunks/deutsche-telekom-companyflex/

 

[fischeredv-mw]

5. siehe 2. und 4. Die (Trunk-)Hauptnummer muss wirklich die Telefonnummer sein die angerufen werden kann.

Das war es bei uns gewesen, ist nicht aufgefallen, da die OnPrem V18 an der Stelle über Telekom Anschluss rausging und das quasi irrelevant war.
Danke für die Zeit zu antworten

 

[fischeredv-mw]

Eine Sache ist noch auffällig bzw. ggf. weiß hier jemand wie es schnell lösbar ist.


Mit V20 wurde ja das Konzept der eingehenden Regeln durch die neue Anrufweiterleitung ersetzt
Nun werden Abteilungen statt Gruppen genutzt.
Wir haben diese Umstellung berücksichtigt und die Abteilungen entsprechend eingerichtet.
Dennoch scheint das aktuelle Routing nicht korrekt zu greifen, nur die Trunk-Hauptnummer im Format +49... scheint so zu funktionieren wir eingerichtet (auf eine Warteschleife) alle im Rufnummerblock verfügbaren DIDs laufen dort aber ebenfalls auf, statt in die Abteilung oder Nebenstelle selbst, der sie zugewiesen ist.


Die DIDs sind unter SIP-Trunks korrekt hinterlegt, dort steht allerdings „Nicht Zugeweisen“.
Unser Verständnis war, dass die DIDs direkt in den Nebenstellen oder über die neue Anrufweiterleitung zugewiesen werden, aber das scheint nicht wie erwartet zu funktionieren.

Daher

1. Hat jemand eine ähnliche Erfahrung bei der Migration gemacht und hat einen heißen Tipp?
2. Gibt es in V20 eine spezifische Stelle, an der bestehende DIDs angepasst oder übernommen werden müssen die ich übersehe?
3. Hat es mit der Rufnummerformatierung zu tun, dass die DIDs nicht richtig matchen und daher die Zuordnung nicht funktioniert?

Bin über jeden Tipp oder Hinweis dankbar

 

[bitn2]

Eine Sache ist noch auffällig bzw. ggf. weiß hier jemand wie es schnell lösbar ist.


Mit V20 wurde ja das Konzept der eingehenden Regeln durch die neue Anrufweiterleitung ersetzt
Nun werden Abteilungen statt Gruppen genutzt.
Wir haben diese Umstellung berücksichtigt und die Abteilungen entsprechend eingerichtet.
Dennoch scheint das aktuelle Routing nicht korrekt zu greifen, nur die Trunk-Hauptnummer im Format +49... scheint so zu funktionieren wir eingerichtet (auf eine Warteschleife) alle im Rufnummerblock verfügbaren DIDs laufen dort aber ebenfalls auf, statt in die Abteilung oder Nebenstelle selbst, der sie zugewiesen ist.


Die DIDs sind unter SIP-Trunks korrekt hinterlegt, dort steht allerdings „Nicht Zugeweisen“.
Unser Verständnis war, dass die DIDs direkt in den Nebenstellen oder über die neue Anrufweiterleitung zugewiesen werden, aber das scheint nicht wie erwartet zu funktionieren.

Daher

1. Hat jemand eine ähnliche Erfahrung bei der Migration gemacht und hat einen heißen Tipp?
2. Gibt es in V20 eine spezifische Stelle, an der bestehende DIDs angepasst oder übernommen werden müssen die ich übersehe?
3. Hat es mit der Rufnummerformatierung zu tun, dass die DIDs nicht richtig matchen und daher die Zuordnung nicht funktioniert?

Bin über jeden Tipp oder Hinweis dankbar

Nicht zugewiesen heisst, die sind nicht zugewiesen. Deswegen geht alles die standard Route. Wie sehen die ausgehenden Regeln aus? Hast du die Nummern in den Nebenstellen schon zugewiesen?

 

[fxbastler]

Die DIDs sind unter SIP-Trunks korrekt hinterlegt, dort steht allerdings „Nicht Zugeweisen“.
Unser Verständnis war, dass die DIDs direkt in den Nebenstellen oder über die neue Anrufweiterleitung zugewiesen werden, aber das scheint nicht wie erwartet zu funktionieren.

Das ist eine der Aufgaben nach der Umstellung einer 3CX von v18 auf v20: die Kontrolle und ggf. Zuweisung von eingerichteten DID auf 3CX Entitäten (Nutzer, RG, WS, IVR, Abteilung, Anrufskript usw.).
Das steht auch so im Leitfaden drin.
Das war im Prinzip auch die Hauptaufgabe bei all unseren Umstellungen: die Dokumentation aller eingehenden Regeln (insbes. wenn dort abweichende GZ angegeben wurden) vor der Umstellung und Kontrolle und Anpassung nach der Umstellung u.v.a.m..

Daher

1. Hat jemand eine ähnliche Erfahrung bei der Migration gemacht und hat einen heißen Tipp?

s.o.

1. Gibt es in V20 eine spezifische Stelle, an der bestehende DIDs angepasst oder übernommen werden müssen die ich übersehe?

Nein, das passiert automatisch mit Umstellung v18 auf v20 oder tlw. eben nicht. Eine gute Übersicht der quasi eingehenden Regeln erhält man unter erhält unter Admin / Berichte / System / eingehende Regeln.

1. Hat es mit der Rufnummerformatierung zu tun, dass die DIDs nicht richtig matchen und daher die Zuordnung nicht funktioniert?

Kann sein, muss nicht sein, musst man probieren. Wenn es vorher funktioniert hat dann sollte das immer noch so sein. Das ist auch eine der Aufgaben nach einer Umstellung.

edit: zu spät, mal wieder, ich schreibe zu langsam und auch ein klein wenig mehr

 

[bitn2]

Das ist eine der Aufgaben nach der Umstellung einer 3CX von v18 auf v20: die Kontrolle und ggf. Zuweisung von eingerichteten DID auf 3CX Entitäten (Nutzer, RG, WS, IVR, Abteilung, Anrufskript usw.).
Das steht auch so im Leitfaden drin.
Das war im Prinzip auch die Hauptaufgabe bei all unseren Umstellungen: die Dokumentation aller eingehenden Regeln (insbes. wenn dort abweichende GZ angegeben wurden) vor der Umstellung und Kontrolle und Anpassung nach der Umstellung u.v.a.m..


s.o.


Nein, das passiert automatisch mit Umstellung v18 auf v20 oder tlw. eben nicht. Eine gute Übersicht der quasi eingehenden Regeln erhält man unter erhält unter Admin / Berichte / System / eingehende Regeln.


Kann sein, muss nicht sein, musst man probieren. Wenn es vorher funktioniert hat dann sollte das immer noch so sein. Das ist auch eine der Aufgaben nach einer Umstellung.

edit: zu spät, mal wieder, ich schreibe zu langsam und auch ein klein wenig mehr

Aber dafür ausführlicher und genauer. ;-)