Inbound Route to Sequential Trunks

I’m trying to wrap my head around this, but not quite getting it.

Say I have ten trunks which are all in the same from-trunk context, for which I have eight DIDs and eight inbound routes, how do I route all non-DID calls to the both of the two remaining trunks?

I know I can do an Inbound Route with _XXXXXXXXXX, but it only allows me to select a single destination.

I could switch all trunks to the from-internal context and accomplish the same using the Outbound Routes, but that will require me to constantly reorder the XXXXXXXXXX route to the end of the route list.

Finally, I know I can set the two trunks to from-internal and the remaining two trunks to from-trunk and use both the Inbound and Outbound Routes, but that has the negative effect of routing calls that could go between the eight existing trunks directly to the other two trunks, causing a sip hairpin scenario, which I’m trying to avoid.

Any thoughts anyone?

Please explain the big picture of what your system is trying to accomplish. In a typical business phone system, an Inbound Route points to an Extension, Ring Group, IVR, Queue, etc. Although the call may then be forwarded outside the system e.g. to an agent’s mobile phone, the incoming and outgoing logic are separate. If the Inbound Route works properly and the Outbound Route works properly, the overall call will succeed, without the routes knowing about each other.

You can have an Inbound Route with DID Number left blank (shows as ANY) and it will catch all calls for which the DID doesn’t match a specific route.

If you have trunks that can handle only one call at a time, you can set up your Outbound Route with multiple trunks; when one is busy it will automatically try the next.

With most decent providers, you need only one trunk, which can have as many numbers and handle as many simultaneous calls as you need (and pay for).

Non-DID call?? I think the only way to do this is to have your own context that assigns a dummy DID then go to from trunk. Here’s an example you can modify: DID from provider breaks incoming routes (DID matching)

Sorry, I should have specified that part in my original post.

This PBX acts as a middle man between the PSTN and other FreePBX machines.

Maybe this will help to explain things a bit better. Here is what I currently have working.

Say I have the following DIDs 5145551000, 5145552000, 5145553000, and 5145554000.

There is an outbound route that points to trunk A then trunk B to go to the PSTN. The context for those trunks is from-pstn (which I believe is the same as from-trunk).

There is an inbound route that points 5145551000 to trunk 1, 5145552000 to trunk 2, 5145553000 to trunk 3, and 5145554000 to trunk 4. The context for those trunks is from-internal.

Calls from the PSTN to the assigned DIDs route according to the Inbound Routes, and calls from the internal FreePBXs route to the PSTN via the Outbound Routes.

In a way, you could say that its working as expected. However I’m trying to optimize this one more step because calls between trunks are being routed over the PSTN.

For example, if 5145551000 dials 5145553000 (or vice versa), this is what ends up as a call path.

This is what I’m trying to achieve.

Hopefully this makes more sense now.

I think this can still be done with small bit of custom dialplan:

exten => 5145551000,1,Goto(from-internal,${EXTEN},1)
exten => 5145553000,1,Goto(from-internal,${EXTEN},1)
; additional lines as required
exten => _.,1,Goto(from-pstn,${EXTEN},1)  ; default

Another way which might better match your deployment is to create a “loopback” trunk to/from and just incorporate that into your routing tables.

That gets a little hard to manage as it grows. That’s why I was thinking of only using from-pstn with all trunks since it matches all the digits before the patterns, so I can just add _XXXXXXXXXX for the PSTN Inbound Route (and it does work, I tested it). The only issue is that I can only specify a single trunk in an Inbound Route. I tried using ring groups, but I can’t call trunks using ring groups.

Maybe something can be done with the Custom Destinations, Misc Applications, or Misc Destinations modules, but I’m not sure.

The loopback trunk seems like an interesting idea, although I’m not sure how I could use that without it turning into an infinite loopback.

that would depend on you NOT creating a reentrant route :wink:

There is this script that I had almost forgotten about, you might be able to adapt it:

How do you propose to use the loopback trunk?

I like your script. Its much more scalable. It would work as long as the database and dialplan hooks don’t change over time.

Part of the reason I was looking for something that might be more “standard” is to avoid some of the breaking changes that could come from updates.

Considering that the only thing I need to be able to use the Inbound Routes _XXXXXXXXXX solution is to have a cascading destination that I can select in the UI, perhaps one to the modules could allow me to map a ficticious extension to a Dial string for a specific trunk. Something like extension 10 to dial trunk A and then extension 20 to dial trunk B (perhaps in the Misc Extensions module). This way I could setup a sequential ring group and dial those trunks sequentially.

Outbound routes that would end up on another internal PBX (effectively all your inbound DID’s) get sent to the loopback trunk which re-presents the DID in the from-trunk context. Thus 1) dialing a did on 3) ‘loops back’ and does not go through the PSTN.

That would require creating an Outbound Route that matches each of the DIDs and pointing that route to the loopback trunk, which is essentially the same as creating an Outbound Route per DID and pointing that at each trunk. No?

That is almost correct, you simply add an outbound route for the new DID to go to the loopback trunk (not each trunk) at the same time you add the DID, yep it takes another 20 seconds :slight_smile: .

Ok, but here’s a question. Wouldn’t that loopback method create two bridges per inter-DID call?

That would be just two bridges which is both less in count and far cheaper in dollars and bandwidth than the four you are creating now.

Asterisk is a Back2BackUA so of course for an endpoint on 1) to connect to an endpoint on 3) with media there would be an SDP bridge between the PBX and 1) and another between PBX and 3).

if you can enforce direct media (no natting allowed here :wink: ) you could redirect the RDP traffic but the SIP connections would remain

If you want to do it more elegantly and with far more flexibility , explore replacing your PBX with a real SIP Proxy (Kamailio comes to mind)


This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.