Alex, Please post the bug report on the bug tracker. Then your fix has a chance to be incorporated in a future release.
Thank you, Vladimir On 9/12/2011 1:28 PM, Alex Villacís Lasso wrote: > El 01/09/11 14:11, Richard Mudgett escribió: >>> 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 > On examination, I see the following differences in > channels/chan_dahdi.c at the end of dahdi_request: > asterisk-1.6.2.20: > if (callwait) > *cause = AST_CAUSE_BUSY; > else if (!tmp) { > if (channelmatched) { > if (busy) > *cause = AST_CAUSE_BUSY; > } else if (groupmatched) { > *cause = AST_CAUSE_CONGESTION; > } > } > asterisk-1.8.6.0: > if (cause && !tmp) { > if (callwait || channelmatched) { > *cause = AST_CAUSE_BUSY; > } else if (groupmatched) { > *cause = AST_CAUSE_CONGESTION; > } else { > /* > * We did not match any channel requested. > * Dialplan error requesting non-existant > channel? > */ > } > } > > In 1.6.2.20, the variable called 'busy' is set when the channel > signaling is SIG_FXOKS/SIG_FXOLS/SIG_FXOGS, which I take to mean that > 'busy' is set when the telephony port used is FXS. In our case, the > card is entirely FXO and connects to the PSTN, so 'busy' remained at > 0, and *cause remained unset (presumably with value 0). In 1.8.6.0 the > signaling is no longer relevant, and results in *cause set to > AST_CAUSE_BUSY. > > I am testing the following patch: > diff -ur asterisk-1.8.6.0/channels/chan_dahdi.c > asterisk-1.8.6.0-new/channels/chan_dahdi.c > --- asterisk-1.8.6.0/channels/chan_dahdi.c 2011-08-03 > 08:38:17.000000000 -0500 > +++ asterisk-1.8.6.0-new/channels/chan_dahdi.c 2011-09-11 > 06:21:48.000000000 -0500 > @@ -13440,6 +13440,7 @@ > if (!p) { > /* We couldn't determine a starting point, which likely means > badly-formatted channel name. Abort! */ > ast_mutex_unlock(&iflock); > + if (cause) *cause = AST_CAUSE_CHANNEL_UNACCEPTABLE; > return NULL; > } > > @@ -13566,7 +13567,7 @@ > restart_monitor(); > if (cause && !tmp) { > if (callwait || channelmatched) { > - *cause = AST_CAUSE_BUSY; > + *cause = /*AST_CAUSE_BUSY*/ AST_CAUSE_CONGESTION; > } else if (groupmatched) { > *cause = AST_CAUSE_CONGESTION; > } else { > @@ -13574,6 +13575,7 @@ > * We did not match any channel requested. > * Dialplan error requesting non-existant channel? > */ > + *cause = AST_CAUSE_CHANNEL_UNACCEPTABLE; > } > } > > This essentially treats channels the same way as groups, and signals > congestion for both of them. However, I want to know the rationale > behind discrimination between channels and groups. If AST_CAUSE_BUSY > is supposed to mean that the destination side is busy, why is it > returned for the scenario where the requested channel is being used > for another call? > > -- > _____________________________________________________________________ > -- 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 > -- _____________________________________________________________________ -- 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
