FreePBX | Register | Issues | Wiki | Portal | Support

Unconditional Call Forwarding conflicting with FMFM


(Mulderlr) #1

Similar to this thread, Call Forward Unconditional (*72) reverts to * VM

I am having an issue with FPBX 13, 10.13.66-21. When users use UCP (13.0.42.6) to change an extensions settings to call forward unconditional enabled to an outside number (eg 8775551234), the forwarding tries for 2 seconds, then tried the FMFM list. According to the documentation, call forward unconditional should be just that - unconditional. It should not be 1. timing out after 2 seconds, and 2, not trying FM/FM after 2 seconds. I am not sure why these two features conflict, but this seems to be a new development for the users of this system. If FMFM is disabled, the unconditional CF seems to work, but it should work correctly regardless IMHO.

Any insight as to whether this is normal behavior, a bug, a setting we are missing or any other help would be appreciated.

Thanks!


(Tom Ray) #2

FindMeFollowMe checks are done first, if the FMFM settings on the extension (such as Pre/Initial Ring) are set with long enough timers, the CF will kick in when the extension is called.

If your Pre/Initial Ring time is set to low the CF is being hit but the PBX (FMFM) is cancelling the call because the ring timer for it was hit and it considers it a time out, then it continues on with the FMFM logic.


(Mulderlr) #3

Ok. I appreciate the clarification. I’m not sure I understand the point of it working this way. I am pretty sure that if call forwarding unconditional was supposed to be called from an enabled FM/FM list, the UCF number could just be in the FMFM list with the same effect. So this seems counter-intuitive or counter-productive at least, but at least now I know how to deal with it. Further clarification in the help text on CF with regard to FM/FM would have been helpful. I am not sure if this has already been done in FPBX 14/15/16/etc?


(Tom Ray) #4

Because as the documentation and tool tips state, enabling FollowMe makes the system look the FollowMe settings first because FollowMe can divert the call from ringing the extension directly.

FollowMe has the Pre Ring setting to call the extension on its own first, then go the the list. Like I said, if you have that set to 7 (the default) or something low it’s going to ring the extension for those X seconds. This is why you CFU is ringing and then cutting off. It’s only ringing for X seconds and it expects the answer in X seconds.


(Mulderlr) #5

Hmm, okay, here is what my UCP says about each feature. FMFM:
FMFM%20152057

CFU:
CFU%20152057

All I am trying to say is that “Forward Immediately” is not very immediate if FMFM is called first.


(Tom Ray) #6

“Regardless of current state”, that would be INUSE, NOT_INUSE, BUSY, UNAVAILABLE, etc. In order to get those states, it must attempt to call the extension.

When FMFM is enabled, as it states there, it doesn’t call the extension directly, it uses the followme logic. If that logic says “call extension directly for X seconds before going to list” that is what it will do.

So if you want to have CF always going AND FMFM enabled, then the Pre Ring must be as long as the CF ring timer (default 20 seconds) so that it can do the CF without timing out and moving on to the list.


(Mulderlr) #7

I get how it works and how the call flow goes, so I am in no way disputing what is, just the documentation that could have been a little more clear. It isn’t even so much for me as the pbx admin, but that we have to prove to end users of the system that they are wrong by pointing to documentation that used conflicting language (ie instead vs immediate). That is all. Again, I appreciate you taking the time to clarify this here for which I was successfully able to use with the end user. I think we are good!


(Lorne Gaetz) #8

If you think the tool tip(s) can be improved, file feature requests with your suggestions. Pushing changes is problematic in that it messes up existing translations, but changes can be added to the Wiki and on major releases.


(Mulderlr) #9

sounds good. thanks!