Verbindungsprobleme alle paar Tage: Call has failed. Forbidden (403)

[Opt-it]

Guten Tag liebe Leute.

Ein Kunde ist seit einiger Zeit wiederholt nicht zu erreichen. Eingehend und Ausgehend sind keine Anrufe möglich.

Im Ereignisprotokoll kommt folgende Warnung:
Call or Registration to 0178xxx@(Ln.10001@+4930xxx) has failed.
sip:217.x.x.x:5060;lr replied: Forbidden (403)

Es betrifft einen Telekom Trunk.
Dieser Trunk ist allerdings nicht der einzige Telekom Trunk, die anderen funktionieren tadellos.

Die Zugangsdaten für den Trunk sind korrekt.
Die Authentifizierung entspricht den 3CX Anleitungen.
Die Trunks sind laut 3CX alle registriert.

3CX ist OnPremise Version 20.0 Update 8 (Build 1121 Beta).
Es läuft auf einem Windows Server 2019.

Nach einem Neustart des SIP Server Dienstes ist für 1-2 Tage erstmal Ruhe.

Vielleicht hat jemand von Euch eine Idee woran es liegen könnte.

 

[avraammich_3CX]

Hi @Opt-it,

das 403 Forbidden bekommst du von der IP 217.x.x.x
Das ist die Telekom.
Hast du schon den provider kontaktiert?

Weiterführend bitte update 3CX Anlage auf dem aktuellen Stand V20 U9 und beobachte das Verhalten, da V20 U9 schon ein Fix beinhaltet bezüglich 403 Forbidden.

 

[bitn2]

Wie sind die Codecs eingestellt? Ganz wichtig, wie schon gesagt, die Anlage mal aktualisieren.

 

[Opt-it]

Danke so weit - nach dem Update werden wir wieder berichten und ggf. weitergehende Infos posten (Codecs) sowie bei der Telekom vorstellig werden.

 

[mbehrens]

3CX ist OnPremise Version 20.0 Update 8 (Build 1121 Beta).

 

[Opt-it]

Die betreffende Anlage wurde aktualisiert auf Version 20.0 Update 9 (Build 995 Release).
Aktuell tritt die Meldung dort noch nicht wieder auf.

Die Meldung tritt inzwischen jedoch auch auf einer anderen Anlage auf, von 3CX gehostet Version 20.0 Update 9 (Build 995 Release - AI 1.4.48), mit Easybell als Trunk Anbieter.
Bisher lässt sich das Problem für einige Zeit lösen indem der SIP Server neu gestartet wird.

Die betreffenden Trunks sind von unterschiedlichen Anbietern.

 

[bitn2]

Die betreffende Anlage wurde aktualisiert auf Version 20.0 Update 9 (Build 995 Release).
Aktuell tritt die Meldung dort noch nicht wieder auf.

Die Meldung tritt inzwischen jedoch auch auf einer anderen Anlage auf, von 3CX gehostet Version 20.0 Update 9 (Build 995 Release - AI 1.4.48), mit Easybell als Trunk Anbieter.
Bisher lässt sich das Problem für einige Zeit lösen indem der SIP Server neu gestartet wird.

Die betreffenden Trunks sind von unterschiedlichen Anbietern.

Prüfe mal on als registrar noch sip.easybell.de drin steht. Wenn ja, auf voip.easybell.de umstellen.

 

[Opt-it]

Prüfe mal on als registrar noch sip.easybell.de drin steht. Wenn ja, auf voip.easybell.de umstellen.

Das ist mir dort gar nicht aufgefallen. Vielen Dank!

 

[bitn2]

Das ist mir dort gar nicht aufgefallen. Vielen Dank!

Die Kunden wurden darüber informiert, die wiederum aber nicht uns... Hatten das Problem auch.

 

[MyNameisZander]

Wir beobachten dieses Verhalten derzeit bei einigen Kunden nach der Umstellung auf Update 9 (U9) – primär in Verbindung mit Anschlüssen von Telekom Company Flex und Easybell.
Ein Neustart des SIP-Dienstes schafft hierbei temporäre Abhilfe. Wir analysieren die Problematik aktuell...

 

[bitn2]

Wir beobachten dieses Verhalten derzeit bei einigen Kunden nach der Umstellung auf Update 9 (U9) – primär in Verbindung mit Anschlüssen von Telekom Company Flex und Easybell.
Ein Neustart des SIP-Dienstes schafft hierbei temporäre Abhilfe. Wir analysieren die Problematik aktuell...

Easybell bitte mal prüfen ob der Registrar noch auf sip.easybell.de steht, wenn ja, umstellen auf voip.easybell.de

 

[MyNameisZander]

Easybell bitte mal prüfen ob der Registrar noch auf sip.easybell.de steht, wenn ja, umstellen auf voip.easybell.de

Danke dir, das hatten wir auf dem Schirm - die Mail von Easybell mit den Parameteränderungen ist bei uns auch angekommen
Wir hatten jetzt als alternatives Beispiel noch eine externe Anlage eines Kudnen mit sip.easybell.de, konnten aber keinen Unterschied feststellen.
In beiden Szenarien war ein manueller Neustart des SIP-Dienstes nötig.
Es sind aber nicht alle Anlagen, aber alle haben U9 als Update installiert.
5x CoFlex
3x Easybell (2x voip.easybell, 1x sip.easybell)

