Preventing calls from being transferred to paging extensions

Hi all

I use freepbx-2.2.2.
I have a paging group extension. Often my users unvoluntarily transfer incoming calls to this paging extension. This leads to a big confusion. Is there a way to prevent some extension / group / paging group to accept redirected calls?

Just for information, I have the CustomContexts and Dialplan Injection patches installed, maybe they can be useful to solve the problem?


What method are your users transferring calls? Are they using the transfer capabilities of the SIP phones, or are they using the asterisk transfer features to complete the calls.

One possible method that comes to mind is the ability to create a “custom” feature in features.conf and point it to your own xfer context that only allows for transfers to certain extensions, or disallows to certain extensions. This would only be useful if you are using the server to perform all the transfers, and not the SIP phone transfer feature.

Perhaps an easier solution might be to use 2 digit dialing for paging and 3 digits for your extensions or some other methodology where it would be more difficult to make the mistake.

They use the phone’s capability. The phones are Snom 320.
I can happily switch to server-side transfers, I think. I’m pretty new to Asterisk, I didn’t even know about this possibility.

I’ll think about it.

hhmm… The fact is not that the user confuses the paging extension with a normal one, and she passes the call to the paging as it would be a normal user. From what I was able to see (I’m not sure the user’s behaviour does not change) the problem happens like this:
There are 3 entities involved: the caller C, the user U who answers the call, the desired destination user D which is different from U. C was looking for D.
An inbound call arrives, U answers the call.
C is searching someone else, so U puts the call on hold, and pages for D. C is still on hold.
U puts the phone on-hook (he wanted to free the phone, to receive D’s call asking to transfer C to him). Doing so C is transferred to the paging extension.

It sounds like the user (U) might be hitting the telephone transfer button instead of hold, which still places the caller © on hold, then dialing the paging extension, which allows U to page for the desired D (Destination person). Upon hanging up the phone, the C is then connected to the paging extension.

If they hit hold instead of transfer to begin with, this wouldn’t happen. You might want to give that a try. I don’t have experience with SNOMs, only Polycoms. But essentially the same idea should apply to both.[/quote]

why don’t you put in a feature request (hmm - maybe it’s even a bug) to trac that blocks blind transfers from hitting a paging group. One could always do an attended transfer but I don’t think allowing a blind transfer should ever be possible. (It is not hard to block, it is a little more work to reroute the transfered call to somewhere useful though)


I’m going to post the feature request.
Blocking blind transfers should be enough for me, since it seems hard to imagine a user doing an attended transfer unvoluntarily.
In the meanwhile, do you have a suggestion about how to block access to my paging extension for call transfers in current freepbx?
For my current situation, it would be acceptable even if the call was completely disconnected. A better solution would be to pass the call to an IVR.

I can think of two options off the top of my head. The first would be with the BLINDTRASFERER channel variable. Although I’m not sure how it would work if the call was transfered from a non-sip extension (never tried that one).

The other way would be to use the TRANSFER_CONTEXT variable in conjunction with properly setup contexts. You could do the same thing that I do with the bad_number context. Under normal dialing, if you dial a wrong number, you get Allison telling you you dialed a wrong number. However, you don’t want to transfer someone to a mis-typed number and drip the call. So bad_number context is not included in the TRANSFER_CONTEXT. (see from-internal and from-internal-xfer in extensions.conf). So you would also not include paging groups an anything else you were trying to block.

So … post the issue (go ahead an put it as a bug, we’ll decide if it should change to a feature request). It requires a bit of re-arranging of things if we decide to implement it this way.

I created the bug in trac, it has ticket # 2110.
Thank you all for your suggestions.