SBC Verbindungsabbrüche

[AndiHB]

Hallo,

ich habe ein paar Probleme mit der Standort-Anbindung über einen Raspberry SBC.

Die Verbindung vom SBC zur Anlage kann problemlos aufgebaut werden, nach einigen Minuten (i.d.R. 6-10 Minuten) bricht die Verbindung aber ab und wird neu aufgebaut.
Dabei werden auch Telefonate unterbrochen. Das Phänomen tritt sowohl über einen lokalen Internet-Anschluss, als auch über einen UMTS-Router auf.
In der Übersicht der SIP-Trunks in der 3cx erscheint dann auch eine Zeit bei "Anmeldung fehlgeschlagen".
Im Aktivitätsprotokoll ist nichts dazu zu sehen.

Die 3cx ist Debian, selbstgehostet. Der Firewalltest ist ok.

Was kann hier die Ursache sein bzw. wie bekommt man die SBC-Verbindung stabil?

 

[AndiHB]

Ich habe das Problem mittlerweile genauer untersucht und weitere Tests vorgenommen:

Die SBC-Verbindung ist selbst im LAN nicht stabil, d.h. die Firewall und Port-Forwards kommen nicht in Frage. Da es zwei unterschiedliche Raspberry SBCs betrifft und auch schon eine Neuinstallation eines SBC vorgenommen wurde, scheint das auch nicht der Fehler zu sein.

Die Installation läuft auf einem Hyper-V Host (Server 2019). Im Rahmen der Versuche wurde auch bereits ein dedizierter virtueller Switch mit einer Netzwerkkarte nur für die 3CX verwendet, es ergibt sich keine Veränderung, die Tunnelverbindung bricht weiterhin regelmäßig ab.

 

[avraammich_3CX]

Hi AdniHB,

NTP Cleints auf dem Hyper V installiert?

Installing 3CX on a Hyper-V VM

This article describes the settings required to run 3CX phone System on a virtual instance on Hyper V

www.3cx.com

SBC auf dem neuesten Stand?
Anlage auf dem neuesten Stand?
Wenn du meinst der SBC ist im selben LAN?
Im selben LAN wie auch die 3cx Anlage?
Setzte das Log level des SBC auf Verbose sowie 3cx Anlage Log level auf Ausführlich.
SBC verbose setzten unter Dashboard->SBC ->Einstellungen ->Protokollierung ->Ausführlich.
Dashboard->SBC markieren-> Konfig. Übertragen button.


/var/log/3cxsbc.log

 

[AndiHB]

Hallo,
zur Diagnose habe ich den SBC ins gleiche LAN, wie der 3CX gehängt.
Die Version vom SBC ist 16.2.24, die Anlage ist 16.0.8.9.
Die Log-Dateien habe ich mir schon angesehen, auffallend ist auf dem SBC, dass die KA-Anzahlen auseinanderdriften (Gesendet/Empfangen). Auf der 3CX selbst kommt im Log irgendwann die Meldung, dass die Verbindung wegen Inaktivität getrennt wird, scheinbar werden die KAs nicht sauber übertragen.
Das NTP ist auf der 3CX entsprechend der Anleitung hinzugefügt worden. Nicht ersichtlich war für mich aus der Anleitung, ob Gastdienste des Hyper-V deaktiviert werden müssen (hier dann insbesondere Zeitsync). Die Gastdienste des Hyper-V stehen aktuell auf aktiviert.

 

[avraammich_3CX]

Hi AndiHB,


nach NTP Clients installieren reboote das System komplett neu.

Wenn du VM bereitstellt hast du die Möglichkeit ein MAC Andresse zu hinterlegen.

Verwende eine nicht die gleiche MAC Adresse wir der HOST sondern eine komplett andere.
Ich kann die jetzt schon mitteilen das uns verbindungsproblem nicht bekannt sind.
Ich selber verwende auch mehrere SBC auf unterschiedlichen Umgebungen/Konstellationen.
Starte ein Pcap auf beiden Seiten auf Server und SBC.
Evtl. bekommst mehr Infos welche dir weiterhelfen.
TCP re Transmission message evtl. welches auf Problem im Netzwerk deutet.

 

[AndiHB]

Ich habe jetzt testweise die Zeitsynchronisierung für den Hyper-V Gast deaktiviert, der SBC ist nun seit 60 Minuten stabil, das ist schon deutlich länger, als das vorher der Fall war. Der NTP war auf dem Debian ja vorher schon installiert. Ich vermute, dass der Hyper-V Host die Zeit in die eine Richtung und der Debian per NTP in die andere Richtung korrigiert hat.
In diesem Punkt sollte dann die Installationsanweisung auf Hyper-V aktualisiert/ergänzt werden.

 

[fxbastler]

Nicht ganz, der Hyper V Server diktiert den Client permanent die Zeit. Je nach verwendeter Hardware hoppelt das mehr oder weniger. Wenn der Client noch dazu seinen eigenen Zeitdienst mitbringt und dessen Zeit weit abweicht werden die Probleme größer.

Die Zeitsynchronisation von virtualisierten 3CX (wie auch von virtualisierten DC u.a.) sollte am Virtualisierungshost für diese VM immer ausgeschalten werden, egal ob Hyper V, KVM, ESX oder sonstwas. Es ist auch egal ob beide die Zeit von der gleichen (gar internen) Zeitquelle beziehen, dennoch ausschalten. Das erspart eine Reihe merkwürdiger Probleme.