Hello we just setup an inbound route pointed at a ring group with confirm calls enabled. The ring group consists of external numbers only (ie; 1234567890#) the ring group works as expected when confirm calls is not enabled but when enabled it drops the call after the announcement plays and the external numbers ring once. Ring time is 90s, Destination if no answer is voicemail of a virtual extension. The relevant alert message in the console is:
– Local/1234567890@from-internal-0000738c;1 is making progress passing it to Local/RG-1111-1234567890#@from-internal-0000738b;2
> 0x7f92209f6390 – Probation passed - setting RTP source address to XXX.XXX.XX.XXX:55570
– Nobody picked up in 5000 ms
Asterisk Version 11.20.0
FreePBX Version 12.0.76.2
All Modules Updated and on stable track
I can confirm this doesn’t work when routing a call from an inbound route -> did -> ring group -> extension/user -> fmfm list -> external number w/confirmation. Calls just drop before the call can be handled at the remote number. However, if you bypass the ring group on the inbound route and go direct to the extension in the sequence and call confirmation works fine. Put the ring group back as the destination on the inbound route, and disable call confirmation, all works fine. …But trying to use a ring group with FMFM enabled on an extension with external numbers which is part of a ring group, and now call confirmation doesn’t work. As a matter of fact the FreePBX configs go haywire and can start doing all kinds of crazy things like dialing the remote number(s) in the FMFM list 5 times and then giving up. I have even received voicemails from the system recording the call confirmation prompts minutes after both parties have disconnected the call. It is a mess. Perhaps it just wasn’t intended to work this way, but whatever, IMHO this is broken badly. I have not googled or checked to see if there is any kind of ticket open on this issue, but I did confirm it is an issue - at least reproducible on my system.
In this case, the workaround might be to route the call to a virtual or real extension with FMFM enabled and include a ring group in the FMFM list of numbers to call instead of routing the number straight to the ring group first? Don’t know if that would work in your situation or not?
FreePBX 13.0.42
Asterisk 11.19.0
FreePBX Distro Update version 6.12.65-31
I just tested this on FreePBX 13.0.42 with Asterisk Version 11.20.0 and FreePBX 12.0.74 with Asterisk 1.8.8.0. Both worked normally. Can you guys post more specifics of your configs?
@mattsl Can you elaborate on what you tested? We are pretty clear about how to reproduce the issue. I’m on a system that only uses SIP trunks, no dahdi based trunks.
So, here’s what it takes. Set up an extension with find me follow me to an external number like a cell phone and enable confirm calls on that fmfm. Now, create a ring group that lists the extension with fmfm enabled (needs a # sign after the extension in the ring group to execute the extension’s fmfm). Next, point a DID on a inbound route to the configured ring group and call the DID from an outside line and try to answer the call on the external number configured earlier in the FMFM. Have fun with this!
@mulderlr Good to know its not just me, I’ve tried quite a few tricks like:
inbound route > ring group > virtual ext > FMFM > external number
inbound route > virtual ext > FMFM > ring group > external number
inbound route > ring group > real ext > FMFM > external number
Nothing seems to work as long as a ring group is involved. I think this is a bug with ring groups, if I set it up the same way with a queue it works, so for now that’s how we will have to do it. Not the best solution but it works for now. This is how I have it working now.
inbound route > queue > external number
I opened a ticket after a quick search turned up nothing. Ticket Here
@mulderlr, I did the exact configuration @ansenlabardee described. Fresh install, did>ring group with some member of 5552222222# with Confirm Calls enabled. Dialed on from one cell, picked up on another. No issues. Since all of your subsequent description is different than his, I also just tested with RG>Ext>FM>Cell. Still no problems.
This may be something fixed between 12 and 13, but as I said before, please post your configurations if you want more help.
@mattsl multiple extensions in the ring group and multiple numbers in the FMFM list for at least one of the extensions with confirm calls on. It doesn’t seem to work for several of us. I’m glad it works for you because it should. This isn’t exactly a simple config to just browse through a config file on. If you want I can post logs of a sample call, etc and you can see what happens. Short of that, I’m not sure what you’re looking for.
We are slightly off from the OP, but here is a call that fails. As soon as 1 is pressed to confirm, the call is immediately send to the unavailable voicemail. 8673 is the originating caller. 5941 is the DID, 6100 is the ext with FMFM, 601 is the ring group, 8509 is the external number trying to pick up the call. Also - call recording is enabled on the 6100 extension. I was able to get one call to work after enabling FMFM via UCP. Typically REST APP is used via a yealink endpoint, but I would need to do more testing to see if that makes any difference.
I know this is a year old thread, but for posterity in case others run across this. I had the same problem, running 12.074. I tracked it down to the ring group having more than 3 digits in it, and something somewhere truncates it to 3 digits before testing if the channel exists in the database (in macro-confirm). I didn’t try to figure out what was doing the truncating, and I haven’t tried this in 13 to see if it still exists. For me at the moment its enough to know to avoid 4 digit ring group numbers!
THANK YOU JEFF! I spent the better part of a year pulling my hair out trying to figure this out. The secret like Jeff said, is to make sure ring groups only have 3 digits in them. I went from 1001 to 199 and the call connected just like it should. No more “I’m sorry the incoming call is unavailable or has been answered by someone else.” errors in FreePBX. (that was mostly for others to be able to find this when their external extensions don’t connect in ring groups. Thanks again.
Please submit this into the bug tracker. if you don’t, it won’t get fixed. Remember, we’re (almost) all nothing but users over here, and you know how hard it is to get newbies to search for their problem. Besides, it’s not right, so it should be fixed.
Thank you Igaetz. I’m running FreePBX 13.0.187 so I don’t know if that is still being developed but I’m sure it is still in production. And it is reproducible there. I’ll look into how to submit a bug. Thank you again.
Did I do it correctly? issues.free pbx. org/browse/FREEPBX-18199 My first bug report. (on an opensource project ever, about time I started giving back ) (I had to break the URL as I’m a new user)
) (I had to break the URL as I’m a new user)