Anruf mit falscher Nebenstelle verbunden

[Matschek]

Ich kann im Log nicht nachvollziehen, warum ein interner Anruf von einer Nebenstelle bei einer falschen Nebenstelle rauskam.
Anrufer ist die 13, angerufen wurde die 14. Die 14 hat nicht signalisiert (Tischtelefon, Handy und App angemeldet), statt dessen die 11. Beim Abnehmen von 11 wurde das Gespräch zwischen 13 und 11 aufgebaut. Im Display der Anruferin stand hingegen der Name der Gegenstelle 14, obwohl sie faktisch mit 11 telefonierte.
Nach der Verwunderung direkter ein zweiter Versuch, dort war wieder alles in Ordnung.

 

[fxbastler]

Die üblichen Fragen:

1. 3CX Version, z. B. Professional oder Enterprise Jahreslizenz 20.0.7.1057
2. Server OS, z. B. Debian / Windows Server - und welche Version genau verwendet wird
3. Wird Ihr 3CX Server gehostet? Wenn ja, wo? z. B. on-Premise (im eig. Netzwerk) / eigenständig gehostet via [DigitalOcean/Google/AWS/Azure/Lightsail oder andere wie Netcup, Hetzner] / Gehostet (von 3CX) / SMB (3CX)
4. Wenn die 3CX selbst betrieben wird: Was für Hardware und ggf. was für ein Virtualisierer wird verwendet? z. B. Xeon E-2486 mit 32 GB ECC Speicher und 2x 960 GB SAS3 im HW RAID 1; Virtualisierer ist ein Hyper V Host
5. War der Firewall Checker erfolgreich?: ja / nein, wenn nein: Bildschirmfoto
6. Split DNS wurde eingerichtet und funktionierend getestet? ja / nein
7. SIP-Trunk-Anbieter der 3CX, z. B. Easybell, Deutsche Telefon, Plusnet, Poeplefone
8. Welche Audio Codecs werden primär in der 3CX verwendet? z. B. SIP Trunk: PCMA, 3CX LAN: PCMA, 3CX WAN: PCMA, SIP Endgeräte: PCMA
9. Typ und Firmware der am beteiligten Anruf verwendeten Endgeräte / aller Endgeräte an den beteiligten Nebenstellen, z. B. Yealink T57W 96.87.0.16, Windows Softphone v20 als CTI Client auf einem PC, Yealink W74H DECT Handset an Yealink DECT Basis W70B
10. Werden die Endgeräte (weil SMB / hosted by 3CX / fremd gehostet) per SMB oder Router Phone angebunden und wenn ja wie?, z. B. nein / Linux SBC virtualisiert, das Yealink T57W soll ein Router Phone werden
11. Befinden sich die 3CX / der SBC, das Gerät von welchem aus angerufen wird und das Gerät an welchem es rufen soll im gleichen phys. LAN?: ja / nein
12. Hersteller, Modell und Firmware Version des im Netzwerk verwenden Router und der zwischen 3CX / SBC und den beteiligten Endgeräten verwendeten Switche, z.B. 1x Mikrotik RB5009UG+S+IN Fw. 7.19.4 + 2x Mikrotik CRS328-24P-4S+RM Fw. 7.19.4
13. Nutzen Sie benutzerdefinierte Telefon-Templates?: ja / nein
14. Sind mehr als ein Endgerät an einer der am Anruf beteiligten Nebenstellen eingerichtet?: ja (bitte genau beschreiben) / nein

TEILEN SIE NIE: Lizenzschlüssel, öffentliche IP-Adressen, E-Mail-Adressen, Benutzernamen, Passwörter, FQDNs, Provisionierungs-URLs, etc.

 

[Matschek]

Hi, hier weitere Infos.

1. Enterprise 20.0 U7 B1057
2. Debian 12
3. onPrem
4. Hyper-V unter 2019, VM mit 2 cores, 2GB RAM (werde bei Gelegenheit auf 4 GB gehen, habe gesehen, dass das jüngst still und heimlich angehoben wurde?)
5. Ja, Screenshot folgt außerhalb der Geschäftszeit. Aber hier reden wir auch von internem Traffic.
6. Ja
7. internes Telefonat, Telekom Trunk nicht involviert.
8. Involvierte Tischtelefone: G722
9. T45W, 96.87.0.16
10. Nein
11. Ja
12. Traffic intern, kein Router involviert
13. Nein
14. Ja. Tischtelefon und App.

VG
Matschek

 

[fxbastler]

Ich würde erst einmal die Protokollierungsstufe des 3CX Aktivitätsprotokoll auf Ausführlich stellen und für 10 Tage behalten wollen. Ich würde die Nutzer instruieren, dass die bei weiteren solchen Problemen das Geschehen notieren: Datum + Uhrzeit + Anrufer + genutztes Endgerät + Angerufener + Umleitung.

Wenn das Problem weiterhin auftritt, dann die 3CX Protokolle nach diesen Anrufen und deren Verlauf durchsuchen. Da sollte die Ursache zu finden sein. Alternativ mit dem 3CX Binlog Viewer nachschauen, das wird dann noch umfangreicher.

