> 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. > I think the new behavior is a bug. It is most likely in chan_dahdi.c:dahdi_request() when it finds that the requested channel or no channels in the group are available.
Richard -- _____________________________________________________________________ -- 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