[asterisk-users] Unexpected behavior change from Asterisk 1.6.2.14 to Asterisk 1.8.5.0

Thu Sep 1 12:16:40 CDT 2011

In our office, we were running an Asterisk 1.6.2.14 machine with DAHDI 2.3.0.1, FreePBX 2.8.1 and an analog DAHDI card with 8 FXO ports. This machine had several DAHDI trunks defined in the FreePBX interface, each one containing a single DAHDI channel. It 
also had a few outgoing routes defined in FreePBX, each of those grouping several of these DAHDI trunks. This setup worked correctly until the hard drive started failing. After backing up most of the data, we changed the hard drive and installed Asterisk 
1.8.5.0 and DAHDI 2.4.1.2 with the same FreePBX 2.8.1. We then noticed that outgoing calls using the analog card were failing if the first tried channel was busy, instead of trying the next channel in the outgoing route. We traced this problem to a 
situation described in a FreePBX ticket: http://www.freepbx.org/v2/ticket/5008 . The logs in the old hard drive showed the following whenever a channel was busy:

[2011-08-30 08:55:39] VERBOSE[2597] pbx.c:     -- Executing [s at macro-dialout-trunk:19] Dial("SIP/514-000007bb", "DAHDI/4/3904170,300,tTwW") in new stack
[2011-08-30 08:55:39] WARNING[2597] app_dial.c: Unable to create channel of type 'DAHDI' (cause 0 - Unknown)
[2011-08-30 08:55:39] VERBOSE[2597] app_dial.c:   == Everyone is busy/congested at this time (1:0/0/1)
[2011-08-30 08:55:39] VERBOSE[2597] pbx.c:     -- Executing [s at macro-dialout-trunk:20] NoOp("SIP/514-000007bb", "Dial failed for some reason with DIALSTATUS = CHANUNAVAIL and HANGUPCAUSE = 0") in new stack
[2011-08-30 08:55:39] VERBOSE[2597] pbx.c:     -- Executing [s at macro-dialout-trunk:21] Goto("SIP/514-000007bb", "s-CHANUNAVAIL,1") in new stack
[2011-08-30 08:55:39] VERBOSE[2597] pbx.c:     -- Goto (macro-dialout-trunk,s-CHANUNAVAIL,1)
[2011-08-30 08:55:39] VERBOSE[2597] pbx.c:     -- Executing [s-CHANUNAVAIL at macro-dialout-trunk:1] Set("SIP/514-000007bb", "RC=0") in new stack
[2011-08-30 08:55:39] VERBOSE[2597] pbx.c:     -- Executing [s-CHANUNAVAIL at macro-dialout-trunk:2] Goto("SIP/514-000007bb", "0,1") in new stack
[2011-08-30 08:55:39] VERBOSE[2597] pbx.c:     -- Goto (macro-dialout-trunk,0,1)
[2011-08-30 08:55:39] VERBOSE[2597] pbx.c:     -- Executing [0 at macro-dialout-trunk:1] Goto("SIP/514-000007bb", "continue,1") in new stack
[2011-08-30 08:55:39] VERBOSE[2597] pbx.c:     -- Goto (macro-dialout-trunk,continue,1)
[2011-08-30 08:55:39] VERBOSE[2597] pbx.c:     -- Executing [continue at macro-dialout-trunk:1] GotoIf("SIP/514-000007bb", "1?noreport") in new stack
[2011-08-30 08:55:39] VERBOSE[2597] pbx.c:     -- Goto (macro-dialout-trunk,continue,3)
[2011-08-30 08:55:39] VERBOSE[2597] pbx.c:     -- Executing [continue at macro-dialout-trunk:3] NoOp("SIP/514-000007bb", "TRUNK Dial failed due to CHANUNAVAIL HANGUPCAUSE: 0 - failing through to other trunks") in new stack

In the old setup (with Asterisk 1.6.2.14), the error type reported by app_dial was 0-Unknown and the dialing status was CHANUNAVAIL.

[Aug 31 12:10:13] VERBOSE[17513] pbx.c:     -- Executing [s at macro-dialout-trunk:19] Dial("SIP/213-000000e7", "DAHDI/5/2201177,300,tTwW") in new stack
[Aug 31 12:10:13] WARNING[17513] app_dial.c: Unable to create channel of type 'DAHDI' (cause 17 - User busy)
[Aug 31 12:10:13] VERBOSE[17513] app_dial.c:   == Everyone is busy/congested at this time (1:1/0/0)
[Aug 31 12:10:13] VERBOSE[17513] pbx.c:     -- Executing [s at macro-dialout-trunk:20] NoOp("SIP/213-000000e7", "Dial failed for some reason with DIALSTATUS = BUSY and HANGUPCAUSE = 17") in new stack
[Aug 31 12:10:13] VERBOSE[17513] pbx.c:     -- Executing [s at macro-dialout-trunk:21] Goto("SIP/213-000000e7", "s-BUSY,1") in new stack
[Aug 31 12:10:13] VERBOSE[17513] pbx.c:     -- Goto (macro-dialout-trunk,s-BUSY,1)
[Aug 31 12:10:13] VERBOSE[17513] pbx.c:     -- Executing [s-BUSY at macro-dialout-trunk:1] NoOp("SIP/213-000000e7", "Dial failed due to trunk reporting BUSY - giving up") in new stack
[Aug 31 12:10:13] VERBOSE[17513] pbx.c:     -- Executing [s-BUSY at macro-dialout-trunk:2] PlayTones("SIP/213-000000e7", "busy") in new stack

In the new setup (with Asterisk 1.8.5.0), the error type reported by app_dial is 17-User busy and the dialing status is BUSY.

The FreePBX context is programmed so that it considers BUSY, along with NOANSWER, INVALIDNMBR and CHANGED, as nonrecoverable errors that abort the dialout attempt, which seems reasonable. The problem is that the new setup is returing BUSY instead of 
CHANUNAVAIL when the particular channel that was tried is in use by a different call. We worked around the issue by applying the recommendation suggested in the ticket (create DAHDI groups in chan_dahdi.conf and use these as trunks). However, I believe the 
previous behavior was correct and the new behavior to be in error. The workaround suggested by the ticket will not work in a scenario where a DAHDI group has all of its channels busy with calls, and the administrator intends additional calls to be routed 
through non-DAHDI trunks (such as SIP/IAX trunks or custom trunks).

My questions:

Is the new behavior the intended one?
If the new behavior is intentional, then how should I set up an scenario in which calls will be routed through SIP when all DAHDI channels are in use, yet will not try to route calls through SIP when the destination is truly busy?
If the new behavior is a bug and not intentional, at what level should I look for the problem? At Asterisk, or at the driver level? The card is an OpenVox card (opvxa1200) for which source code is available.