Telekom gibt Forbidden (403) aus, Easybell zeigt keine sichtbare Fehlermeldung.
Das Problem betrifft in unserer Analyse nur ausgehende Anrufe – eingehend funktioniert alles weiterhin.

 

[Stephan von NP]

Wir haben bei verschiedenen Kunden (selbstgehostet und hosted by 3CX) auch ständige Probleme mit easybell. Wir haben auf voip.easybell.de umgestellt und danach wurden die Probleme nur größer. Wieder zurück zu sip.easybell.de ist zwar nicht zu empfehlen, aber dann kann man wenigstens wieder Telefonieren. Kann es sein, dass es Probleme mit der Providervorlage gibt? Überall ist Update 9 installiert.

 

[MyNameisZander]

Wir haben bei verschiedenen Kunden (selbstgehostet und hosted by 3CX) auch ständige Probleme mit easybell. Wir haben auf voip.easybell.de umgestellt und danach wurden die Probleme nur größer. Wieder zurück zu sip.easybell.de ist zwar nicht zu empfehlen, aber dann kann man wenigstens wieder Telefonieren. Kann es sein, dass es Probleme mit der Providervorlage gibt? Überall ist Update 9 installiert.

Ich glaube das Problem ist tieferliegend, entweder irgendetwas in der Vorlage oder der 3CX SIP Service in Verbindung mit den Änderungen mit Update 9 - wir haben die Probleme mit beiden Hostnames (SIP und VOIP)
Neustart des SIP Dienstes behebt das Ganze temporär... egal welcher Hostname von Easybell verwendet wird.
Ich melde mich, sobald unsere Analyse abgeschlossen ist.

 

[Stephan von NP]

Danke, aber ich sehe erstmal 3cx in der Plicht hier ein Statement abzugeben.

 

[bitn]

Wenn keiner ein Ticket aufmacht wird da wohl nichts passieren. Man müsste halt auch den Zustand so lassen damit überhaupt einer was sehen kann bei der Analyse, was bei Kunden natürlich wiederum schwierig ist.
Bei der Telekom trat das Problem sporadisch schon vor U9 bei uns auf. Neu ist das Problem bei easybell das kannten wir vor U9 nicht.

 

[MyNameisZander]

Wenn keiner ein Ticket aufmacht wird da wohl nichts passieren. Man müsste halt auch den Zustand so lassen damit überhaupt einer was sehen kann bei der Analyse, was bei Kunden natürlich wiederum schwierig ist.
Bei der Telekom trat das Problem sporadisch schon vor U9 bei uns auf. Neu ist das Problem bei easybell das kannten wir vor U9 nicht.

Ich gehe davon aus das wir morgen eines eröffnen aber dafür muss unser interner Prozess erstmal abgeschlossen werden - weil Bronze Partner keine kostenlosen Tickets haben wird halt bei uns alles individuell bewertet, da monetärer Aufwand. Ich halte euch auf dem laufenden.

 

[patrickb]

Ich gehe davon aus das wir morgen eines eröffnen aber dafür muss unser interner Prozess erstmal abgeschlossen werden - weil Bronze Partner keine kostenlosen Tickets haben wird halt bei uns alles individuell bewertet, da monetärer Aufwand. Ich halte euch auf dem laufenden.

Das Re-Registrieren sollte schon ausreichen. An sich könnt ihr mehrere Sachen im Template testen. Checkt auch mal bei EB wo sie was erwarten Nach der Umstellung sind da teilweise aktive Einstellungen auf der Strecke geblieben.

Wenn Auth im PAI erledigt wird, kannst du im From Clippen, wenn im From der Auth erfolgt kannst du im PPI clippen. Standard sollte From Display Name sein und Auth im PAI. EB ist da manchmal zickig und gerade bei Outbound kann das ein Thema sein. Wenn ihr mal schnell die Parameter checken oder ändern wollt ohne U9 Template Editor -> check mal meine Signatur

Alternativ: Den Trunk schonmal testweise neu angelegt? Das hilft auch manchmal und ist effizienter als ewige Fehlersuche.

 

[Stephan von NP]

Wenn jemand ein Ticket aufmachen möchte, dann nehmt bitte eine hosted by 3CX Anlage. Ich habe den Fehler gemacht, dass wir unsere selbstgehostete verwendet haben. Nun möchte der 3CX Support irgendwelche Logdateien aus den Tiefen des Linux. Für uns kaum stemmbar.

 

[bitn2]

Wenn jemand ein Ticket aufmachen möchte, dann nehmt bitte eine hosted by 3CX Anlage. Ich habe den Fehler gemacht, dass wir unsere selbstgehostete verwendet haben. Nun möchte der 3CX Support irgendwelche Logdateien aus den Tiefen des Linux. Für uns kaum stemmbar.

Wo ist das Problem? Der Support sagt dir doch wo und was du ihm liefern sollst?