Swyxit Verliert Serververbindung Hinter Vpn Alle 5 Minuten

[michlson]

Hallo zusammen,

 

ich habe das Problem das unser SwyxIt 2011 R2 hinter einer OpenVPN Verbindung alle 5 Minuten die Verbindung zur SwyxWare (Server) verliert und munter anfängt die Verbindung wieder herzustellen was nach zweimaligem Versuch auch funktioniert. Der Effekt der sich einstellt ist nur der, dass dies während eines Gesprächs auch passiert. Es sind also nur Gespräche innerhalb des 5Minuten Zeitfensters möglich. Bei direkter Verbindung zur SwyxWare ist alles ok. Ich habe mir schon WireShark installiert und den Trafik mitloggen lassen werde aber aus den Protokollen nicht schlau. Es scheint mir so zu sein das der Client die Verbindung sauber trennt, die Serververbindung wiederherstellt und im Anschluss kann ein neues Gespräch begonnen werden. Die VPN Verbindung scheint mir nicht das Problem zu sein. Eher hat der Client ein Problem mit dem Server z.B. dass die keep alives nicht durch kommen oder ähnlich.

 

Vielen Dank schon mal im Voraus.

 

Log vom SwyxIt Client:

 

02/15/15 12:00:15 Registriert: user@telefonserver

02/15/15 11:59:56 Nicht registriert: user@telefonserver

02/15/15 11:59:56 Nicht registriert: user@telefonserver

02/15/15 11:59:56 503 Server nicht verfügbar - No matching transport found - user@telefonserver

02/15/15 11:59:54 Nicht registriert: user@telefonserver

02/15/15 11:59:54 Nicht registriert: user@telefonserver

02/15/15 11:59:54 503 Server nicht verfügbar - No matching transport found - user@telefonserver

02/15/15 11:54:29 Registriert: user@telefonserver

02/15/15 11:54:08 Nicht registriert: user@telefonserver

02/15/15 11:54:08 Nicht registriert: user@telefonserver

02/15/15 11:54:08 503 Server nicht verfügbar - No matching transport found - user@telefonserver

02/15/15 11:54:05 Nicht registriert: user@telefonserver

02/15/15 11:54:05 Nicht registriert: user@telefonserver

02/15/15 11:54:05 503 Server nicht verfügbar - No matching transport found - user@telefonserver

 

WireShark Auszug ist im Anhang:

[Bambuskuchensalat]

Hallo Michlson

 

Zwei Fragen dazu:

 

a) Wie verhält sich die VPN generell? Als wir bei uns VPN eingerichtet hatten ging jede Serverseitige Arbeit extrem lange. Wir hatten damals ein kleines Progrämmchen gebastelt, welches z.B die CallQueue von Swyx als HTML-iframe angezeigt hatte, das stürzte auch alle paar Stunden mal ab. Wir haben dann wieder auf RDS bzw. RemoteApplication umgestellt, was einfach nur absolut super ist (Hardware für Terminal Server müsste natürlich vorhanden sein)

 

b.) Wie verhält sich Swyx sonst? Gibt es Probleme bei Anrufen im internen Netz?

 

Falls Swyx sonst keine Probleme macht, würde ich behaupten, das Problem muss eher an der VPN Verbindung als an Swyx selber gesucht werden.

 

grüsse

Bambuskuchensalat

[michlson]

Hallo Bambuskuchensalat,

 

erst mal danke für die Antwort. Seit heute ist das Problem für mich sogar noch etwas kurioser. Ich hatte etwas Zeit rum zu probieren. Ich habe mal die OpenVPN Verbindung auf einem Android Handy eingerichtet, den Tunnel aufgebaut und führe jetzt schon ein Telefonat über eine halbe Stunde. Allerdings nicht über SwyxIt sondern mittels CSipSimple. Für mich scheint das Problem am Zusammenspiel von SwyxIt mit dem SwyxServer und dem Verlangen nach der SwyxIt nach einer Serververbindung zusammen zuhängen. Ich habe keine Ahnung welche Ports oder Protokolle im Hintergrund eine Verbindung haben müssen damit SwyxIt die Verbindung zum Server hält. Witziger weise nach dem zweiten Verbindungversuch der SwyxIt steht die Serververbindung dann wieder für die besagten 5Min. Wenn ich dich richtig verstehe lasst ihr die SwyxIt auf einem Terminal Server laufen. Die Audioausgabe lenkt ihr dann auf die Clients um oder wie? Oder benutzt ihr die SwyxIt dann nur im CTI Modus?

 

Danke und Guss Michlson

 

P.S. ich vergas. Die VPN Verbindung ist nicht der Knaller da wir in der Arbeit nur eine 6Mbit Leitung haben aber die läuft verhältnismäßig stabil. Also das Arbeiten über die VPN ist möglich.

 

SwyxIt macht hausintern keine nenneswerten Probleme.