I have an issue with FMFM and am hoping somebody may have seen it before and have a solution.
I am using FMFM to call an external number, a cell phone. For the most part it is working fine. However I occasionally get a recording of the “Too late” announcement that’s left in the voicemail for the follow me number. I’ve tracked it to cases where either the cell phone blocks the call or where the user declines the call. How can we avoid this?
Cell phone is setup to block call from numbers that are not in the contact list. So under normal circumstances, a call to the cell number from a number not in contacts never rings the cell phone and the caller ends up in cell phone vm box. A call from a contact rings the cell phone normally.
FMFM seems to be working as expected when caller is in contacts. Call forwards off to cell, user can pick up if desired, if not answered it goes to PBX vm. However if the call is actively declined at cell phone - user presses the decline button - it behaves the same as if the call had been blocked.
Either way, the caller is handled professionally and ends up in the proper pbx vm. It’s just that this artifact message of the too late announcement recording is left in the cell phone vm.
So it seems freepbs is seeing the cell phone vm picking up as a call completion but it is also sending the call back to the pbx vm. It’s not releasing the call to the cell phone vm even though that is first to answer, but it’s not ignoring it either.
Here are the details:
FMFM using ringall.
One number in the list, the cell phone. Might add additional in future.
confirm is on, for ability to determine when the call is originating from freepbx as opposed to someone dialing the cell number directly. Open to other methods to do this if needed.
all trunks are sip.
Tell me what else you need to know, and thanks in advance for any assistance you can offer!
Your’e not going to be able to deal with this with FMFM without end user training. When the cellphone declines the call, it sends the call to voicemail, the pbx, it’s the same as the call being picked up by the other carrier (whether the phone is answered by the user or sends it to voicemail, the trunk sees that the other carrier answered the call).
If you weren’t using the confirm call feature, then the caller would end up in the cellphone carrier’s voicemail rather than the PBX’s voicemail system. So kudos on using confirm call.
If using FMFM, I train end users up front not to decline the call, but simply mute it if they don’t want to take a call.
The other option would be to use a smartphone app to connect to the PBX as an extension (don’t open port 5060 for this). I’ve had great experience using iax2 extensions for this, not all apps use iax2, zoiper is pretty good. I’ve also used pjsip for mobile apps, I had some initial issues with the push (battery saving) settings in Bria when more than one contact is required (for example if user has a smartphone app and bria deskphone tied together), but after trial and error I’ve gotten it to work consistently. You could also use fmfm to the iax extension if the chan_sip extension is used.
Thanks. I knew somebody would have tried this and be willing to share. I hoped for a different answer but I’m not surprised.
RE confirmation…experience with other systems made this an obvious step for me. Blind external transfers are never optimal in automated arrangements. At some point a human has to press something if for no other reason but to stop the occasional unanticipated looping issue.
End user has to use the call block (or call would never stop ringing) if not in contacts so training to mute will only answer the 1% cases that are manually declined. I had hoped to avoid requiring a vpn (or opening ANY port not just 5060) to get the mobile devices connecting, hence the desire to make PSTN delivery work. But it looks like I’ll end up doing one or the other.
Can you set PBX voicemail to answer e.g. three seconds before mobile voicemail would pick up? If that’s unacceptably short, you may be able to increase the no-answer delay on the mobile.
Combined with handling declined calls properly, this should eliminate most of the ‘too late’ messages. (You will still get them when the mobile is out of range, dead battery, etc.)
I already optimized the various timings but I will play with this a bit. Unfortunately I think this will continue to fail for the most part in my circumstance, because the of the timing. The crux of the issue is that the call blocking at the cell phone happens essentially immediately, and the manual decline can happen at any point including almost immediately. So there’s no way to set the ring time to a meaningful value that reliably avoids the message when the potential action point is zero seconds after call initializes.