SIP-Trunk ändert Status auf unregistered

[Wolfgang T.]

Hallo an alle!

1-2 mal pro Tag erhalte ich folgende Fehlermeldungen:

1. "Trunk L:10049(IMSVIE) has changed status to unregistered. This means that no more calls will pass via this trunk. Please check your network connection and the voip provider or other SIP PBX"
2. "Registration at IMSVIE has failed.
   Destination (sip:127.0.0.1:5080;lr) is not reachable, DNS error resolving FQDN, or service is not available."
3. "Trunk L:10049(IMSVIE) has changed status to registered."

Wir haben 2 3CX per SIP-Trunk verbunden, die über VPN verbunden sind, die IP-Adresse ist also eine interne (10.x.x.x).
Zwischen "unregistered" und "registered" vergehen etwa 2 Minuten, dann ist wieder alle online.

Auch seltsam ist, dass nur eine 3CX diese Meldungen ausgibt, die andere nicht.
Auch frage ich mich, woher die Loopback-Adresse kommt, in den Einstellungen ist nirgends ein Eintrag mit 127.0.0.1. Und wie gesagt, nach 2 Minuten ist der Spuk wieder vorbei.

Kennt jemand dieses Phänomen?

lg
Wolfgang

 

[WB@continue]

Wir haben alle paar Wochen Probleme mit dem SIP-Trunk. Parallel zur Anlage meldet aber auch unser Nagios Monitoring dann entsprechend. Nagios läßt den PBX-Server in kurzen Abständen gegen die Providerseitige IP unseres Trunks pingen.
D.h. wenn Nagios meldet, ist es mit Sicherheit ein Netzwerk Problem.
Wegen der Loopback Adresse würde ich mir vorerst keine Gedanken machen. In den Logs der PBX kommt die sehr oft als Adresse für irgendwelche Verbindungen mit Nebenstellen auf. Ich vermute, dass die Meldungen in einem Prozess generiert werden, der nicht selber nach Außen kommuniziert, sondern über Ports des Loopback mit anderen Prozessen. ( --> ist aber nur mein "solides" Halbwissen)

 

[Wolfgang T.]

Danke für die Antwort.
Netzwerk kann ich ausschließen, da es ansonsten auch eine Meldung über den VPN-Tunnel geben würde.
Warum allerdings nur eine 3CX diese Meldung bringt, ist für mich nicht ganz durchschaubar.

Ansich funktioniert ja alles, ist mehr ein "kosmetisches" Problem.

 

[WB@continue]

Habt ihr den Tunnel im Monitoring? Ist die Check-Sequenz dicht genug?
Was ist mit der Last auf den Routern vor und nach dem Tunnel, bzw. generell zwischen den PBX'en und dem Tunnel? Wenn dort alternatives Routing möglich ist, könnte es sein, dass Asyncrones Routen zu dem Problem führt.

Kosmetik ist immer relativ ;-)
Ich muss auf jedes kleine Zipperlein der PBX achten, sonst wandern die Kollegen wieder zu Skype ab ...

------------------------------------------------------------------------------------------------------------------
Asyncrones Routen: Wenn es das Routing ermöglicht, dass die Pakete von A nach B einen anderen Weg gehen als von B nach A.

 

[Wolfgang T.]

Der Tunnel wir überwacht, hier kommt es zu keinen Meldungen.
Die Route ist fix vorgegeben, da es sich um interne IP's handelt ist auch kein anderer Weg möglich.
Neben der Tatsache, dass nur eine 3CX die Meldung wirft wundert mich der Eintrag der 127.0.0.1, das auf der IP nix läuft ist klar. Aber woher kommt die?

 

[WB@continue]

Interessant ist, dass ich die 2te der 3 Meldungen bei unseren Problemen nicht bekomme.
Das scheint tatsächlich ein Problem zwischen den 2 PBXen zu sein.
Da fällt mir im Moment auch nichts mehr zu ein.

 

[avraammich_3CX]

Hi Wolfgang,

wenn du meinst du hast zwei Anlagen über Trunk verbunden?
Meinst du über Bridge?

Für die message 127.0.0.1:5080 bekommen wir wenn der Tunnel intern beendet wird.. So wird es in den Protokollen angezeigt, da die PBX auf diese Weise mit dem Tunnel kommuniziert. Mach dir keine sorgen um den 5080 Port welcher die angezeigt wird.

Beiden 3cx Anlagen stehen im selben NETZ (intern), so wie ich es verstanden habe, richtig?