Wenn die Protokollierungsstufe des 3CX Aktivitätsprotokoll auf niedrig steht, dann wird es schwer bis unmöglich dieses Problem im Nachgang zu finden.

 

[mbehrens]

Ich kann im Log nicht nachvollziehen, warum ein interner Anruf von einer Nebenstelle bei einer falschen Nebenstelle rauskam.

Loglevel erhöhen, auf den beteiligten Geräten nachschauen.

Irgendwas mit den SIP IDs gemacht?
Hat der Anwender Einstellungen am Endgerät versucht zu ändern?

 

[Matschek]

Ich hab das Loglevel von Medium auf Verbose erhöht, seit dem jedoch den Fehler nicht mehr reportet bekommen.

[...] Da sollte die Ursache zu finden sein.

Kannst Du dir denn einen theoretischen logischen Grund für so ein Verhalten vorstellen? Es sind keine Scripte o.ä. im Einsatz.

Irgendwas mit den SIP IDs gemacht?
Hat der Anwender Einstellungen am Endgerät versucht zu ändern?

Keine Änderungen an den Optionen in den letzten Wochen.

auf den beteiligten Geräten nachschauen.

Der Call lief zwischen den Tischtelefonen, wo würdest Du dort etwas nachsehen?

 

[fxbastler]

Kannst Du dir denn einen theoretischen logischen Grund für so ein Verhalten vorstellen?

1. Umleitung im Endgerät aktiviert
2. Netzwerkprobleme

 

[mbehrens]

Der Call lief zwischen den Tischtelefonen, wo würdest Du dort etwas nachsehen?

Auf den beteiligten Endgeräten nachschauen. Jedes Gerät führt Logdateien.

 

[Matschek]

Auf den beteiligten Endgeräten nachschauen. Jedes Gerät führt Logdateien.

Also bei meinen automatisch provisionierten T54W muss ich das erst explizit aktivieren. Zum Zeitpunkt des Fehlers war da nichts an. Da ich nicht weiß wo/wann der Fehler wieder auftritt, tue ich mir schwer 1x alle Apparate abzuklappern und es überall zu aktivieren. Bislang blieb es "leider" beim einmaligen Vorkommen.

1. Umleitung im Endgerät aktiviert
2. Netzwerkprobleme

Umleitung kann ich ausschließen. Ich saß vor dem Apparat, der angerufen werden sollte. Ich hatte/habe keine Umleitung drin, und hatte innerhalb der 45 Sekunden zwischen dem falschen und dem richtigen Anruf nicht mal das Tischtelefon oder die App berührt, geschweige denn etwas dort konfiguriert. Es gibt in der 3cx auch keinerlei andere Regeln, die die falsch klingelnde 11er Nebenstelle als Abwurfziel o.ä. hätte. Diese Theorie würde ich daher kippen.
Netzwerkprobleme: Immer schwierig zu beurteilen bei einem einzelnen Vorfall der naturgemäß nicht mitgeschnitten wurde. Bislang sind in keinerlei anderen Form Anomalien im Netz aufgetreten. Simpler Aufbau, 2 Switche, in dem Segment keine VLANs oder Router beteiligt. Ich kann mir - aber da mag es mir an internem Funktions-Knowledge fehlen - einfach nicht erklären, wie ein Netzwerkfehler Gegenstellen vertauschen/vermischen könnte. Denkst Du da an verfälsche Pakete?

 

[fxbastler]

Ich kann mir - aber da mag es mir an internem Funktions-Knowledge fehlen - einfach nicht erklären, wie ein Netzwerkfehler Gegenstellen vertauschen/vermischen könnte. Denkst Du da an verfälsche Pakete?

Ja, auch das.

Ebenso Multicast Probleme - wenn die Multicast Bindung der 3CX nicht passt. Das kann und sollte man kontrollieren:
https://www.3cx.de/forum/threads/telefone-verlieren-verbindung-zur-3cx-onpremises.116013/post-410287

Oder wenn sich das ein Gerät an Land zieht. Siehe die Geschichte hier, das ist so ein Beispiel:
https://www.3cx.de/forum/threads/probleme-mit-ausgehenden-gesprächen.97737/post-318050

Die problematische Nebenstelle von angehangenen provisionierten Endgeräten befreien (löschen), die Nebenstelle löschen, alle ehemals angehangenen provisionierten Endgeräte auf Werkseinstellungen zurücksetzen und die Nebenstelle mit allen Endgeräten komplett neu einrichten ist zwar die Holzhammermethode aber kann auch zum Ziel führen. Insbesonders wenn dort Altlasten in den Einstellungen (z.B. per ehem. Tastencode) enthalten sind.

Nur ganz am Rande: Ausnahmen in den Weiterleitungsregeln der Nebenstelle sind wohl hoffentlich keine aktiviert - richtig?

 

[Matschek]

Das Phänomen trat nie wieder auf... Diagnostisch gesehen schade, pragmatisch betrachtet schön dass alles funktioniert
Danke für die Denkanstöße!