Erfahrungsbereicht: Telekom CompanyFlex keine ausgehende Anrufe

[julian72]

Hallo!

Das ist hier keine Frage oder bitte um Hilfe sondern ein Tip wie ich bei mir die Anlage wieder zum laufen gebrachte habe.
Ausgangsituation:
Eingehende Anrufe funktioniert tadellos.
Ausgehende wurden mit ein 403 FORBIDEN konsequent abgelehnt.

Mit Hilfe eines sehr Hilfsbereiter Telekomtechniker wurde festgestellt (per SIP-Tracing), dass bei mir das Feld PPI-User Part die Rufnummer ohne führendes + Zeichen sendet.
Vor kurzem soll ein Platformwechsl bei der Telekom bundesweit ausgerollt sein und daher muss man dies nun ändern - daher nun muss es mit + sein.
Bis Dato war das Feld "P-Preferred Identity : User Part" auf OutboundLineID gesetzt. Und bis 24.05. funtkinierte es damit auch raus zu telefonieren.
Nach dem das Feld auf "Caller Num caller's number (default: From->user)" umgestellt, funktionieren die ausgehende Anrufe wieder.

Das ist womöglich nicht die beste Lösung! Aber bei mir funktioniert sie (vorerst ;-).

Vielleicht hilft das hier jemand weiter mit einem ähnliches Problem?

 

[ThePhil]

Hey

ich habe aktuell auch das Problem und bekomme es trotz Techniker nicht hin, dass die Ausgehende Telefonie wieder richtig funktioniert oder eher, dass sie funktioniert.

Ich dachte eben, dass Dein Lösungsansatz das Problem löst, ist leider nicht so
Ich hatte das Feld eben angepasst, aber leider wird das Telefonat wieder mit 403 Forbidden abgebrochen.

Welches Trunk Template verwendest Du?
Das "richtige" für Company Flex oder das modifizierte NGN?

Viele Grüße
Philipp

 

[julian72]

Ich habe das für CompanyFlex benutzt. Jetzt mache ich mir Sorgen, dass die Lösung dann evtl. nur von kurzer Dauer sein wird.
Übrigens, nach der Änderung hat es bei mir auch nicht sofort gegriffen. Ich schätze erst nach 2-3 Minuten.

 

[ThePhil]

Mmh, komisch...

Ich hatte eben gesehen, dass bei mir eine andere Einstellung krumm war und ich wohl heute mal kurz die Option "Request Line URI : Host Part" verstellt hatte und hatte sie dann wieder auf den Ursprungswert gestellt, aber leider war das nicht der Übeltäter.

Lassen wir uns mal überraschen, vielleicht kommt ja in der nächsten Zeit ein Update für das Trunk Template, schön wäre es ja

Das komische ist, bis gestern hat alles ohne Probleme funktioniert und dann ab ca. Mitternacht ging es nicht mehr...
Da hat die Systemumstellung bei uns dann zugeschlagen.

Bevor ich es vergesse, mich hatte der Techniker auf die Spezifikation 1TR119 der Telekom hingewiesen...

https://www.telekom.de/hilfe/downloads/1tr119.pdf

 

[julian72]

In der Tat. Aber vielleicht ist bei Ihnen nur eine vorübergehende Störung die Ursache?
Bei mir war schon der Telekomtechniker ganz klar und deutlich: PPI-Header Falsch wegen fehlende + am Anfang der Nummer.
Hier in Forum gab es schon mal Fälle wo 403 kam und es lediglich an eine Störung lag. ;-)

Ja, die Datei habe ich per Google auch gefunden. Die mit den Einstellungen von 3cx abzugleichen fällt mir etwas schwer wg. den einerseits englischen Begriffen in den Ausgehende Regel im Trunk und andererseits die deutsche Bezeichnung der Parameter auf der Rest der Webseite der PBX. (Und ich versuche es mi zu verkneifen, nicht ganz an letzte Stelle. ;-)

 

[3cx2]

... hat jemand eine Lösung für das Problem gefunden?
Die Telekom und folgendes geschickt:

