[asterisk-bugs] [Asterisk 0018675]: ChannelRedirect hanging up a channel who is in a ChanSpy
Asterisk Bug Tracker
noreply at bugs.digium.com
Mon Jan 31 18:44:21 CST 2011
A NOTE has been added to this issue.
======================================================================
https://issues.asterisk.org/view.php?id=18675
======================================================================
Reported By: Thera
Assigned To:
======================================================================
Project: Asterisk
Issue ID: 18675
Category: Applications/app_channelredirect
Reproducibility: always
Severity: minor
Priority: normal
Status: feedback
Asterisk Version: SVN
JIRA: SWP-3011
Regression: No
Reviewboard Link:
SVN Branch (only for SVN checkouts, not tarball releases): N/A
SVN Revision (number only!):
Request Review:
======================================================================
Date Submitted: 2011-01-25 10:34 CST
Last Modified: 2011-01-31 18:44 CST
======================================================================
Summary: ChannelRedirect hanging up a channel who is in a
ChanSpy
Description:
User B is bridge with User A.
User C start ChanSpy on the A channel.
Let's doing a redirection of the Channel C with manager command (Action:
Redirect), CLI command (channel redirect) or Application (ChannelRedirect).
=> The channel stop to spying but, just before go in the
context,extension,priority specified, the call end.
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
duplicate of 0018585 [patch] AMI redirect from meetme - call...
======================================================================
----------------------------------------------------------------------
(0131322) paulc (reporter) - 2011-01-31 18:44
https://issues.asterisk.org/view.php?id=18675#c131322
----------------------------------------------------------------------
I'm not sure if this is a duplicate of 0018585 but I'm experiencing the
same symptoms as described by Thera.
I have a context with s extension to do monitoring (the target being in a
channel variable) and an h extension (so I know when the person doing the
monitoring hangs up).
A1 is talking to A2, B1 is talking to B2. I originate a call to C, who
sits listening to music on hold. Via AGI I set a channel var for C then
redirect to a context where he starts monitoring A1. This works fine. I
then set the channel var to B1 and redirect C as I did previously. C
triggers the h extension and the call ends.
This is in 1.6.2.16, but works fine in 1.6.2.9 - in the earlier version, C
stops monitoring A1 and starts monitoring B1 with no issues.
Here's what I see on the console, for both versions:
//
// We make an outbound call (to C) using a call file
//
-- Attempting call on SIP/+9998883293 at 192.168.65.251 for
s at ono-monitor-start:1 (Retry 1)
== Using SIP RTP CoS mark 5
> Channel SIP/192.168.65.251-0000011f was answered.
-- Executing [s at ono-monitor-start:1]
NoOp("SIP/192.168.65.251-0000011f", "Starting call for agent monitoring")
in new stack
-- Executing [s at ono-monitor-start:2]
Set("SIP/192.168.65.251-0000011f", "ONO_AUDIO_PREFIX=o3") in new stack
-- Executing [s at ono-monitor-start:3]
Set("SIP/192.168.65.251-0000011f", "ONO_AUDIO=o3/eng-str") in new stack
-- Executing [s at ono-monitor-start:4]
Set("SIP/192.168.65.251-0000011f",
"ONO_WEB=http://agents-ws.xipservices.com/ws") in new stack
-- Executing [s at ono-monitor-start:5]
Set("SIP/192.168.65.251-0000011f", "Result=1") in new stack
-- Executing [s at ono-monitor-start:6]
Wait("SIP/192.168.65.251-0000011f", "1") in new stack
-- Executing [s at ono-monitor-start:7]
Playback("SIP/192.168.65.251-0000011f", "o3/eng-str/agent-monitor-start")
in new stack
-- <SIP/192.168.65.251-0000011f> Playing
'o3/eng-str/agent-monitor-start.ulaw' (language 'en')
-- Executing [s at ono-monitor-start:8]
WaitMusicOnHold("SIP/192.168.65.251-0000011f", "60") in new stack
-- Started music on hold, class 'default', on
SIP/192.168.65.251-0000011f
//
// At this point the call has been answered, C is listening to music, and
// will get redirected when he clicks in the web control front end
//
// He clicks, and gets sent to ono-monitor-agent,s,1
//
== Manager 'o3' logged on from 127.0.0.1
-- Stopped music on hold on SIP/192.168.65.251-0000011f
== Spawn extension (ono-monitor-agent, s, 1) exited non-zero on
'SIP/192.168.65.251-0000011f'
-- Executing [s at ono-monitor-agent:1]
ChanSpy("SIP/192.168.65.251-0000011f", "SIP/192.168.65.251-0000011d,q") in
new stack
== Manager 'o3' logged off from 127.0.0.1
== Spying on channel SIP/192.168.65.251-0000011d
[Jan 31 16:27:43] NOTICE[8415]: app_chanspy.c:414 start_spying: Attaching
SIP/192.168.65.251-0000011f to SIP/192.168.65.251-0000011d
[Jan 31 16:27:43] NOTICE[8415]: app_chanspy.c:414 start_spying: Attaching
SIP/192.168.65.251-0000011f to SIP/192.168.65.251-0000011d
[Jan 31 16:27:43] NOTICE[8415]: app_chanspy.c:414 start_spying: Attaching
SIP/192.168.65.251-0000011f to SIP/192.168.184.201-0000011b
//
// At this point, C is now monitoring A1's conversation
//
// He uses the web control front end to request monitoring of B1
//
== Manager 'o3' logged on from 127.0.0.1
== Manager 'o3' logged off from 127.0.0.1
== Done Spying on channel SIP/192.168.65.251-0000011d
== Spawn extension (ono-monitor-agent, s, 1) exited non-zero on
'SIP/192.168.65.251-0000011f'
-- Executing [s at ono-monitor-agent:1]
ChanSpy("SIP/192.168.65.251-0000011f", "SIP/192.168.65.251-0000011e,q") in
new stack
== Spawn extension (ono-monitor-agent, s, 1) exited non-zero on
'SIP/192.168.65.251-0000011f'
-- Executing [h at ono-monitor-agent:1]
NoOp("SIP/192.168.65.251-0000011f", "********** ONO-MONITOR-AGENT - Hangup
Detected") in new stack
-- Executing [h at ono-monitor-agent:2]
Set("SIP/192.168.65.251-0000011f", "Result=1") in new stack
-- Executing [h at ono-monitor-agent:3]
Hangup("SIP/192.168.65.251-0000011f", "") in new stack
== Spawn extension (ono-monitor-agent, h, 3) exited non-zero on
'SIP/192.168.65.251-0000011f'
[Jan 31 16:27:56] NOTICE[8415]: pbx_spool.c:349 attempt_thread: Call
completed to SIP/+9998883293 at 192.168.65.251
//
// It seems that in stopping monitoring, C is deemed to have hungup. The
// h extension triggered and the call ends.
//
//
// For comparison, on my 1.6.2.9 system, the first redirect looks like
this:
//
== Manager 'o3' logged on from 127.0.0.1
-- Stopped music on hold on SIP/101-00000010
== Spawn extension (ono-monitor-agent, s, 1) exited non-zero on
'SIP/101-00000010'
-- Executing [s at ono-monitor-agent:1] ChanSpy("SIP/101-00000010",
"Local/s at robot-agent-3ae4;1,q") in new stack
== Manager 'o3' logged off from 127.0.0.1
== Spying on channel Local/s at robot-agent-3ae4;1
[Jan 31 16:42:18] NOTICE[22831]: app_chanspy.c:414 start_spying: Attaching
SIP/101-00000010 to Local/s at robot-agent-3ae4;1
[Jan 31 16:42:18] NOTICE[22831]: app_chanspy.c:414 start_spying: Attaching
SIP/101-00000010 to Local/s at robot-agent-3ae4;1
[Jan 31 16:42:18] NOTICE[22831]: app_chanspy.c:414 start_spying: Attaching
SIP/101-00000010 to Local/6664 at in-sip-76d3;2
//
// And the second redirect looks like this:
//
== Manager 'o3' logged on from 127.0.0.1
== Done Spying on channel Local/s at robot-agent-3ae4;1
== Spawn extension (ono-monitor-agent, s, 1) exited non-zero on
'SIP/101-00000010'
-- Executing [s at ono-monitor-agent:1] ChanSpy("SIP/101-00000010",
"Local/s at robot-agent-020a;1,q") in new stack
== Manager 'o3' logged off from 127.0.0.1
== Spying on channel Local/s at robot-agent-020a;1
[Jan 31 16:42:21] NOTICE[22831]: app_chanspy.c:414 start_spying: Attaching
SIP/101-00000010 to Local/s at robot-agent-020a;1
[Jan 31 16:42:21] NOTICE[22831]: app_chanspy.c:414 start_spying: Attaching
SIP/101-00000010 to Local/s at robot-agent-020a;1
[Jan 31 16:42:21] NOTICE[22831]: app_chanspy.c:414 start_spying: Attaching
SIP/101-00000010 to Local/6664 at in-sip-ee4c;2
Issue History
Date Modified Username Field Change
======================================================================
2011-01-31 18:44 paulc Note Added: 0131322
======================================================================
More information about the asterisk-bugs
mailing list