[asterisk-users] Unexpected behavior change from Asterisk 1.6.2.14 to Asterisk 1.8.5.0
Vladimir Mikhelson
vlad at mikhelson.com
Mon Sep 12 19:43:30 CDT 2011
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 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.
>>>
>> 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
>
More information about the asterisk-users
mailing list