Eingehende Anrufe kommen auf falsche Nebenstelle nach Upgrade auf v.18

[Schweigand]

Hallo,

bei einem unserer Kunden ist es nach dem Upgrade von v.16 auf v.18 bereits das zweite mal (ohne jeglichen Eingriff) passiert, dass eingehende Anrufe von beispielsweise 3 verschiedenen Nebenstellen (ich nenne sie 440, 460 und 490) auf die Nebenstelle "420" geleitet werden, obwohl die eingehenden Regeln richtig konfiguriert sind.

Das ganze passiert von einem Tag auf den anderen, ohne irgendeine Konfiguration geändert zu haben oder ein Update durchgeführt zu haben.

Beim ersten Mal dauerte die Fehlersuche ziemlich lange, bis ich drauf gekommen bin, den Sip-Trunk komplett löschen und neu anlegen zu müssen, sodass die Anrufe wieder auf der jeweiligen Nebenstelle ankommen.
Der Fehler ist dauerhaft und reproduzierbar, ohne Ausnahmen. Schön zu sehen im Anrufprotokoll, dass mein Testanruf nicht bei 440 sondern bei 420 ankommt.

Da dies jetzt ca. 5-6 Wochen später nun schon zum zweiten Mal auftritt, wissentlich, dass das einzige was hilft ist, die Sip-Trunks wieder neu anzulegen (inkl. aller ein- und ausgehenden Regeln, die dabei mit gelöscht werden), vermute ich hier einen Bug/Fehler.

Hat jemand schon ein ähnliches Verhalten beobachten können?

Vielleicht hat jemand einen Tipp für mich, ohne die ganze Anlage komplett neu aufzusetzen oder alle Paar Wochen die Trunks neu anlegen zu müssen, was ich dem Kunden natürlich nicht in Rechnung stellen kann.

Vielen Dank!
Michael

 

[fxbastler]

Hallo,

Hat jemand schon ein ähnliches Verhalten beobachten können?

Nein.

Solche Fehler weisen i.d.R. auf Altlasten oder frühere Basteleien hin. Ist selten aber kommt vor. Die einfachste Lösung ist wirklich:

• Backup der 3CX erzeugen
• Backup komplett herunterladen und kontrollieren ob das i.O. ist (entpacken, schauen ob die xml da ist)
• 3CX zurücksetzen
• 3CX Ersteinrichtung starten, Backup zurückspielen, Ersteinrichtung abschließen
• sonst. indiv. Einstellungen vornehmen und testen

 

[Schweigand]

Danke für deine Antwort.
Das kann man natürlich so machen, aber wird der Fehler durch das Backup dann nicht mitgezogen?

 

[fxbastler]

Wenn da nicht wirklich etwas falsch konfiguriert war: nein. Die DB wird geleert, neu aufgesetzt und nur mit den sauber exportierbaren Einträgen des Backup gefüttert. Das hat bisher gereicht. Wenn dann wirklich etwas noch nicht stimmt dann sieht man das auch in den Einstellungen und kann das korrigieren bzw. wurden direkte Einstellungen an den Endgeräten (Umleitungen die nicht rausprovisioniert werden) vorgenommen.

Wenn ihr aber schon solche Probleme in Hinsicht auf die SIP Trunk Einrichtung erlebt habt, dann würde ich den nach so einer Aktion dennoch genau kontrollieren, ob die Felder alle so sind wie sie sein sollen (mit einem Leeren einer Referenzanlage z.B.).

 

[Schweigand]

Wenn da nicht wirklich etwas falsch konfiguriert war: nein.

Es hat bei der v16 ca. 2-3 Jahre lang reibungslos funktioniert. Nach dem Upgrade auf v18 (was einem Backup, einer Deinstallation von v16, einer Neuinstallation von v18 und einem Restore des Backups gleichkommt), hat sich der Fehler eingeschlichen. Deshalb habe ich Bedenken, dass ein erneutes Backup, Neuinstallation und Restore hier Abhilfe schafft.

Ich werde es bei Gelegenheit versuchen und hier Rückmeldung geben.

Vielen Dank für deine bisherigen Antworten/Hilfestellung!

 

[fxbastler]

Nach dem Upgrade auf v18 (was einem Backup, einer Deinstallation von v16, einer Neuinstallation von v18 und einem Restore des Backups gleichkommt)

Aha, dann ist das eine Windows 3CX?

 

[Schweigand]

Aha, dann ist das eine Windows 3CX?

Ja, on-premise beim Kunden vor Ort gehostet, auf einem Windows 10 Server. Ist bei allen meinen Kunden so gelöst (meistens Windows Server OS) und funktioniert reibungslos. Bis auf diesen Fall hier, der mir unerklärbar ist.

 

[fxbastler]

Ja, on-premise beim Kunden vor Ort gehostet, auf einem Windows 10 Server.

Dann bringt ein Backup, Reset und Restore der 3CX natürlich nichts.

Dann die Protokollierungsstufe des Aktivitätenprotokoll der 3CX auf mittel stellen und das Protokoll mit dem Fehlerbild analysieren. Das bringt schon recht viel, ggf. leicht anonymisert hier als Code Block (wegen der Lesbarkeit) einstellen. Muss man halt warten bis der Fehler reproduzierbar wieder auftritt und dann mitschneiden.