Starface 7.0 + Gigaset N720 = gelegentliches "Active call dropped!" an Station 1

Hallo zusammen,

gelegentlich, jedoch min. 3x die Woche, kommt es vor, dass Gesprächsverbindungen abrupt beendet werden.

Das Setup ist folgendes:

- Starface 7.0.2.1 (VM-Edition)
- Gigaset N720 DM mit 5 Stationen. (alle auf Firmwareversion 71.116.00.000.00)

Die Starface läuft in einem ESXI.
Der ESXI ist an einem managed Switch02 (Netgear) angeschlossen und geht von dort aus zum Hauptswitch Switch01 (Unify).
Von Switch01 geht ein Uplink zu einem unmanaged POE-Switch (TP-Link), an dem sämtliche Gigaset Geräte angeschlossen sind.
Die Pakete gehen also alle über den Hauptswitch.

Im großen und ganzen läuft alles relativ stabil. Bis eben auf die gelegentlichen Aussetzer.
Ich möchte das Problem nun versuchen einzugrenzen und frage euch daher, wo man am besten anfängt.

Auszug aus dem DECT Manager. Zuletzt am 01.03. zurückgesetzt

Cl Lv RPN Sync   Conn  HoIn HoOut  Loss Async  Busy DpcOff
----------------------------------------------------------
 1  1  02 (FF)    753    57    31     2     0    21     0 1 - 1
       03 (FF)      0     0     0     0     0     0     0 
 1  2  04 (02)     65    20    22     0     9     0     0 2 - 2
       05 (FF)      0     0     0     0     0     0     0 
 1  2  08 (02)    147    26    41     1     0     0     0 4 - 3
       09 (FF)      0     0     0     0     0     0     0 
 1  2  0A (02)     56    20    28     2     0     0     2 5 - 4
       0B (FF)      0     0     0     0     0     0     2 
 1  3  06 (04)    195     5     6     0     8     0     0 3 - 5
       07 (FF)      0     0     0     0     0     0     0

Im Augenmerk liegt Station 1. Diese ist die Hauptstation, von der sich alle anderen aus syncen.
Die anderen Stationen mit "active Call dropped" sind direkt mit der Station 1 verbunden (Sync-Level 2). Diese möchte ich zur Fehlersuche in diesem Fall aber gerne ausblenden.
Die Verbindung der Handsets zur Station1 zum Zeitpunkt des Drops ist ausgezeichnet. Die Station ist auch nur max. 10 Meter entfernt.
Die Handsets sind GigaSet S650H Pro.

Bei den unzähligen Logs in der Starface bin ich mir nicht ganz sicher, welche nun genau das richtige ist.
"callhandling" sieht vielversprechend aus.

Ich habe für mein Befinden die Einträge ausgewählt die evtl. relevant sind. Bitte korrigiert mich.

Um 10.10 Uhr wurde das Gespräch über Starface Comfortphoning initiiert.
Das Gespräch brach nach 6.53 Minuten ab. Das sehe ich aufgrund der Gesprächsdauer und hat mir die Suche im Protokoll etwas erleichtert.

Ich habe folgende Einträge aus dem Log ausmachen können (einige Daten habe ich mit xxx ersetzt:)

