The title might not make total sense, but here’s the problem. When a ring group with confirm calls enabled points to an extension (including the # modifier) with follow me enabled, the cell phone in the follow me list is unable to answer the call. They get the message “call is no longer available or has been answered by someone else.” Unfortunately, if the follow me external device is the first one to pick up and press 1, it tricks the system into thinking the call has been answered, so everyone else will get the “call is no longer available” message, and the call will be lost.
I’m pretty sure this has been a problem ever since core version 14.0.28.72. I think I opened a bug report, but it got closed as a duplicate of the problem that was initially trying to be solved in that version. I’ve just been keeping the servers that need that functionality on the old version of core, but that is becoming difficult.
This is very easy to reproduce, I just ask that someone try it and see that this is still a problem.
Call confirmation is not enabled on follow me, just the ring group. I’m not sure if that would solve the problem, but I use the follow me without call confirmation for most of the calls that pass through. Only specific calls require the confirmation, which is why its in the ring group.
Has anyone been able to reproduce this? I took a look at what was changed in that update, but it only appears to be related to the sub-send-obroute-email
Here issue was we were using the two macro in single dial, which will not work, now changed the macro with gosub
I’m not sure how this fixed the other problem and caused this problem at the same time, but it’s all a little over my head to try to figure out.
Does anyone perhaps have suggestions how I could accomplish this without running into this bug?
Basically, I want to ring a number in a follow me without it using call confirmation, but I would also like to be able to reference the same follow me number from within a ring group while using call confirmation. I’ve written some custom code to have people change the contents of an extension’s follow me list, so I would like that to remain in the system. However, if someone can think of a better way to accomplish this, I’m all ears, and I’d gladly rewrite the custom context if it meant getting this problem behind me.
Well, first the bad news: I set up a simple test on my own system, figuring that I would compare logs to see what’s wrong with yours. Unfortunately, mine also failed (running core 15.0.12.55).
Next, I simplified further and discovered that RG with Confirm -> FM fails, even if the FM does not include any external destinations. RG with Confirm to an external destination does work.
It probably makes no sense for me to fix the bug, because I’m not familiar with all the paths and would likely break a different case. I decided to look for a workaround instead.
Simple workaround: point the RG to the DID number corresponding to the extension with FM. As expected, that works, but has obvious downsides: cost of outbound and inbound legs, latency, network bandwidth, etc.
Next attempt: loopback trunk (Custom trunk with Dial set to Local/$OUTNUM$@from-internal). Surprise, no workie.
Final solution: a loopback pjsip trunk. Authentication: None, SIP Server: IP address of PBX, SIP Server Port: port that pjsip listens on. All other settings left at defaults.
Of course, you need an Outbound Route with some prefix. The RG calls the number using that prefix and the DID that points to the extension with FM, e.g. 9992125551212# If the extension doesn’t have a dedicated DID, make up a fake on and create an Inbound Route for it.
Thanks for testing. I don’t have a DID for the extension, so I’m going to try to implement your loopback trunk workaround. That’s a very creative idea. I’ll post back here if I run into any problems.
Thanks again, @Stewart1. I was able to implement your loopback workaround. I’m just wondering if having this extra, unauthenticated trunk would present any security vulnerabilities. Does it matter at all what DID I choose? I’m pretty sure the DID doesn’t matter, but I figured I would double check for the trunk.
Interesting question, for which I don’t have a good answer. I tested that you can set Authentication to Both and enter a random secret; the trunk still functions. Although I strongly believe that an incoming call to this trunk would fail unless properly authenticated, I did not test that.
I’m reasonably certain that a call would be routed to this trunk only if the source IP of the INVITE matches the address set in SIP Server. If that’s a private IP, an attack would have to come from your LAN (inside job, or the attacker already gained a foothold). If it’s on a dedicated public IP, the attack would have to come from a flaky data center that allows a spoofed address to pass. (An ordinary home, small business or cloud server connection goes via routers that pass only source addresses that are yours.)
Finally, such an attack would only gain access to the from-pstn context, which by default is not able to make outgoing calls or access feature codes. Of course, some systems allow greater access, because of a configuration error or a misguided customization.
Well, after upgrading out PBX, we also now have this issue. No matter what when you answer the RG with call confirm, after pressing 1, it will always say the call is now unavailable or answered elsewhere. The log looks the same on the entry here, Asterisk can plays the press 1 message, and it sees the calling party press 1, regardless it plays the unavailable or answered elsewhere message, 100% of the time. Removing confirmation via the toggle or by removing the # at the end of the extension restores function, but we need to have call confirm.
@Stewart1 or @dicko, not sure if you have any other suggestions on how to make this work. Mine is a slightly different setup (but running core 15.0.12.55 as well).
We have a single ring group (called variable ring group) it has a single extension, 1111111111#, in the extensions list.
Extension 1111111111 has its dial string set to local/s@var-extension-dial
which calls an external phone number, defined in the asterisk phonebook name field using: exten => s,n,goto(from-internal,${RESULT3},1)
RESULT3 is the is the external phone number to call, and is defined earlier in the call.
The whole purpose of this is being able to consolidate like-treatment ring groups into one RG entry. Then it is just a matter of making many (much easier) phone book entries.
This has been working flawlessly, but then an upgrade to our server has put us in the same situation. as above. I am not sure which module(s) or if asterisk needs to be rolled back, I do not want to guess if I can avoid it.
@lgaetz & @kgupta1, it seems like the correct process was followed here.