Sporadisch Probleme mit ausgehenden Rufen - 400 invalid route

[bkr]

Guten Tag,

ich nutze 3CX an einem VOIP-Anschluss der EWE (dynamische IP). Ich habe einen SIP-Trunk für meine Rufnummer konfiguriert. Dieser verbindet sich auch und wird als grün angezeigt. Eingehende und ausgehende Rufe sind problemlos möglich. Nach einiger Zeit kann es jedoch passieren, dass ich nicht mehr raus wählen kann. Eingehende Rufe sind hingegen weiterhin möglich und der Trunk wird auch als grün angezeigt. Wenn ich den Trunk manuell deaktiviere und wieder aktiviere funktioniert es wieder. Anbei ein Wiresharkauszug eines fehlgeschlagenden Wahlversuchs, der zeigt, dass die EWE wiederholt eine Authentifizierung anfordert und dann abbricht. Bei einem Wireshark-Auszug eines funktioniernden Call kommt statt dem zweiten "Proxy Authentication Required" ein "Ringing". Es funktioniert also grundsätzlich. Die 3CX befindet sich hinter einem Route mit NAT, der jedoch alle benötigten Ports an die 3CX weiterleitet. (Firewall-Check der 3CX ist grün und eingehende Rufe funktionieren immer)

Leider verweigert die EWE jede Kooperation und auch die Herausgabe weiterführender Logs. Ich denke der Fehler liegt aber klar bei der EWE oder kann ich noch auf meiner Seite Abhilfe schaffen?

Vielen Dank für die Hilfe.

NACHTRAG:

Ich weiß nicht, ob es damit überhaupt im Zusammenhang steht, aber heute Nacht war laut logs die Internetverbindung kurz weg. (Zwangstrennung?) Zur selben Zeit steht folgende Zeile in Log: "Registration failed for: [...] Cause: Cause: 400 Missing Authorization header field/REGISTER from". Was aber seltsam ist: Der Trunk war grün, eingehende Rufe gingen und ein manuelles deaktivieren/aktivieren des Trunk löst das Problem. Der Header wird also wohl grundsätzlich gesendet.

 

[bkr]

Die Meldung aus dem Nachtrag scheint nichts mit dem Problem zu tun zu haben. Ein Reconnect erzeugt immer diese Meldung, allerdings wird bei detailliertem Log nach 5min ein Erfolg bestätigt. Ausgehende Rufe funktionieren auch unmittelbar nach einem Internetverlust

 

[fxbastler]

Hallo,

Fragen:

1. Was für eine 3CX wird benutzt (Version + Ausführung, z.B. Debian, 18 u6 build 908, 8 SC pro)?
2. Wo ist diese 3CX installiert (physisch, virtuell, welche Hardware und ggf. welcher Virtualisierer wird benutzt)?
3. Gab es zu diesem Zeitpunkt je einen Wechsel der öffentlichen IP?
4. Ist deine im obigen Log auftauchende öffentliche IP die zu diesem Zeitpunkt wirklich aktuelle öffentliche IP und steht diese in diesem Moment auch so im Dashboard der 3CX?
5. Gibt es einen absehbaren Rhythmus für solche wiederholten Probleme?
6. Lässt sich sich das Problem auch lösen (innerhalb rd. 5 min), indem der Router vorn dran rd. 10 sek. gezielt stromlos gemacht wird?

 

[bkr]

1. Was für eine 3CX wird benutzt (Version + Ausführung, z.B. Debian, 18 u6 build 908, 8 SC pro)?

18.0.6.908 Standard Debian

1. Wo ist diese 3CX installiert (physisch, virtuell, welche Hardware und ggf. welcher Virtualisierer wird benutzt)?

Es ist physischs auf einem Twitter Mini pc TT2883 installiert

1. Gab es zu diesem Zeitpunkt je einen Wechsel der öffentlichen IP?

Kann ich nicht genau sagen, ist aber gut möglich. Ein reiner Wechsel der IP löst das Problem aber nicht reproduzierbar aus.

1. Ist deine im obigen Log auftauchende öffentliche IP die zu diesem Zeitpunkt wirklich aktuelle öffentliche IP und steht diese in diesem Moment auch so im Dashboard der 3CX?

Das habe ich leider nicht überprüft und das Problem ist noch nicht wieder aufgetreten.

1. Gibt es einen absehbaren Rhythmus für solche wiederholten Probleme?

Leider nicht

1. Lässt sich sich das Problem auch lösen (innerhalb rd. 5 min), indem der Router vorn dran rd. 10 sek. gezielt stromlos gemacht wird?

Werde ich beim nächsten Auftreten testen.

 

[bkr]

Das Problem war wieder da. Die öffentliche IP in der 3cx ist korrekt und ein Router Neustart bringt keine Besserung

 

[bkr]

