[asterisk-bugs] [Asterisk 0014426]: app_chanisavail always set AVAILSTATUS to 0 with option 's' set
Asterisk Bug Tracker
noreply at bugs.digium.com
Sat Feb 7 12:51:31 CST 2009
A NOTE has been added to this issue.
======================================================================
http://bugs.digium.com/view.php?id=14426
======================================================================
Reported By: macli
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 14426
Category: Applications/app_chanisavail
Reproducibility: always
Severity: tweak
Priority: normal
Status: feedback
Asterisk Version: Addons-1.6.1-rc1
Regression: No
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2009-02-06 13:34 CST
Last Modified: 2009-02-07 12:51 CST
======================================================================
Summary: app_chanisavail always set AVAILSTATUS to 0 with
option 's' set
Description:
Here is dialplan copied from extensions.conf.sample:
[macro-page];
exten => s,1,ChanIsAvail(${ARG1},s) ; j is for Jump
and s is for ANY call
exten => s,n,GoToIf($[ ${AVAILSTATUS} = 1 ]?autoanswer:fail)
exten => s,n(autoanswer),Set(_ALERT_INFO="RA") ; This is
for the PolyComs
exten => s,n,SIPAddHeader(Call-Info: Answer-After=0) ; This is for the
Grandstream, Snoms, and Others
exten => s,n,NoOp() ; Add others here
and Post on the Wiki!!!!
exten => s,n,Dial(${ARG1},,)
exten => s,n(fail),Hangup
;page
exten => 6999,1,Set(TIMEOUT(absolute)=60)
exten => 6999,2,Macro(page,SIP/vli)
First call when SIP/vli not in use
----------------------------------
*CLI> -- Starting simple switch on 'DAHDI/1-1'
-- Executing [6999 at brc-internal:1] Set("DAHDI/1-1",
"TIMEOUT(absolute)=60") in new stack
Channel will hangup at 2009-02-06 11:49:08.454 PST.
-- Executing [6999 at brc-internal:2] Macro("DAHDI/1-1", "page,SIP/vli")
in new stack
-- Executing [s at macro-page:1] ChanIsAvail("DAHDI/1-1", "SIP/vli,s") in
new stack
== Using SIP RTP CoS mark 5
-- Executing [s at macro-page:2] GotoIf("DAHDI/1-1", "0?autoanswer:fail")
in new stack
== branch1: autoanswer branch2: fail branch: fail
-- Goto (macro-page,s,7)
-- Executing [s at macro-page:7] Hangup("DAHDI/1-1", "") in new stack
== Spawn extension (macro-page, s, 7) exited non-zero on 'DAHDI/1-1' in
macro 'page'
== Spawn extension (brc-internal, 6999, 2) exited non-zero on
'DAHDI/1-1'
-- Hungup 'DAHDI/1-1'
Second call when SIP/vli is in use:
----------------------------------
*CLI> [Feb 6 11:49:16] NOTICE[12461]: chan_dahdi.c:7144 ss_thread: Got
event 18 (Ring Begin)...
[Feb 6 11:49:19] NOTICE[12461]: chan_dahdi.c:7144 ss_thread: Got event 2
(Ring/Answered)...
-- Executing [s at brc-incoming:1] Wait("DAHDI/4-1", "1") in new stack
-- Executing [s at brc-incoming:2] Answer("DAHDI/4-1", "") in new stack
-- Executing [s at brc-incoming:3] Playback("DAHDI/4-1",
"brc/brc-office") in new stack
-- <DAHDI/4-1> Playing 'brc/brc-office.gsm' (language 'en')
-- Executing [s at brc-incoming:4] WaitExten("DAHDI/4-1", "5") in new
stack
== CDR updated on DAHDI/4-1
-- Executing [668 at brc-incoming:1] Gosub("DAHDI/4-1",
"stdexten(668,SIP/vli)") in new stack
-- Executing [668 at brc-incoming:50000] NoOp("DAHDI/4-1", "Start
stdexten") in new stack
-- Executing [668 at brc-incoming:50001] Set("DAHDI/4-1",
"LOCAL(ext)=668") in new stack
-- Executing [668 at brc-incoming:50002] Set("DAHDI/4-1",
"LOCAL(dev)=SIP/vli") in new stack
-- Executing [668 at brc-incoming:50003] Set("DAHDI/4-1", "LOCAL(cntx)=")
in new stack
-- Executing [668 at brc-incoming:50004] Set("DAHDI/4-1",
"LOCAL(mbx)="668"""") in new stack
-- Executing [668 at brc-incoming:50005] Dial("DAHDI/4-1",
"SIP/vli,20,Tt") in new stack
== Using SIP RTP CoS mark 5
-- Called vli
-- SIP/vli-083f31d8 is ringing
-- SIP/vli-083f31d8 answered DAHDI/4-1
*CLI> -- Starting simple switch on 'DAHDI/1-1'
-- Executing [6999 at brc-internal:1] Set("DAHDI/1-1",
"TIMEOUT(absolute)=60") in new stack
Channel will hangup at 2009-02-06 11:50:48.558 PST.
-- Executing [6999 at brc-internal:2] Macro("DAHDI/1-1", "page,SIP/vli")
in new stack
-- Executing [s at macro-page:1] ChanIsAvail("DAHDI/1-1", "SIP/vli,s") in
new stack
== Using SIP RTP CoS mark 5
-- Executing [s at macro-page:2] GotoIf("DAHDI/1-1", "0?autoanswer:fail")
in new stack
== branch1: autoanswer branch2: fail branch: fail
-- Goto (macro-page,s,7)
-- Executing [s at macro-page:7] Hangup("DAHDI/1-1", "") in new stack
== Spawn extension (macro-page, s, 7) exited non-zero on 'DAHDI/1-1' in
macro 'page'
== Spawn extension (brc-internal, 6999, 2) exited non-zero on
'DAHDI/1-1'
-- Hungup 'DAHDI/1-1'
======================================================================
----------------------------------------------------------------------
(0099666) putnopvut (administrator) - 2009-02-07 12:51
http://bugs.digium.com/view.php?id=14426#c99666
----------------------------------------------------------------------
macli, that patch is not a good idea.
The problem appears to be that AVAILSTATUS is being used for two distinct
purposes here. In the case where inuse <= 1, the status gets overriden in
the ast_request call with a Q.931 cause code describing the reason the
channel could or could not be requested. In the case where inuse > 1, the
status corresponds to the device state of the channel.
Unfortunately, it's very hard to judge the intent of the ChanIsAvail
application just from reading the code and its CLI documentation. As a
result of potential ambiguities, I have several ideas for patches that
would fix this problem.
As a workaround for now, you can use the AVAILORIGCHAN variable as a means
of determining if the channel is available. In macro-page, change the
second line to be
exten => s,n,GoToIf(${EXISTS(${AVAILORIGCHAN})}?autoanswer:fail)
Issue History
Date Modified Username Field Change
======================================================================
2009-02-07 12:51 putnopvut Note Added: 0099666
======================================================================
More information about the asterisk-bugs
mailing list