Beispiel für falschen Contact-Header, woraufhin die nIMS-Plattform das INVITE mit Responce 403 (Forbidden) ablehnt.
Im Contact-Header muss die Pilotnumber (Registrierungsrufnummer) und nicht die Ursprungsrufnummer hinterlegt sein.
 
Falsch: Contact: sip:[email protected]:5066;transport=tls
 
Richtig: Contact: sip:[email protected]:5066;transport=tls

- Im User-Part des Contact Header wird NICHT die Registrierungsrufnummer verwendet
- Im Host-Part der R-URI oder der Header From, To, P-Asserted-Identity und P-Preferred-Identity wird NICHT die korrekte SIP-Domäne
(tel.t-online.de) verwendet
- Im Via Header oder im Host-Part des Contact Header wird STATT der Interface-IP-Adresse die SIP-Domäne (tel.t-online.de)
verwendet

 

[ThePhil]

... hat jemand eine Lösung für das Problem gefunden?
Die Telekom und folgendes geschickt:

Leider nicht bisher, ich warte seit 11 Uhr auf Rückmeldung von der Telekom. Hintergrund ist/war, dass dem Mitarbeiter das ganze komisch vorkam und er sich dann bei mir melden wollte.
Und natürlich, wer hätte es gedacht, bisher keine Reaktion.

Die abrupte Umstellung von der "alten" Plattform auf die neue finde ich nicht so super - man hätte es zu mindestens ankündigen können - so ist aber aktuell totales Chaos aus der Geschichte geworden.

Die Konstellation bei mir sieht so aus, dass eine FritzBox vor der 3CX sitzt, zur Not binde ich den Trunk erstmal bei der FB ein und gebe den an die 3CX weiter, auch wenn es nicht schön ist.

Langfristig will ich mit dem Trunk weg von der Telekom, wir hatten in dem letzten Jahr einige Probleme mit dem Trunk (z.B. versprochene Kostenreduzierung oder einfach von dem DeutschlandLAN Trunk auf den Company Flex 2 Tage früher umgestellt wie vereinbart).

Aber ich schweife ab
Wenn jemand eine Lösung für das Problem hat, immer her damit

 

[d.leidenheimer]

Bei mir war es auch der Contact Header.
Das sieht man leider in der Schnittstellenbeschreibung auch nur schlecht, aber die wollen dort die Authentifizierungs-ID mit der Lokalen IP Adresse der Anlage haben und schon ging das Raus rufen wieder.

 

[ThePhil]

Anscheinend stehe ich entweder auf dem Schlauch oder irgendwas anderes ist noch bei mir verkehrt.

Ich habe die Einstellungen wie von @d.leidenheimer beschrieben angepasst, aber leider geht der Ruf immer noch nicht raus und wird mit einem 403 abgelehnt...

Was hast Du als Port genommen? Ich hatte proforma :5060 genommen gehabt.

Edit, ich habe es zum laufen bekommen.

Den Host-Part von Contat Header musste nicht anpassen, bei mir ging es mit "GWHostPart".

 

[avraammich_3CX]

Hi ThePhil.

ich würde dir gerne helfen

Kannst du mir in PM bitte schreiben.

 

[cibra]

Wir haben seit heute auch das Problem, leider haben die Anpassungen bei uns nicht geholfen:


und

Hab ich noch was vergessen?

Danke schon mal für Tipps.

 

[avraammich_3CX]

hi cibra,

kannst du mir PM senden damit ich dir helfen kann.

 

[cibra]

@avraammich_3CX danke für das Angebot, wir haben es gerade mit Wireshark selber hinbekommen.
Egal was wir konfigurieren hatten, es wurde immer der FQDN der 3CX im contact header übertragen, was die Telekom nicht mag. Da kommt beim REGISTER gleich das forbidden.

Folgende Einstellung hat dann zum Ziel geführt:

 

[p4x]

@avraammich_3CX danke für das Angebot, wir haben es gerade mit Wireshark selber hinbekommen.
Egal was wir konfigurieren hatten, es wurde immer der FQDN der 3CX im contact header übertragen, was die Telekom nicht mag. Da kommt beim REGISTER gleich das forbidden.

Folgende Einstellung hat dann zum Ziel geführt:
Anhang anzeigen 8794

