[asterisk-bugs] [Asterisk 0016626]: Chanspy application does not exit when user hangs up
Asterisk Bug Tracker
noreply at bugs.digium.com
Thu Jul 29 09:30:52 CDT 2010
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=16626
======================================================================
Reported By: kobaz
Assigned To: jpeeler
======================================================================
Project: Asterisk
Issue ID: 16626
Category: Applications/app_chanspy
Reproducibility: always
Severity: minor
Priority: normal
Status: acknowledged
Target Version: 1.6.2.12
Asterisk Version: SVN
JIRA: SWP-742
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): 1.6.0
SVN Revision (number only!): 240716
Request Review:
======================================================================
Date Submitted: 2010-01-17 13:06 CST
Last Modified: 2010-07-29 09:30 CDT
======================================================================
Summary: Chanspy application does not exit when user hangs up
Description:
1.6.0 svn tr
IAX device dials 267 at services, ChanSpy executes... IAX device hangs up...
chanspy is still running
extend context services {
267 => {
Answer();
ChanList(SIP/213);
Set(encchannel=${BASE64_ENCODE(${CHANLIST_RESULT})});
goto connectToChannel, ${encchannel}, 1;
}
}
context connectToChannel {
h => {
Hangup();
}
_.! => {
Set(spy=${BASE64_DECODE(${EXTEN})});
Answer();
ChanSpy(${spy},qw);
}
}
-- Executing [267 at trunkhandler_from-branch:1]
Answer("IAX2/branch-9556", "") in new stack
-- Executing [267 at trunkhandler_from-branch:2]
ChanList("IAX2/branch-9556", "SIP/213") in new stack
-- Executing [267 at trunkhandler_from-branch:3] Set("IAX2/branch-9556",
"encchannel=U0lQLzIxMy0wMDAwMDAwMA==") in new stack
-- Executing [267 at trunkhandler_from-branch:4] Goto("IAX2/branch-9556",
"connectToChannel,U0lQLzIxMy0wMDAwMDAwMA==,1") in new stack
-- Goto (connectToChannel,U0lQLzIxMy0wMDAwMDAwMA==,1)
-- Executing [U0lQLzIxMy0wMDAwMDAwMA==@connectToChannel:1]
Set("IAX2/branch-9556", "spy=SIP/213-00000000") in new stack
-- Executing [U0lQLzIxMy0wMDAwMDAwMA==@connectToChannel:2]
Answer("IAX2/branch-9556", "") in new stack
-- Executing [U0lQLzIxMy0wMDAwMDAwMA==@connectToChannel:3]
ChanSpy("IAX2/branch-9556", "SIP/213-00000000,qw") in new stack
== Spying on channel SIP/213-00000000
[Jan 17 13:54:44] NOTICE[8329]: app_chanspy.c:245 start_spying: Attaching
IAX2/branch-9556 to SIP/213-00000000
[Jan 17 13:54:44] NOTICE[8329]: app_chanspy.c:245 start_spying: Attaching
IAX2/branch-9556 to SIP/213-00000000
--- IAX2/branch-9556 hangs up here ---
> core show channels
Channel Location State Application(Data)
IAX2/branch-9556 U0lQLzIxMy0wMDAwMDAw Up
ChanSpy(SIP/213-00000000,qw)
SIP/213-00000000 s at dialExten:1 Up AppDial((Outgoing
Line))
IAX2/branch-3772 s at dialExten:5 Up Dial(SIP/213)
I'm not good enough with the code yet to see why it's happening... but I
see where it's happening.
Line 416 of app_chanspy.c
414: if (ast_test_flag(flags, OPTION_WHISPER)) {
415: ast_audiohook_lock(&csth.whisper_audiohook);
416: ast_audiohook_detach(&csth.whisper_audiohook); //
lockup
417: ast_audiohook_unlock(&csth.whisper_audiohook);
418: ast_audiohook_destroy(&csth.whisper_audiohook);
419: }
If the spyee channel hangs up, ast_audiohook_detach() will finish, and
ChanSpy will end.
This only happens when there is no audio being generated.
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
related to 0016524 Chanspy cannot spy on a non-bridged cha...
======================================================================
----------------------------------------------------------------------
(0125254) kobaz (reporter) - 2010-07-29 09:30
https://issues.asterisk.org/view.php?id=16626#c125254
----------------------------------------------------------------------
Two tests
'_267' => 1. Answer()
[pbx_ael]
2. ChanSpy(SIP/2618)
[pbx_ael]
'_267' => 1. Answer()
[pbx_ael]
2. ChanSpy(SIP/2618,b)
[pbx_ael]
202 spys on 2618... same result when using b or no b.
This seems more like a feature request than a bug. ChanSpy() seems to
loop around indefinitely waiting for callers on the specified device.
Maybe there needs to be a new option 'h' or similar, that would end chanspy
if there is nothing to spy on.
-- Executing [267 at trunkhandler_from-branch:2]
ChanSpy("SIP/202-00000003", "SIP/2618,b") in new stack
-- <SIP/202-00000003> Playing 'beep.ulaw' (language 'en')
-- <SIP/202-00000003> Playing 'spy-sip.ulaw' (language 'en')
-- <SIP/202-00000003> Playing 'digits/2.ulaw' (language 'en')
-- <SIP/202-00000003> Playing 'digits/6.ulaw' (language 'en')
-- <SIP/202-00000003> Playing 'digits/1.ulaw' (language 'en')
-- <SIP/202-00000003> Playing 'digits/8.ulaw' (language 'en')
== Spying on channel SIP/2618-00000002
[Jul 29 10:24:44] NOTICE[19889]: app_chanspy.c:245 start_spying: Attaching
SIP/202-00000003 to SIP/2618-00000002
-- Executing [h at dialOut:1] Set("SIP/2618-00000002",
"ARGS="module=CallRouter,action=DialHangup"") in new stack
-- Executing [h at dialOut:2] AGI("SIP/2618-00000002",
"agi://127.0.0.1:2000") in new stack
-- <SIP/2618-00000002>AGI Script agi://127.0.0.1:2000 completed,
returning 0
-- Hungup 'IAX2/tipton-local-11035'
-- AGI Script Executing Application: (Hangup) Options: ()
-- <SIP/2618-00000002>AGI Script agi://127.0.0.1:2000 completed,
returning 0
-- Executing [s at dialOut:8] Return("SIP/2618-00000002", "") in new
stack
-- Auto fallthrough, channel 'SIP/2618-00000002' status is 'ANSWER'
== Done Spying on channel SIP/2618-00000002
-- <SIP/202-00000003> Playing 'beep.ulaw' (language 'en')
core show channels
Channel Location State Application(Data)
SIP/202-00000003 267 at trunkhandler_fro Up ChanSpy(SIP/2618,b)
1 active channel1*CLI>
Issue History
Date Modified Username Field Change
======================================================================
2010-07-29 09:30 kobaz Note Added: 0125254
======================================================================
More information about the asterisk-bugs
mailing list