I would like to know if I can set unconditional call forwarding on an extension but allow direct calls from the extension it is forwarded to.
Example:
Extension 100 sets call forwarding (unconditional) to extension 101.
All calls to 100 are immediately forwarded to 101 as expected.
However, if 101 tries to transfer a call to 100 or tries to call 100 directly, it sounds “busy” because it obviously goes into a loop where 101 tries to call itself.
How do I set an “exception” so that 101 can actually call 100 even if the latter is forwarded to 101?
I am looking at the dialparties.agi code but it seems that this situation hasn’t been foreseen. Or has it?
Conditional call forward. I remember seeing somebody who published some code for it someplace Have you checked over at http://www.voip-info.org I think that’s where I saw it.
Most likely it would be pure asterisk code which will need to be adjusted as I’ll bet the directions will say to add it into the extensions.conf instead of extensions_custom.conf in FreePBX’s case.
However, I’m unable to find anything related to my scenario which is quite surprising because it should be a “common” situation.
Imagine your company’s boss on extension 100 (as in my example) who doesn’t want to attend calls directly so he/she forwards to his/her seretary on 101. The secretary then knows whether she can: - call his/her boss directly or - transfer calls to him/her either via blind or attended transfers.
All the “conditional” call forwarding examples I’ve seen on the Internet are basically what’s already implemented within FreePBX: CF on Busy, CF on Unavailable. Neither of the two can be applied to my case.
It should be “trivial” though. The “condition” is “CF unless caller ID number == 101”.
The changes to dialparties.agi I posted above work fine in all cases I’ve tested except one: somehow, when I use Asterisk’s built-in attended transfers (default *2), the asterisk CLI shows that the “realcallerid” number is wrong so I can’t identify the source correctly. It’s “completely wrong” in the sense that an extension number I’ve never even created shows up (say, 199). Very odd. It must be an Asterisk bug for attended transfers (tested on 1.2 only).
Anyway, “client-side attended transfers” (eg. using the R/flash keys on ATA phones) work fine.
I’d rather not hack dialparties.agi so if you have an idea or a link you can point me to, I’d be grateful.
We do it a different way. Assign the CEO two extensions. One is the public known one and it only goes to the Secretary, the real one is hidden and she can transfer to it. You just adjust the voicemail settings properly so say what you need it to say.
So in your case Secretary has two extensions on her phone. 101 (primary #) and 100 (Bosses number as second #), the Boss has a phone with extension 899, The boss can even record the voicemail greeting for extension 101.
Most boss’s also want a way for his/her spouse to be able to dial them directly and this solve that problem also as they give out the the true extension on their desk.
Your solution is fine but it still doesn0t quite achieve what I have in mind.
In your example, extension 899 is a direct call to the boss and anyone can dial it, supposing they know it. I don’t want to run the risk of someone “guessing” the extension and then have to change the boss’s number just for that.
Besides, as I stated in the trac issue, the behavior I’m trying to get in FreePBX is “standard” in many commercial PBX systems such as the Alcatel 4400.
In my opinion, we should also have this when the phone has DND active and we have Follow Me configured, so that the or all callers in the Follow Me list should be able to call that extension anyhow.
Anyone agrees?
I’ve posted a feature request for this and am working on a patch, see http://www.freepbx.org/trac/ticket/4229
I would not agree that any caller in the FollowMe list of an extension should always have DND ignored by that extension when they are being called.
Loop detection is obviously important but setting the described behavior is not necessarily what people expect.
I’m also always a little wary of implementing features that will behave differently for server side vs. client side features though sometimes it can’t be helped.