- Joined
- Jul 11, 2012
- Messages
- 404
- Reaction score
- 16
We've recently installed a new 3CX system at our school. We're currently using iPhones (2 x iPhone 5 & 1 x iPhone 6) for our walkaround phones, however, they seem to be having issues maintaining call connections when walking around the school. We've also tried using the app on an Android phone, which appears to have the same issue.
While in a call and walking down the corridor. The call will start off clear but will start to lag and then eventually disconnect resulting in the call being dropped. We are currently using a mixture of HP MSM422s & HP E-MSM430s with the firmware version of 5.5.2.1-01-10012 across the board. The iPhones are all connected to the same SSID and are primarily contacting other stationary 3CX phones on the local network. The IPs for the iPhones are all handled by DHCP as well.
First of all you should consult this HPE Knowledge ArticleI had a call externally going on Wi-Fi and when I left the Wi-Fi range the 3CX client dropped the call on my end but left if going on the other persons (internal) end.
There should be noted that even some households use Fast BSS transition feature of OpenWrt!
Seamless Roaming allows your supported device such as an iPad® or iPhone® to roam between a supported Linksys Max-Stream router or range extender products (make sure that the latest firmware is installed with Seamless Roaming support). Seamless Roaming guarantees no dropped Voice over IP (VoIP) calls, no lag streaming video/video calls such as FaceTime® or Skype™.
As wireless devices improve in power and portability, exceptional on-the-go performance is expected from devices such as tablets, cell phones, and mobile VoIPs. Starting with firmware version 3.7.26 on the first Gen UniFi AP line, and version 3.7.21 on the second Gen UniFi AP line, UAPs automatically deploy Fast Roaming for improved roaming performance.
By reducing authentication steps with 802.11r, Fast Roaming considerably improves handoff time on UniFi APs. This improvement is most pronounced on WPA2-Enterprise networks, but BSS Transition similarly reduces steps on WPA2-Personal (WPA2-PSK) networks by allowing clients to quickly negotiate with any AP on the network.
By reducing authentication steps with 802.11r, Fast Roaming considerably improves handoff time on UniFi APs. This improvement is most pronounced on WPA2-Enterprise networks, but BSS Transition similarly reduces steps on WPA2-Personal (WPA2-PSK) networks by allowing clients to quickly negotiate with any AP on the network.
Captive portal should not be an obstacle for this app. It is expected that normal devices will connect only to known networks. It is not reasonable to expect that every call will be saved, but from this we can see demand for such feature.
In API 23 it is even possible to detect NET_CAPABILITY_CAPTIVE_PORTAL, but there is no need.
More importantly is to use onLost NetworkCallback to immediately activate local HD on hold music. Next callback to expect is onAvailable when new network is ready.
Captive portal should not be an obstacle for this app. It is expected that normal devices will connect only to known networks. It is not reasonable to expect that every call will be saved, but from this we can see demand for such feature.
PBX will not play on hold music if reinvite is not supported on specific in-office extension when mobile app switches to out of office.
If mobile app is not reconnected after 30s, PBX should send PUSH info about parked call.
User will have same problem with blocked ports anytime the device is connected to that network and he will not use it again.
- A VPN or some other form of tunneling would let you keep the connection open.
But re-connections take several seconds and then the server would need to know when you're off so it can enable music-on-hold.
No impossible to do, but I doubt any server will have this feature built-in. - My Samsung S5 has a feature that lets switch seamlessly between GSM and WiFi.
Packets all appear to come from a single IP address. This would prevent connection losses as long as either WiFi AND GSM is available. - Since the PBX would be in the middle, I'd think it could maintain a connection on one side right after the other side vanishes without properly saying "goodbye".
- I think it would be possible with Asterisk's conferencing functionality, for example.
If the call from you to the destination is actually two separate calls (1) from you to the PBX and
(2) from the PBX to your destination, then when part (1) drops, there's no reason to think you couldn't quickly redial into the PBX and rejoin the caller (2) who's technically "waiting alone in the conference room". - A new interface (wifi) is brought online, and the phone then has two IP addresses--one from the cellular network and one from the wifi network. The handset *should* be smart enough to not break an existing connection and should keep it live on the old interface (as long as the interface is still up)--any new connections should form on the new, higher-priority interface, but existing ones shouldn't be broken.
- One would think it would, but it doesn't. If a connection breaks, Asterisk hangs up the call.
- This is something that, frankly, should be fundamental as part of a modern Asterisk core.
VoIP is inherently subject to network issues, and the default behavior of Asterisk if a connection breaks should be to put the call on hold and reconnect it when the IP connection is reestablished. - Try updating to Android 6.0 please and use its SIP dialer instead of third party app. Call would not drop during hand over between Wi-Fi and mobile data, but you get dead air at both ends during hand over period that could last many seconds.
They could hang up even with music. After 1 min prompt may notify that user is still in tunnel.If it were possible, as you desire, the re-connect time may be more than just "a few seconds", and in fact, depending on each scenario, may be long enough to cause the other end to hang up, thinking they were dropped, especially if it happened mid sentence.
And how they do it:
As the video shows, when connected to a mobile network that supports Call Continuity and if implemented by an OEM, a smartphone powered by an LTE capable Snapdragon processor is capable of handling off the call from the LTE cell tower to a known Wi-Fi access point, or vice versa, without dropping it. To decide when to execute the switch, the LTE capable Snapdragon processor is designed to check the strength of the Wi-Fi signal — switching the call to Wi-Fi when it’s strong, and switching to LTE when it weakens. This addresses the two caveats of Wi-Fi calling discussed earlier.
Last edited: