Estos ProCall Client über VPN Client - werde nach einer Weile nicht mehr gehört

[p0ddie]

Hi,

ich habe einen Windows Client mit Estos Procall Softphone drauf, der per Advanced VPN Client (aktuelle Version) über ein ikev2 VPN zu einem Lancom Router (LCOS auch aktuell) mit der dahinter liegenden TK Anlage kommuniziert. Nach 2-8 Minuten höre ich meinen GEsprächspartner noch, der aber mich nicht mehr. Es bricht plötzlich ab. Zeitintervall habe ich versucht herauszufinden, ist aber nicht so einfach.

Ich nehme an, dass es irgendwie am IKE Rekeying o.ä. liegt. Es ist jedenfalls leider reproduzierbar und so unbrauchbar... Ich bin mir sicher, dass ich nicht der einzige bin, der über VPN mit einem Softphone arbeitet, gibt es dafür eine Lösung? Danke!

Edit: Wenn ich den Softphone Client innerhalb einer RDP-Verbindung auf den Terminalserver benutze, bricht es auch ab, die RDP Verbindung bleibt allerdings problemlos bestehen. Hier fließen die Audiodaten ja nicht direkt vom Procall Client zur TK Anlage über das VPN, sondern von meinem lokalen Client gehen die Audiodaten über RDP an den Terminalserver, der das dann per Procall an die TK Anlage im gleichen LAN weiter gibt.

Noch ein Edit: Ich hab's gerade mal mit einem Macbook und einer ikev2 Verbindung (mit dem macOS internen VPN Client) ausprobiert, bisher kein Verbindungsabbruch nach 14min. Scheint ein Problem im Advanced VPN Client für Windows zu sein...

[Ganzfix]

Wir setzten Estos Procall 7.5 mit dem Advanced VPN Client (verschiedene Versionen) ein. Das funktioniert ohne Probleme.
Somit kann es zumindest kein generelles Problem des Advanced VPN Client sein.
Leider fällt mir aber auch gerade keine Lösungsmöglichkeit ein.

[p0ddie]

Danke für das Feedback, ich lasse das einfach mal jemanden testen mit internen Telefonaten, dann ist es nicht so peinlich, wenn GEspräche zu Kunden abbrechen.

[GrandDixence]

Die Anwendung der üblichen Fehlersuchwerkzeuge wie Trace (VPN - IKE) und Wireshark mit Packet Capture kann doch nicht so schwierig sein...
fragen-zum-thema-vpn-f14/probleme-mit-i ... tml#p99340

[p0ddie]

Sich mal in Menschen hineinzuversetzen, die nicht für ihre Zeit, die sie als Angestellter im Büro absitzen, sondern für die Lösung für Probleme bezahlt werden - und daher erst mal nachfragen, ob das ein bekanntes Problem ist, um nicht für alles immer bei Adam und Eva anzufangen und mind. 1-2h in den Lösungsansatz rein zu versenken, damit der Chef sieht, dass man was tut für sein Geld - kann doch ebenfalls nicht so schwierig sein

[Dr.Einstein]

Also der VPN selbst funktioniert noch? Du kannst dich im Netzwerk (zB dem RDP Server) frei bewegen über den Tunnel, nur das Gespräch reißt ab bzw eine Sprachrichtung? Dann kanns an sich nicht Rekeying sein, weil zumindest bei Lancom immer beide SA#s zeitgleich ausgehandelt werden.

Da es reproduzierbar ist, zwei Ansätze:

- Wireshark auf dem LAN-Interface des Lancoms aktivieren (geht über die Weboberfläche des Lancoms) und sofort stoppen, sobald das Gespräch einseitig wird. Wenn du weiterhin UDP in beide Richtungen siehst mit gleicher Paketdichte, liegen die Daten von TK-Anlage Richtung deines Clients noch an
- IP-Router Trace auf dem Lancom. Da wirst du natürlich erschlagen, aber ab Fehlerzeit stoppen und auch hier gucken, ob die UDP Pakete anstehen. Wichtig ist hier, dass ab Fehlerzeitpunkt weiterhin als Router Tx die VPN-Client-Verbindung stehen muss. Da darf nix mit FIlter Port etc stehen.

[backslash]

Hi Dr.Einstein

- IP-Router Trace auf dem Lancom.

davon würde ich abraten, denn das braucht extrem viel Speicher - insbesondere, wenn viel los ist, kann es sein, daß dem Gerät dabei der Speicher ausgeht. Mit viel Glück erkennt der Trace das rechtzeitig und bricht selbst ab - wenn nicht bootet das Gerät...

Abegesehen davon wird das Grät durch den Trace auch noch extrem langsam...

Gruß
Backlsahs