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@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@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@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@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@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@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@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@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@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@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@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@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@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.
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