Die Logs enthalten gelegentlich folgende Meldung die ich nicht erklären kann.

01.03.2023 06:48:08 - [CM306002]: There is no valid STUN server specified! External IP can not be resolved.

Es passiert nicht bei jedem Stun request und die IP in der 3cx wird korrekt angezeigt. Also vermutlich ein separates Problem.

 

[bkr]

 

[fxbastler]

Es passiert nicht bei jedem Stun request und die IP in der 3cx wird korrekt angezeigt. Also vermutlich ein separates Problem.

In einer 3CX mit dynamische öffentlicher IP sind i.d.R. 3 verschiedene STUN Server hinterlegt. Es kann schon vorkommen, dass mit den Standardwerten mal einer zeitweilig nicht antwortet oder die 3CX (auf Grund eines Loadbalancers?) feststellt, dass mehrere STUN Server auf das gleiche Ziel verweisen. So lange das kein permanentes Problem ist, hat das keine derartigen Funktionsstörungen zur Folge. Wir haben z.B. stun-eu.3cx.com, stun.t-online.de und stun.sipgate.net je alle 360 s. drin stehen - ohn derartige Fehler.

Frage: Ist in der 3CX IPv6 irgendwo aktiv? Wenn ja: abschalten.

Für die weitere Fehlersuche braucht man vmtl. einen kompletten Protokollmitschnitt der 3CX zur Analyse, evtl. gar ein Support Dateipaket. Insbesonders wegen der kompletten Aushandlung und der Meldungen der 3CX. Entweder selber durchsteigen oder den 3CX Partner bemühen. Der holt ggf. den 3CX Support dazu

 

[bkr]

Ich konnte 3 Konditionen ermitteln, unter denen das Problem auftritt:

1.) Source-Port wechselt zwischen dem Register und den Invite
2.) Source-IP im Register ist eine andere als im Invite
3.) Zwei Register, die zu schnell hintereinander passieren. (Z.B. Nachdem der Trunk von 3CX als unregistered erkannt wird)

(Zu 1 und 2 ist nicht nur die tatsächliche IP: Port Kombi relevant, sondern auch die Angabe im via Header. Diese muss bei Register und Invite identisch sein)

Nr. 1 kann es nicht sein, da ich einen statischen Port im outbound NAT habe.

Um die Gefahr von Nr. 2 zu reduzieren, habe ich das STUN Interval auf 30s gesetz, in der Hoffnung, dass er dann nicht versehentlich die alte IP für das Register nutzt.

Wie ich Nr. 3 verhindern kann, habe ich leider noch nicht herausgefunden, wobei ich auch nicht weiß, ob es hier die tatsächliche Ursache ist.

IPv6 ist nicht aktiviert.

 

[fxbastler]

Um die Gefahr von Nr. 2 zu reduzieren, habe ich das STUN Interval auf 30s gesetz, in der Hoffnung, dass er dann nicht versehentlich die alte IP für das Register nutzt.

Wird evtl. nicht reichen.

Wie ich Nr. 3 verhindern kann, habe ich leider noch nicht herausgefunden, wobei ich auch nicht weiß, ob es hier die tatsächliche Ursache ist.

Wir würden in so einem Fall die Überwachung anziehen: die des Routers davor, evtl. dazwischenliegender / das Thema auch betreffender Geräte und natürlich der 3CX. Geht z.B. wunderbar mit Zabbix, eventuell die Abfragerate erhöhen. Zudem noch einige selbstgebastelte Skripte auf der 3CX oder von extern für deren Status und es wird sich sicher ein Muster abzeichnen. So kann man auch Mitschnitte auf mehreren Geräten automatisch erzeugen.

Wenn das Problem nicht reproduzierbar ist, sich durch Tausch (ggf. Vereinfachung) von Hardware, durch Neuinstallation und Einrichtung von Software und durch testweise Wechsel der Anbieter nicht lösen lässt, dann wird das der einzige Weg bleiben.

 

[bkr]

Ich bin sehr zuversichtlich, dass Nr. 2 das Problem zumindest abschwächen kann. Seit der Anpassung hatte ich keine Fehler mehr.

Das größte Problem ist meiner Ansicht nach, dass der via Header von Register und Invite identisch sein muss. Leider scheint es wohl so, dass die Zwangstrennung des Providers zu einem neuen Register der 3CX führt, aber es ist wohl nicht sichergestellt, dass das Stun-Update vorher auch tatsächlich erfolgreich durchgeführt wird.

Eine Config, die ein Stun-Update vor einem Register erzwingt, wäre super.

 

[bitn2]

Einer der Nachteile einer dynamischen IP.... Es braucht immer einen Moment bis sich die IP aktualisiert hat.

 

[bkr]

Wäre kein Problem, wenn die 3CX immer einen STUN vor dem Register ausführt. So eine Config-Option wäre doch ein super Feature-Request.