[2022-03-08 10:10:22,926] [INFO ] [AMI BridgeEnterEvent] [CallModelLogic] SipCallerIdUpdate SIP/1199.N720-0000746e "xxx" <sip:yyy@xxx> 
[2022-03-08 10:10:22,926] [INFO ] [AMI BridgeEnterEvent] [CallModelLogic] Connected Line (SIP/1199.N720-0000746e) xxx xxx 
[2022-03-08 10:17:16,881] [INFO ] [AMI BridgeLeaveEvent] [BridgeLeaveEventListener] 05b3fdeb-dd39-4fd8-8872-xxx <-|-> SIP/1199.N720-0000746e 
[2022-03-08 10:17:16,881] [INFO ] [AMI BridgeLeaveEvent] [BridgeLeaveEventListener] 05b3fdeb-dd39-4fd8-8872-xxx <-|-> SIP/+49xxx-0000746f 
[2022-03-08 10:17:16,881] [INFO ] [AMI BridgeDestroyEvent] [BridgeDestroyEventListener] 05b3fdeb-dd39-xxx-1364685878a4 
[2022-03-08 10:17:16,881] [INFO ] [AMI HangupEvent] [HangupEventListener] SIP/+49xxx-0000746f 
[2022-03-08 10:17:16,881] [INFO ] [AMI HangupEvent] [CallContainer] - UciCall [861b10de-6945-492e-8b5b-xxx, 1016, HANGUP , [SIP/+49xxx-0000746f], caller=xxx <555>, called= <0049xxx>, caller=false] 
[2022-03-08 10:17:16,881] [INFO ] [AMI HangupEvent] [CallContainer] - UciCall [df4fbed3-940e-456c-bb20-xxx, , CONNECTED , [SIP/1199.N720-0000746e], caller=xxx <555>, called= <0049xxx>, caller=true] 
[2022-03-08 10:17:16,881] [INFO ] [AMI HangupEvent] [HangupEventListener] SIP/1199.N720-0000746e 
[2022-03-08 10:17:16,882] [INFO ] [AMI HangupEvent] [CallContainer] - UciCall [df4fbed3-940e-456c-bb20-xxx, , HANGUP , [SIP/1199.N720-0000746e], caller=xxx <555>, called= <0049xxx>, caller=true]

Für mich kommen mehrere potentielle Fehlerquellen in den Sinn.

• managed Switches und ggf. falsch eingestellte QoS-Einstellungen.
  Am Netgears Switch habe ich unter den PVID Einstellungen die "Port Priority" auf 5 gesetzt. Diese ist für Echtzeitdaten bzw. Audio empfohlen.
  Am Unify Switch gibt es augenscheinlich dazu keine Einstellung.
• Inkompatibilität des unmanaged POE-Switch
• Handsets Gigaset S650H Pro
• Mit Sicherheit noch mehr Quellen die mir im Moment nicht einfallen oder die ich nicht kenne.

Kann man aus den Protokollen schlauer werden oder könnt ihr mir sagen, wo man noch nachsehen sollte?
Was wäre euer lösungsorientierter Ansatz, um das Problem zu finden?

Ich freue mich auf eure Antworten.

Ok. Dazu habe ich nochmal ein paar Fragen.

1. Ich habe als erstes das regelmäßige Neustarten des DMs und der Basisstationen für jeden Tag aktiviert.
Ein Mitarbeiter hatte sich häufig über schlechte Tonqualität beschwert. Nach einem Neustart der zuständigen Basisstation war das Problem verschwunden.

Also scheint auch dort schonmal der Wurm drin zu sein. Und die Tatsache, dass es die Funktion für routinierte Neustarts gibt, scheint wohl eine Existenzberechtigung zu haben.

2. Ich habe Syslog im DECT Manager aktiviert und lasse dort mitschneiden.
Ich warte auf ein "Loss", damit ich die Logs auf Unregelmäßigkeiten überprüfen kann. Der Zähler wird im Moment täglich protokolliert und zurückgesetzt.

Somit kann ich es wenigstens auf 24 eingrenzen.

Was meinst du mit "Ping mitlaufen lassen". Mir ist klar was ein Ping ist. Aber wie meinst du das im Detail?
Die TK-Anlage ständig anpingen und ggf. lange Laufzeiten aufspüren? Wie würdest du das in der Praxis in einer VM-Umgebung umsetzen?

Switch Port Monitoren.
Alles läuft an einem managbaren Hauptswitch zusammen. Detaillierte Statistiken kann ich dennoch nicht aus diesem ziehen.

Meinst du damit z.B. den Port spiegeln und mittels Tool alles mitschneiden? Hast du ein Praxisbeispiel für mich?

Die Problematik bei den unzähligen Logs ist für mich eben, aussagekräftige und hoffentlich schlüssige Meldungen zu loggen und am Ende auch "zu finden".