3CX Windows Client over satellite network connection

[smsinc]

I am using the 3CX Windows Client over a satellite internet connection (Exede). I have a ticket open with the provider that we got the system from, but I thought I would post the question here.

The Windows client has a hard time making and maintaining a connection to the host. It takes a long time to register, I usually have to start and restart the client several times to get it to register and go on hook. Once it has done that it seems to have a hard time maintaining the connection to the server, losing the connection and attempting to re-register, which typical fails.

I suspect the issue is the latency that is inherent in a satellite internet connection. I was wondering if there was a registry setting that could be changed, that would cause the client to wait longer for a response back from the server.

Thank you

 

[NickD_3CX]

You could try toggling the 3CX Tunnel on/off to see if one of the 2 works better.

If this is V14, you can do this from the Management Console -> Extensions -> Extension settings -> '3CXPhone' tab, by enabling/disabling the "Use 3CX Tunnel for remote connections" option. After making a change you must exit the client and opening it.

 

[Sopock]

I suspect the issue is the latency that is inherent in a satellite internet connection. I was wondering if there was a registry setting that could be changed, that would cause the client to wait longer for a response back from the server.

First visit some online tcp analyzer and speedtest?

Maybe in Troubleshooting console there could be tracert button to IP of remote extension?

 

[leejor]

I know someone that was also trying to get a SIP satellite connection working. The end result was "acceptable", but just barely, of course every satellite provider will be different. Going with the lowest bit-rate Codec, (that works) is a must (this may affect the use of DTMF tones end to end). Unfortunately, given that SIP voice is done in "real time", any packet delay (beyond a certain threshold) means they are simply dropped, which can severely affect voice quality.

The initial registration should not really be an issue, and there may be something else at play here. Any dropped data packets should be re-sent, unlike voice packets. Once registered, 3CX will normally wait 30 minutes (unless you've changed that) before the set is required to register again. In the mean time, each end would assume that registration is valid until that time expires. Before the 30 minutes is up, the only way that 3CX should see the set as unregistered is if it attempts a call and received no response from the remote end. Much the same with the set. Unless a call were placed, or, the physical LAN connection were dropped, the set should assume that it is still registered. Of course, things like "keep alive " settings and manual "short" interval re-registrations, can affect this.