3cx re-register timer verändern?

[Tom Z]

Hallo,

kann man, wenn ein SIP-Trunk aus irgendeinem Grund ausfällt, den Timer von 120 Sekunden auf einen niedrigeren Wert verändern?

Konkret scheint eine 3cx-Installation bei einem Kunden ein Problem zu haben und unregelmäßig einfach kein REGISTER schicken.
Ich hab das Problem jetzt bis in die 3cx logs analysiert und mich mit Sniffern auf die Interfaces/Geräte zw. 3cx und SIP-Trunk gehängt.

Die 3cx versucht den Trunk neu zu registrieren, glaubt jedoch in der selben Millisekunde der Trunk ist nicht mehr erreichbar.
Auf Netzwerkebene erzeugt das ein Re-REGISTER Loch von 120 Sekunden, die sich durch den entsprechenden Timer ergeben.
Diesen sieht man jedoch nur im Logfile.

Gibt es irgendeine Möglichkeit diesen Timer runter zu setzen, damit der Trunk nicht (so lange) ausfällt?
Also den Timer, welcher für diese LOG-Zeile verantwortlich ist:

Line 10000: Request for registration in 120000 ms

Langfristig werde ich natürlich eine Alternative suchen, aber jetzt kurzfristig brauche ich diese Lösung.

 

[fxbastler]

Hallo,

in jedem SIP Trunk kann man doch unter Optionen das Zeitlimit für Neuanmeldung reduzieren, auch auf sehr niedrige Werte. Reicht oder funktioniert das nicht? Dazu muss ich noch anmerken: es ist nicht unbedingt von Vorteil die Zeit manuell weit zu verringern. Der Provider sollte entspr. Angaben bereithalten was er da erwartet. Dann zu einer Gegenfrage: Ist das kein von 3CX unterstützter SIP Trunk?

 

[Tom Z]

Der Wert in der GUI ist nicht der von mir angesprochene Wert.

Ich rede von dem Zeit-Wert der in der 3cx dafür sorgt, dass sie 120s wartet nach einem 408 bis die Verbindung erneut versucht wird aufzubauen. Vermutlich irgendwo in einem Config-File, dass man nicht über die GUI konfigurieren kann.

Hatte eigentlich gehofft die 3cx ist so idiotensicher, dass ich damit keine Arbeit habe, weil ich damit auch de facto nix verdiene. Schon gar nicht, wenn ich irgendwelche Bugs finde, die ich dann nicht mal umgehen kann.

 

[fxbastler]

Na dann such doch mal in den Parametern nach 120

 

[fxbastler]

Die 3CX hat Eigenarten, ein festgelegtes Konzept des Funktionierens und Bugs, ja, wie alle anderen PBX auch. Aber im Großen und Ganzen - wenn nicht grad wieder generic changing update kommen - überwiegen die Vorteile (wenn ich sehe was andere da abliefern und wie die reagieren).

Es gibt nichts was idiotensicher ist. "If you make something idiot-proof, someone will just make a better idiot."

Wenn du nix daran verdienst und ich deine Reaktion richtig deute dann machst du das nicht nur kostenlos sondern umsonst. Dann kann ich nur empfehlen: sein lassen.

 

[Tom Z]

Also Parameter gefunden - auf 1 Sekunde gestellt.

Folgende Änderung im Verhalten.

Sekunde 0: 3cx glaubt ein 408 zu bekommen und entfernt die bestehende Registrierung.
Wir erinnern uns: Der 408er ist nicht im Netzwerk sichtbar, er passiert nur auf der Anlage, der Hypervisor, Switch, Router, die Firewall und der Provider sehen völlig normalen SIP-Verkehr.
Nur die 3cx glaubt, dass die Session ausgetimed ist.

1 Sekunde Später: 3cx versucht erneut eine Verbindung aufzubauen, weil ich ja den Timer auf 1s gesetzt hab.
Ergebnis: 403 vom Provider - logisch.
Provider wundert sich, wieso plötzlich eine neue Session daher kommt, obwohl die alte ja noch steht.

Danach:
Timer von 5 Minuten wird aktiv, den ich bisher nicht in der Anlage zum Konfigurieren finden konnte.

Zertifizierter Provider hin oder her, wenn eine Software aus dem nichts und ohne erfindlichen Grund in ein Timeout läuft (ich kann sogar die Code-Zeile benennen, die diesen Zustand auslöst), welches sie dazu bringt eine völlig gemäß Standard funktionierende Verbindung einseitig und ohne jegliche Info an die Gegenstelle abzubauen, dann ist das ein Fehler.

22.12.2020 20:51:04:231 | 8 | Reg. request-retry: h=609630; code=408

Level = 5
Severity = Trace
Tread = 8
Source = /home/repomaster/workspace/Releases/16.0.SP7/Sources/Projects/PbxServer/src/Registrar.cpp, line:873

Innerhalb der selben Millisekunde wird ein request-retry versucht, als "failure" geloggt und der Trunk abgebaut. Es ist physikalisch gar nicht möglich, dass die Antwort so schnell zurück gekommen wäre.

Nochmal mein Angebot: Ich zeige dieses Verhalten und Logfiles inkl. PCAPs einem Entwickler.
Bitte um Reaktion durch fachkundiges Personal.