Edit - Follow Me is irrelevant, it happens anyway with or without Follow Me.
If a caller is presenting the same CLI that the User has entered into the Call Forwarding widget in UCP (Unconditional Enabled), it ignores the Call Forwarding as if it is “Disabled”.
Not sure if I have found a bug or a feature and wanted to check before just working around it. I don’t have any need to “fix” this or spend too much time looking into it right now, but if it is a feature meaning “Well obviously because…” then that’s fine, I will tell the end user the same if it comes up. If it’s a bug, then I will report it. Perhaps I am missing something obvious.
FreePBX 14.0.13.24
Asterisk 13.29.2
User Control Panel 14.0.3.8
Extension Settings 13.0.4
A scenario where this might be problematic, I suppose, is when a User diverting their Extension to the main office number using UCP is then called by a colleague presenting that number. The divert won’t work. For argument’s sake, let’s just assume they call the DDI rather than calling internally and Presence etc doesn’t apply.
FollowMe is checked before the local extension routing is checked. If FollowMe is enabled, it immediately does FollowMe and if FollowMe is not answered it jumps into the extension routing to check for Alternate Destinations, call fowarding and voicemail.
Hi Tom, Yes I was able to replicate it, break it and unbreak it. The only influencing factor when every other variable stays the same is if the presenting number of the caller matches the number the called party wants to divert to.
So yeah, if I call my extension from my cell phone and I have my unconditional forwarding setup it won’t forward the call because then it’s calling me. All I’m doing is looping a call back to my cell phone. So why would it forward the call to the place the call is coming from? That doesn’t make much sense.
I’m not sure you example scenario is one that is used a lot. If I was to be out of the office and I wanted someone else to take my calls, I would FollowMe/CF to them directly not back to the main DID so it makes an outbound call to come back into the PBX. Also there is no reason, ever, for the users to be calling DDI’s to reach each other, that’s what the PBX is for. That is just wasting actual channels for real calls to/from the PSTN when they could have just dialed internal extensions.
So again, I’m not sure what real use case would require someone to want to CF a call that is coming from the CF destination and loop the call.
Thanks. That’s no problem and what I thought. We stumbled across it accidentally as we routinely divert extensions to the main office IVR when away, but we probably haven’t ever tested it from an extension presenting that same number. Thanks for the detailed explanation, I will borrow it if it ever comes up. Although as you rightly point out, that’s highly unlikely.
No problem. Don’t forget nothing says Call Forward has to be to a PSTN routed destination. Again, I could just CF to extension 200. If 200 was to call me with CF enabled, it would ignore forwarding the call back to extension 200. Same reason, looping.
Sure there is, it’s because the users don’t know any better. For example, they call the number printed on a business card. Many systems have loopback trunks set up for this purpose, or have contexts arranged so the calls route internally, keeping them off the PSTN.
But isn’t that the point of us? I find spending the time to train the users on how to use things is much more efficient than maintaining extraneous things like loopback trunks for using DDI’s as the method to do internal calling.