Trunk Sequence For Matched Routes Does Not Failover

General Help
1

Hi All,

I have become frustrated in trying to get the trunk sequence for matched routes to failover when the first trunk in the list is busy.

The system in question is running Freepbx v2.9.0.7 and Asterisk 1.87. In this particular instance, the first outbound trunk is an analog POTS circuit terminated on a DAHDI card, and the second outbound trunk is a SIP trunk. Local/toll free calls ONLY are routed to the DAHDI card, and my intention is to have all long distance calls routed out the SIP trunk, as well as local calls, but only if the DAHDI circuit is busy.

My understanding is that the TRUNK SEQUENCE FOR MACHED ROUTES setting should accomplish this, but this does not appear to be the case for some reason if the DAHDI trunk is listed first. If the SIP trunk is listed first, then the behavior is as I would expect it to be, (calls will failover to the DAHDI trunk if the SIP trunk is busy). Unfortunately, this scenario does not meet my needs, since the SIP trunk can be tied up by a local call that could have been serviced by the DAHDI trunk, and if the second call is to a long distance number, then it will fail for lack of a trunk that will allow the route.

If the DAHDI trunk is listed first, Local calls route out the first trunk correctly. Calls that are not local route out the SIP trunk correctly. However, if the DAHDI interface is busy, then any subsequent local/toll free calls fail with a dialstatus busy, and without ever attempting to use the SIP trunk, (see below).

If I reverse the priority order of the trunks such that the SIP trunk is first in the list, then all calls regardless if local or long distance will go out the SIP trunk as I intended. Thus I have verified that the dial patterns in use are doing what I want them to, but the failover in the event of a busy circuit is not working.

If anyone has any idea on how to resolve this, I am all ears.

-- Executing [s@sub-flp-1:798] Return("SIP/100-00000004", "") in new stack
-- Executing [s@macro-dialout-trunk:13] Set("SIP/100-00000004", "OUTNUM=w18667794747") in new stack
-- Executing [s@macro-dialout-trunk:14] Set("SIP/100-00000004", "custom=DAHDI/1") in new stack
-- Executing [s@macro-dialout-trunk:15] ExecIf("SIP/100-00000004", "0?Set(DIAL_TRUNK_OPTIONS=M(setmusic^default)tx)") in new stack
-- Executing [s@macro-dialout-trunk:16] ExecIf("SIP/100-00000004", "0?Set(DIAL_TRUNK_OPTIONS=txM(confirm))") in new stack
-- Executing [s@macro-dialout-trunk:17] Macro("SIP/100-00000004", "dialout-trunk-predial-hook,") in new stack
-- Executing [s@macro-dialout-trunk-predial-hook:1] MacroExit("SIP/100-00000004", "") in new stack
-- Executing [s@macro-dialout-trunk:18] GotoIf("SIP/100-00000004", "0?bypass,1") in new stack
-- Executing [s@macro-dialout-trunk:19] GotoIf("SIP/100-00000004", "0?customtrunk") in new stack
-- Executing [s@macro-dialout-trunk:20] Dial("SIP/100-00000004", "DAHDI/1/w18667794747,300,tx") in new stack

[Oct 29 02:48:57] WARNING[17695]: app_dial.c:2198 dial_exec_full: Unable to create channel of type ‘DAHDI’ (cause 17 - User busy)
== Everyone is busy/congested at this time (1:1/0/0)
– Executing [s@macro-dialout-trunk:21] NoOp(“SIP/100-00000004”, “Dial failed for some reason with DIALSTATUS = BUSY and HANGUPCAUSE = 17”) in new stack
– Executing [s@macro-dialout-trunk:22] Goto(“SIP/100-00000004”, “s-BUSY,1”) in new stack
– Goto (macro-dialout-trunk,s-BUSY,1)
– Executing [s-BUSY@macro-dialout-trunk:1] NoOp(“SIP/100-00000004”, “Dial failed due to trunk reporting BUSY - giving up”) in new stack
– Executing [s-BUSY@macro-dialout-trunk:2] PlayTones(“SIP/100-00000004”, “busy”) in new stack
– Executing [s-BUSY@macro-dialout-trunk:3] Busy(“SIP/100-00000004”, “20”) in new stack
== Spawn extension (macro-dialout-trunk, s-BUSY, 3) exited non-zero on ‘SIP/100-00000004’ in macro ‘dialout-trunk’
== Spawn extension (from-internal, 18667794747, 5) exited non-zero on ‘SIP/100-00000004’

2

I found the solution to the problem, and will post it here in the hope that it will benefit anyone else who happens up this ame scenario.

The Maximum Channels setting in the DAHDI trunk configuration had been left blank. Once I updated this to 1, the failover on a busy trunk works fine. Presumably since this setting had been left blank, Asterisk assumed that there was still a channel available and would not try the SIP trunk even though it was unused.

3

I have been having the same problem since the last update to the PBX framework. The above solution works when the first line is use with an outbound call. However, the Maximum Channels setting is not used by inbound calls. So once someone calls me on the first line, no one is able to call out without using a separate outbound route with a direct dial digit (like dial 9 for line 2).

Has something changed in the framework to change this behavior? It never used to be an issue.

Does anyone have any suggestions on how to get around this?

4

@gicandles Confirmed, I had encountered the same problem today.

5

I have the same problem. However, the Maximum Channels setting on the four DAHDi trunks we set up were already set to 1. So, go figure.

6

Once a busy status is encountered it stops trying additional trunks that might be in the outbound route.

You can work around it; see: http://www.freepbx.org/forum/freepbx/general-help/doesnt-fail-over-to-second-trunk-when-a-603-declined-is-given-how-to-fix-#comment-45682

7

I was having the same problems, and come across this post. I also notice the workaround method mentioned above by SpaethCo, but before trying that, I tried grouping Dahdi trunks and it works. Details below:

6 dahdi trunks:

  • Failover failed if I create 6 separate dahdi trunks, and assign all 6 under Trunk Sequence of an outbound route.

  • My solution is using group, defined in /etc/asterisk/chan_dahdi.conf. Failover works with the default group g0 being the only option under Trunk Sequence. (remember to specify maximum channel)

  • Moreover, I can divide them into 2 groups (with maximum channels of 3): g0(1,2,3), and g1(4,5,6) to use for 2 separate outbound routes. This setup still work properly.

Hope this help save you some time.

Regards,
Bao Nguyen

8

@nttranbao Thanks, this works well.