I’ve got two trunks, a BT PSTN trunk and a Sipgate VoIP trunk.
(I have to dial ‘9’ to get the Sipgate trunk, and that 9 is then stripped from the dialled number.)
If I implement “FollowMe” on my Sipgate extension (linked to the Sipgate trunk), if I don’t pick up the call, the PSTN is used to try to forward the call on. This works.
If I try to do the reverse, and use “FollowMe” on my PSTN extension (linked to the PSTN trunk), it doesn’t work. There’s no record of an attempt being made in the CDR.
A little confused here so maybe you can confirm what I’m thinking.
You have 2 trunks. You have 2 extensions that use follow me to route a call through those trunks.
One extension when dialed will use the follow me feature to redirect and send the call through your sipgate trunk to whatever destination you have setup.
The other extension uses the follow me feature to redirect the call through your BT SIP trunk, but its currently not working. Is that correct?
Also can you describe the outcome you’re trying to achieve with an example so I can have a better understanding for the above situation. I want to make sure I can give you an answer that wont interfere with what your are trying to achieve.
I’m puzzled. I assume that the Incoming Route for the BT DDI points to extension 4001, which has Follow Me list of
4001 907640320033#
But in step 385 of your log, we see: Dial("Local/FMGL-907640320033#@from-internal-00000021;2", "Local/RG-4001-907640320033#@from-internal ...
As if it’s trying to call a ring group.
My system is very similar (if the desk phone is not promptly answered, ring the mobile) and the equivalent log entry would be: Dial("Local/FMGL-907640320033#@from-internal-00000021;2", "Local/907640320033@from-internal ...
If there is actually a Ring Group involved, try taking that out. If not, please post screenshot of extension 4001 follow me settings.
I guess the next thing would be to maybe take a paste from my logs when I’m doing a call to my Sipgate line (the one which uses my BT line to successfully forward on calls via) and see if that mentions RG?
The problem indicator exist on line 310 on your pastebin. Based on that it could be a couple of things…but if you provide me with a little more info from my last response I can tell you how to fix it.
I want to make sure the solution I give you wont interfere with what you want to achieve.
Sorry, my mistake. I didn’t realize you were doing Confirm Calls, which shares logic with ring groups. I enabled that on my test system to get a log comparison; I’ll let you know when I finish looking at it.
BTW, my log also shows the connected line update prevented noted by @rfreeman1478 and it doesn’t affect function, so I don’t believe it’s relevant.
The connected line update is more of an indicator to me as to what could be happening.
My theory is the PSTN trunk is being considered answered when ever the call gets placed. The call is marked answered whenever the PSTN trunks starts to ring (or possibly error) but is already considered answered on asterisk side and because of that followme stops and the issue with the connected line update may keep the other SIP phone ringing (in relation to ringall strategy being used for followme).
-- Called Local/RG-4001-907640320033#@from-internal
-- Executing [RG-4001-907640320033#@from-internal:1] Set("Local/RG-4001-907640320033#@from-internal-00000022;2", "CDR_PROP(disable)=true") in new stack
-- Auto fallthrough, channel 'Local/RG-4001-907640320033#@from-internal-00000022;2' status is 'UNKNOWN'
The fallthrough is definitely wrong; I suspect that the macro call to dial is missing, possibly from inconsistent module versions.
I suggest that the OP go to Module Admin and update all modules (or at least the relevant ones) and see if the problem persists. If so, test with Confirm Calls off to see if that is needed for the trouble to appear.
That was intended as a test, not a solution. You will need confirmation if you want to ensure that calls never go to mobile voicemail. Also, if the mobile is off, out of range or has a dead battery, mobile voicemail may pick up so quickly that you won’t have a chance to answer on the extension (though you can mitigate that by having e.g. 5 seconds of initial ring time before follow me kicks in).
If you want to get confirmation working, first try updating your modules. If no luck, let’s find the simplest thing that fails. Set up a new Ring Group with your mobile as the only member and Confirm Calls on. See whether dialing the ring group number from an extension works properly.
As a side issue - is it normal that analog trunk calls take quite a while to be accepted/processed by Freepbx/Asterisk before ringing the POTS phones? I find my Sipgate softphone rings instantly when I call it from a mobile but my BT POTS phone takes about five seconds from the call appearing on the command line to it making the phone ring - and it doesn’t appear to be caller ID related because one of the first lines shows the caller ID! I can make a separate thread about this if to answer here would clutter up and derail this thread! EDIT: So because of the fact the call shows up via the command line pretty much instantly I don’t think it’s a delay introduced by the ATA
I’d expect a couple of seconds delay (the ATA reverses polarity, sends caller ID, then starts ringing, with a short delay between steps), but five seems much longer than I’d expect.
The SPA has a syslog feature. On the System tab, point Syslog Server and Debug Server to your PC, set Debug Level to 3, use Wireshark or a syslog server to view the output.
Looks like you might have been onto something. Upgrading modules now. The Ring Groups module had this in the changelog:
**14.0.1.2:** [#14945](http://issues.freepbx.org/browse/FREEPBX-14945) Call Confirm Announcement under Virtual Queue module is broken
**14.0.1.1:** [#14872](http://issues.freepbx.org/browse/FREEPBX-14872) Enable Call Pickup option under Ring Group is broken
