When to use the different trunk scripts in outbound routes

Forums

We are trying to figure out when to use the various trunk scripts and have a few questions:

- Dial Out (1 trunk)
- Dial Out (1 trunk) pass through
- Dial Out (2 trunks)

1) What does the passthrough version mean? Looks like it may be something to do with the callerid being passed through.
2) We assume that the 2 trunk allows us to set a backup route that is used if the first trunk rejects the call. However when we test it, if the first trunk gives a 603, the call stops and doesn't try the second trunk. Are there any options we need setup?
3) Dialing a DID that exists in TL, either in the same tenant or another: Is there an option to route the call internally rather than hairpinning the call out to the trunk and back in again. Do any or all of them do this? In our testing, calling to an internal did always goes on the outbound route with all 3 types of trunk. ois there a way to stop this?

Thanks

Submitted by thirdlane on Tue, 03/14/2017 Permalink

1) yes, when you want to preserve the inbound callerid - possibly when getting a call from a pbx
2) we'll have to check
3) yes, you can do this by setting TL_REROUTE_LOCAL_DIDS global dialplan variable to 1

Submitted by Dougster on Mon, 03/27/2017 Permalink

We have set TL_REROUTE_LOCAL_DIDS=1, but calls to DIDs in the same tenant and pbx are still routing out to our gateway and back in again. Is there anything else that needs to be done to avoid hairpinning calls out and in again?

Submitted by thirdlane on Tue, 03/28/2017 Permalink

This should be enough, and should work as long as the dialed number matches the DID exactly. Please take a look at the CLI to see what may be going on - whether the script tries to do the lookup and what happens.

Submitted by netriplex on Tue, 03/28/2017 Permalink

Doug,

Some things I have noticed when using this feature...

Essentially, your SIP trunk provider needs to essentially support dialing numbers outbound with the same format that you have numbers configured for the inbound DIDs. Then, you need to configure your outbound routes to strip/prepend digits so that the numbers dialed will match the DIDs configured in the inbound routes.

I am unsure if you are US based or not, but I will provide examples for US configurations and where the "mismatches" usually come in:

If your provider sends DIDs in to your PBX without a "+" and without a "1", it is usually formatted NPANXXXXXX or as an example 4085551234. You then create a inbound route with the DID in exactly this format.

You then have a user that dials out to call this number and dials out by dialing 14085551234. Because of the proceeding "1", the DID does not match exactly and the call is not rerouted. To resolve, this you need to set your outbound route that matches 1NXXNXXXXXX to strip 1 digit, so that only 4085551234 is actually attempted to be "dialed" so that a match is found.

Also, what version of Thirdlane are you using as there was a problem with the script at one point that we submitted the fix for that I believe was incorporated in the most recent Thirdlane revisions.

Submitted by Dougster on Wed, 03/29/2017 Permalink

You are right. The DID needs to match the number after prefixes have been added for the route rather than the number that was dialed.
Example...
Our DIDs are 10 digits. Out of habit we prefix a 1 when the user dials 10 digits before sending to the gateway, which means that isn't recognised as an internal DID. Our gateway can accept 10 digits as well, so removing the prefix meant that the number was routed internally.