Hey @cibra , schon einmal danke für den hilfreichen Beitrag! :3

Ich habe noch eine Frage zu den Ausgangsparametern (Contact: User/Host Part).
Welche Parameter habt ihr dort eingetragen?

Im Anhang mal ein Screenshot von unserer Konfiguration.

//EDIT: Sorry, habe gerade gesehen, dass du in deinem vorherigen Post die Conf. gepostet hast. Habt ihr diese soweit beibehalten?


Viele Grüße!

 

[cibra]

Hey @cibra , schon einmal danke für den hilfreichen Beitrag! :3

Ich habe noch eine Frage zu den Ausgangsparametern (Contact: User/Host Part).
Welche Parameter habt ihr dort eingetragen?

Im Anhang mal ein Screenshot von unserer Konfiguration.


Viele Grüße!

//EDIT: Sorry, habe gerade gesehen, dass du in deinem vorherigen Post die Conf. gepostet hast. Habt ihr diese soweit beibehalten?

Hey p4x,
da mussten wir Anpassungen vornehmen, ich habe das mit Wireshark immer wieder getestet und letztendlich folgende Konfiguration jetzt, welche auch bisher funktioniert. Das ganze hatte ich mit dem Beispiel in der Schnittstellenbeschreibung immer abgeglichen (https://www.telekom.de/hilfe/downloads/1tr119.pdf Punkt 12.2).
Die Nummer unter Contact: User Part ist diese lange AuthID und "nicht" die Telefonnummer.
Weiterhin war noch das Problem, dass die 3CX immer ihren FQDN mitgesendet hat, was die Telekom auch nicht will, daher musste ich unter Optionen folgendes anpassen (die private IP der 3CX eintragen):


Hier alle Parameter:

 

[p4x]

@cibra
Super, vielen lieben Dank für die ganzen Infos!!1
Wir haben leider auch das Problem mit dem FQDN im Header, der Rest sollte soweit richtig nach 1TR119 eingestellt sein.

Werde gleich die Settings mal ausprobieren, vielen Dank nochmal!

 

[cibra]

@p4x das ging bei uns erst weg, nachdem wir die interne IP unter den Optionen selbst gesetzt hatten. Danach war auch der 403 forbidden verschwunden und es konnte wieder telefoniert werden.

 

[sitsolutions]

Hey p4x,
da mussten wir Anpassungen vornehmen, ich habe das mit Wireshark immer wieder getestet und letztendlich folgende Konfiguration jetzt, welche auch bisher funktioniert. Das ganze hatte ich mit dem Beispiel in der Schnittstellenbeschreibung immer abgeglichen (https://www.telekom.de/hilfe/downloads/1tr119.pdf Punkt 12.2).
Die Nummer unter Contact: User Part ist diese lange AuthID und "nicht" die Telefonnummer.
Weiterhin war noch das Problem, dass die 3CX immer ihren FQDN mitgesendet hat, was die Telekom auch nicht will, daher musste ich unter Optionen folgendes anpassen (die private IP der 3CX eintragen):
Anhang anzeigen 8815

Hier alle Parameter:

Anhang anzeigen 8814

Das war unsere Rettung! Vielen Dank cibra

 

[SaschaKratz]

Hallo,
bei uns leider auch nach der Anleitung ohne Erfolg. Diese auch so tolle Telekom. Kommend funktioniert soweit. Gehende leder immer noch mit dem gleichen Fehler. Call or Registration to +49xxxxxxxxx@(Ln.10000@Deutsche Telekom (CompanyFlex)) has failed. 217.0.149.208 replied: 403 Forbidden; from IP:217.0.149.208:5060 Die "Firewall" ist mittlerweile nur noch eine FritzBox mit Exposed Host. Wir versuchen uns erst seit 10 Stunden mit dem Problem....

 

[SaschaKratz]

3CX meinte nun die 3CX macht alles richtig. Muss an Telekom liegen. Telekom sagt es liegt an 3CX, trotz Wireshark Protokoll, und ja bei anderen Kunden läuft der SIP Trunk (CompnayFlex) der Telekom, nur bei diesem Kunden leider nicht.