FreePBX | Register | Issues | Wiki | Portal | Support

Fixed Mobile Convergence


#1

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.


(Tony Lewis) #2

That all sounds like a complicated solution to problem that doesn’t exist much and the world is moving to mobile voice over data. Even the carriers of mobile networks are moving to carrying the voice over data. I can tell you again we have no plans or anything on a radar for such a complicated setup. We are fully committed to our mobile app and using voice over data. If you feel there is such a need for a setup as your describe and a market place for it, basic supply and demand should kick in and everyone would be building such a product or if we are all missing the boat here go start a company around such a idea and go build and sell the product. Maybe you will prove us wrong and we are down the wrong path. Stranger things in life have happened.


#3

Moving to, yes. VoLTE, when you have it, sounds wonderful, a welcome relief after 30 years of crappy cellular. But it’s far from universal and gets priority treatment unavailable to a VoIP app. Although relatively few have tried Zulu Mobile, we all have experience with Skype, WhatsApp, FaceTime, etc. and know that at least occasionally they sound pretty bad.

On systems I have worked on, nearly all use of a VoIP app is targeting a mobile in the office or in a teleworker’s home, running over good Wi-Fi. When forwarding to an associate in the field or on call, the overwhelming preference is to use a mobile number.

Since you are hosting many systems in your cloud, you could survey thousands of users by inspecting their PBX configurations. My bet is that most of them forward to cellular voice.

As a migratory bird with four places (semi-rural, suburban, two high-density urban), I also have considerable personal experience. Locations where VoIP has been problematic include subways, trains, rural highways, highrise buildings and large steel and concrete buildings. In some of these places there is of course no coverage at all, but there are numerous situations where cellular voice is just a bit choppy and VoIP is unusable.

It is also common for mobiles to connect to poor Wi-Fi (overloaded, interference, no QoS, at range limit, etc.), even though mobile data would be fine. AFAIK it’s not presently possible for some apps to use mobile data while others are on Wi-Fi.

I’d be interested in hearing from readers of this thread who forward calls to field or on-call workers. Do you use VoIP or voice calls? Why?


(Tom Ray) #4

The problem with this (well at least one or so of them) is that this isn’t going to be solved by a “module” in FreePBX. This would require the Zulu mobile app to be able to deal with the phones/devices the client is running on. Pretty much 95% of this would be done at the app level on the phone.

The PBX is not going to determine the quality of the devices Wifi and/or Cellular data, the app is going to need to do that. The PBX isn’t going to need to split the metadata and the audio, the app is going to have to do that. A lot of is this going to be dependent on the actual app that is running on the device and well the device itself. Keep in mind that many people do not have current devices. So how far back should this app go in regards to mobile OS releases?

You pointed out “dropped calls due to IP changes” well that’s not going to stop with this either, it will actually be more prevalent since the idea is to use the most stable/better “rated” connection so that could leave the device jumping between the mobile and wifi data in locations to try and keep the “best connection”. How will the app and the PBX deal with that?

Everything that I’ve ever seen or tested that offered anything close to this also required an SBC of some sorts that would be in-between the PBX/SIP system and the endpoints so it can handle dealing with the media and signaling IPs changing with the endpoint while staying consistent with the PBX/SIP system for registration, states, etc.

You’ll notice that everything that offers some level of what you are referring to (or at least pieces of it) they all have their own softphone app for it and I’m pretty sure there are other pieces involved as Avaya, Mitel, Nortel, all those guys also sell phones and SBCs for their PBX/UC solutions to work. So even if this was on a roadmap for Sangoma it would be more than installing a module and a softphone app.

This is also going to be something that is still dealt with. So I’m on a network that is crappy or whatever and the solution is to send my audio over the cell network but still do all the metadata via IP signaling. The signalling is going to still have to traverse firewalls and generally the only reason you have the RTP ports open in a firewall is a crappy firewall all the real meat and potatoes is in the signaling and if that portion is still IP (wifi) then firewalls and NAT still matter.

However, let’s just say that this is a thing now much like Video, SRTP/TLS, WebRTC are things now. I compete with Comcast, CenturyLink, Qwest, Spectrum, Momentum, Jive, RingCentral and pretty much most LEC/“Carrier”/TSP companies in various markets. FMC and the other aforementioned items are less than 1% (being generous) of the time requested, mentioned or even considered a “must-have” feature when they move from those providers to me. IF the provider had a softphone (like RingCentral, etc) that is replaced with Bria. No complaints.

While my market reach is much smaller these days since going into my own world I have been in various markets from California, New Mexico, Texas, Washington, New York, Wisconsin, Illinois, Indiana, Florida, Ohio and a full LEC in Michigan and by that market reach things like FMC and those other items where a huge waste of resources and time in the Engineering dept. Months spent testing things like Video over various phones, cameras along with TLS and all that only to never really sell anything that would make up to for it.

The issue with this is that it’s still not caught on as a “thing that needs to be”. While what you are requesting/wanting is completely achievable the downside is, it is still in such stages that achieving it is a rather costly venture that could have little or no return in the immediate future.


(Lorne Gaetz) #5

One thing that would be easy and gets most of the way to the discussed features, would be a single button on the mobile client that a user can use to immediately transfer the call to the cellular number and continue the call that way. It offloads all the call quality logic to the user on a per call basis, or i suppose you could have a toggle.


(Tom Ray) #6

The RingCentral app does exactly that. It lets you “hot-swap” between ip phone/app and vice versa. It’s basically like a blind transfer that has no ringback and possibly auto answers the other device.

That, however, is a different beast of taking your active call between wifi-to-wifi or wifi-to-cellular and cellular-to-wifi. That is the part that requires auto intervention and handling the re-INVITEs, SDP, location updates, etc.