Trunk Call Forward

I’m relatively new to freepbx but think I have an OK understanding of most of what I’m asking. We have SIP Trunks into our building connected to our FreePBX. From there we have customer PBX’s connected via Trunks to our FreePBX and then routed out our SIP trunks.

When call for a DID to another trunk comes in on our SIP, the FreePBX routes the calls to custom destinations using the extensions_custom.conf file.

Because of this… UCP call forwarding does not work. I get that, I can make it work for regular extensions but not for the trunks… so is there a solution to this? How would I go about doing this, and can I do this where the customer is able to login and make these changes? I was debating trying to write code to read the db and route to a different trunk if this option is set for that DID / ucp user.

The customer is in a remote location and in the event of power loss, or seasonal shut down they want to call forward the number to X or Y number.


I appreciate you taking the time to review this.

Just so we’re all speaking the same language:

  • Trunks connect your PBX to another PBX, either unidirectionally or bidirectionally, depending on the remote provider’s needs. So, it’s possible for a single trunk to support many, many numbers to a single location through a single trunk.

  • On an inbound call (from any of your trunks), the Inbound Route is selected based on inbound DID or inbound CID (or, far less commonly, both). It is, therefore theoretically possible for calls from all of your numbers to come in on the same trunk.

  • For outbound calls, the trunk selection is based on the ordered list of trunks in the outbound route.

Once the number is received by your PBX, it is locally routed to the appropriate destination, which could be a queue, a ring group, or an extension.

So, based on the description above, the referenced scenario can’t really happen. If the server is shutdown for power, the call will never be processed by your PBX, so no amount of settings will make any difference. In this case, you need to have a failover destination set up at your ITSP so that, when the call fails to the PBX, it gets routed somewhere else. If, on the other hand, the PBX is on and can route, the calls will be routed based on the outbound route settings, which should include some sort of failover (for a queue or ring group that doesn’t get answered, for example).

You could set up time conditions (which can be toggled manually) which then send the calls to another destination (another facility or office) but these aren’t likely to be sent to a trunk. They are more likely send to some sort of custom destination and processed that way.

So, based on this, UCP call forwarding should actually work, since you are allowing the CF to process on the local machine unless it’s unreachable. It sounds like you may have overcomplicated your setup and killed UCP in the process. It may also be that you are trying to do something that Asterisk and FreePBX don’t do very well, such as trying to set FreepBX (which is a back to back user agent or B2BUA) as some kind of SIP proxy. If that’s the case, your solution may be to start using a real SIP Proxy like Kamillio as your front end to route the calls appropriately.

Because of the hypothetical nature of your question, though, it’s hard to say for sure.

Thanks for the input. You are correct, if our PBX went down routing would fail. UCP is call forwarding to Extensions that are not using… a custom destination. the ones that are, UCP does not work, I sense because of the custom destination, and it doesn’t know to use anything else… I think UCP might just say try that number… via the custom destination… Does that make sense?

Also, thank you for the detailed definitions on inbound route vs trunk. Unfortunately the previous person that set this up seems to have done certain things strangely as we only have inbound routes and no outbound routes.

Wait - what?

That supports my position that your system may be a little over complicated. Without outbound routes, you can’t get calls out of the system unless you do some crazy stuff with your custom contexts and process calls through directly to trunks, but that would WAY over-complicate what would normally be a relatively simple setup.

I discovered we in fact do have some (I was confused and have the flu atm) either way I solved our problem. Things are working now, although it might be a little more complicated then it should be :slight_smile:

Thanks for all your advice.

Previously I had Inbound Route -> Custom Destination

Now I have Inbound Route -> Extension -> Custom Destination (via Find/Follow me). This allows the extension to use UCP to enable the custom destination via find/follow me, or set call forwarding to an external number.