IMO, FreePBX sorely needs a decent module for Fixed Mobile Convergence. Many users take calls on a mobile when they cannot answer at their desk. This is typically done with Follow Me, forwarding, an IVR option or transfer by a live receptionist.
Presently, one can use a SIP app, forward to a mobile number, or use a hybrid third-party solution, but all have serious shortcomings. Mobile outbound calls (to show company number, log and record the call, etc.) can use a SIP app, DISA, Callback or third-party, all with serious limitations.
Most SIP apps suffer from lost registrations, limited battery life, poor voice quality under less-than-ideal network conditions, dropped calls (IP address changes, etc.), non-operation behind many firewalls, security weaknesses and other issues. Though commercial apps have solved many of these problems (and Zulu Mobile could potentially solve all), there is still a risk that when a call comes in, the recipient is in a location with poor data coverage and voice quality will be terrible. Users can forward to their mobile number instead, but that also has serious issues:
If the caller ID is that of the original caller, you don’t know it’s a business call and may answer inappropriately. If the company number is sent, you don’t know who’s calling. To ensure that business calls don’t go to mobile voicemail and the caller doesn’t hear announcements in a language he may not speak, Call Confirmation (press 1 to accept) is needed, but that’s unsafe to do while driving. The added delay may result in the call being abandoned or going to voicemail. There is also significant quality loss (especially if the caller is also mobile) from cascaded compression codecs and from increased latency. Combined with e.g. caller in noisy bar, you on crappy car Bluetooth, one or both not speaking his native language, communication can become impossible. Outbound calls using DISA have additional usability and reliability issues.
A hybrid approach (metadata sent by IP; audio as a cellular voice call) could solve many of these issues, but the offerings of which I’m aware are both lame and expensive. In this thread Opticaller/Panaram for FreePBX (Mobile Android / iOS Client) , @tlewis said
There is a misunderstanding here. We don’t want a separate ‘product’. Rather, when Zulu detects that the current mobile data path is inadequate for VoIP (based on a brief test at the start of a call), it establishes a voice call to carry the audio. This is transparent to the user, except for some additional setup delay. In this mode, IP is still used for metadata; transfer, conference, park, BLF keys, etc. work normally.
If there is no data connection at all, only a cellular voice call is established, but some metadata can still be presented. Instead of ‘press one to accept’, I suggest that the user record one second of ringback tone at the beginning of his mobile voicemail greeting. On personal calls made directly to the mobile number, the caller will likely not notice. But when FreePBX forwards the call, upon answer it listens for this ‘audio key’ to know whether the call went to voicemail. During this time, the original caller continues to hear ringback (or music if programmed) and a brief announcement is played to the user, e.g identifying the organization or department called, so he can answer appropriately. On outbound, Zulu would use a protocol similar to DISA, but with integrity checking and automatic retries so signaling is faster and reliable. When a data connection is unavailable, Zulu would use DTMF commands behind the scenes; function keys as seen by the user would work normally.
Currently, I believe that a great majority of users receiving calls in the field just forward to their mobile number, because it’s too risky to depend on a quality data connection. A Zulu which can adaptively choose among these three modes would provide better quality, reliability, ease of use and cost savings.