[Home]

Summary:ASTERISK-16346: [patch] Chanspy hangs up the targetted phone call.
Reporter:thomas_foerster (thomas_foerster)Labels:
Date Opened:2011-01-19 16:22:22.000-0600Date Closed:2013-09-16 09:03:50
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_chanspy
Versions:1.8.4 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) GSD-ChanSpy-Hangup-fix-backport-16-r303548.patch
Description:What is Expected :

1)Phone A is on a call.
2)Phone B dials a "Chanspy" extension in order to listen to phone A conversation.
3)Phone B hears phone A conversation


What is Happening :

1)Phone A is on a call.
2)Phone B dials a "Chanspy" extension in order to listen to phone A conversation.
3)Phone A call is immediatly hung up by Asterisk.
4)Phone B call is still alive , but there is no audio.



****** ADDITIONAL INFORMATION ******

If we "Chanspy" to a sip phone before the targeted phone makes a call, then the next call can successfully be spied. The bug only happens if we try to "chanspy" a phone that is already on a call.

Asterisk SVN-branch-1.6.2-r299242M
Comments:By: thomas_foerster (thomas_foerster) 2011-01-19 16:34:46.000-0600

Log File :


[Jan 19 17:05:11] VERBOSE[16112] pbx.c: [Jan 19 17:05:11]     -- Executing [5145273726@tdmout-noerr:1] Dial("SIP/u010112-0000374b", "SIP/15145273726@sbc1") in new stack
[Jan 19 17:05:13] VERBOSE[16112] app_dial.c: [Jan 19 17:05:13]     -- SIP/sbc1-0000374c answered SIP/u010112-0000374b
[Jan 19 17:05:13] VERBOSE[16112] rtp.c: [Jan 19 17:05:13]     -- Packet2Packet bridging SIP/u010112-0000374b and SIP/sbc1-0000374c
[Jan 19 17:05:31] VERBOSE[16128] pbx.c: [Jan 19 17:05:31]     -- Executing [*32112@ubity:1] ChanSpy("SIP/u010102f-0000374f", "SIP/u010112,q") in new stack
[Jan 19 17:05:32] VERBOSE[16128] app_chanspy.c: [Jan 19 17:05:32]   == Spying on channel SIP/u010112-0000374b
[Jan 19 17:05:32] NOTICE[16128] app_chanspy.c: Attaching SIP/u010102f-0000374f to SIP/u010112-0000374b
[Jan 19 17:05:32] NOTICE[16128] app_chanspy.c: Attaching SIP/u010102f-0000374f to SIP/u010112-0000374b
[Jan 19 17:05:32] NOTICE[16128] app_chanspy.c: Attaching SIP/u010102f-0000374f to SIP/sbc1-0000374c
[Jan 19 17:05:32] VERBOSE[16112] pbx.c: [Jan 19 17:05:32]   == Spawn extension (tdmout-noerr, 5145273726, 1) exited non-zero on 'SIP/u010112-0000374b'
[Jan 19 17:05:32] VERBOSE[16128] app_chanspy.c: [Jan 19 17:05:32]   == Done Spying on channel SIP/u010112-0000374b
[Jan 19 17:05:49] VERBOSE[16128] pbx.c: [Jan 19 17:05:49]   == Spawn extension (ubity, *32112, 1) exited non-zero on 'SIP/u010102f-0000374f'
By: thomas_foerster (thomas_foerster) 2011-01-19 16:36:06.000-0600

Dialplan :

exten => *32112,1,Chanspy(SIP/u010112,q)
By: mlegas (mlegas) 2011-01-25 10:41:48.000-0600

I can confirm the same issue in the latest 1.4.39.1
it happens when doing Packet2Packet bridging
when doing normal bridging within the core, it does not happen
By: Bing Li(enst) (enst) 2011-01-25 13:04:23.000-0600

And the same issue in 1.8.2.2.
Packet2Packet bridging
Even I  make the "chanspy" call first,  the next call also can not be spied.
By: Russell Bryant (russell) 2011-02-08 14:06:00.000-0600

Can you please try the latest 1.6.2 code?  I think this may have been fixed by a change I put in recently for some softhangup handling.
By: Sébastien Couture (sysreq) 2011-02-09 12:17:51.000-0600

russell: Upgrading to the latest 1.6.2 revision (307105) did fix the issue. Thank you!
By: Steven Wheeler (swheeler) 2011-02-17 10:25:45.000-0600

I can confirm that this is also happening on 1.8.2.3

(edit)
However, it works as expected on v1.8.1.1


By: ornix (ornix) 2011-02-18 14:12:10.000-0600

1.8.3rc3, same issue.
By: Walter Doekes (wdoekes) 2011-02-21 05:22:48.000-0600

Confirmed on 1.4.39.1. Also confirmed that changeset 303546 fixes it.


   -- Executing [203@pi_special_spy:4] ChanSpy("SIP/nosyparker-00000005", "SIP/victim-") in new stack
...
[2011-02-21 11:43:11] DEBUG[19409]: chan_sip.c:4013 sip_answer: SIP answering channel: SIP/nosyparker-00000005
...
 == Spying on channel SIP/victim-00000003
[2011-02-21 11:43:17] NOTICE[19409]: app_chanspy.c:218 start_spying: Attaching SIP/victim-00000005 to SIP/nosyparker-00000003
[2011-02-21 11:43:17] DEBUG[19409]: channel.c:1578 ast_softhangup_nolock: Soft-Hanging up channel 'SIP/trunk-00000004'
[2011-02-21 11:43:17] DEBUG[19408]: rtp.c:3370 bridge_p2p_loop: Oooh, something is weird, backing out
[2011-02-21 11:43:17] DEBUG[19408]: channel.c:4855 ast_channel_bridge: Unbridge signal received. Ending native bridge.
[2011-02-21 11:43:17] DEBUG[19409]: audiohook.c:224 audiohook_read_frame_both: Read factory 0x41e0d8a0 and write factory 0x41e0e2d0 both fail to provide 160 samples

[2011-02-21 11:43:17] DEBUG[19408]: channel.c:4616 ast_generic_bridge: Didn't get a frame from channel: SIP/trunk-00000004


After applying r303546, that last line debug line disappears and the channels stay open like expected. Note that I did not test for any (other) side-effects of the patch.
By: Ronald Chan (loloski) 2011-02-21 06:57:16.000-0600

do we have a fix for SVN 1.6 branch ?
By: Walter Doekes (wdoekes) 2011-02-21 07:11:13.000-0600

~/src/asterisk-1.6.2.x$ svn log -r 303546:HEAD | grep 303546 -C4
------------------------------------------------------------------------
r303548 | russell | 2011-01-24 21:49:53 +0100 (Mon, 24 Jan 2011) | 38 lines

Merged revisions 303546 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
...

It should be fixed by r303548 in 1.6.2.x
By: Ronald Chan (loloski) 2011-02-21 08:07:39.000-0600

walter,

Thanks for your info, if this has been deemed fixed, case close :D
By: Patrick Plattes (mrparity) 2011-03-03 03:15:19.000-0600

I can confirm this issue on 1.8.3-rc3. Should I open an other Issue for the 1.8 branch?


By: Gabriel Ortiz Lour (elbriga) 2011-03-15 12:38:24

I've just uploaded a patch that fixes the issue on the 1.6.2.15 version.
I backported the changes from r303547 to r303548
By: Walter Doekes (wdoekes) 2011-03-21 09:58:19

Does this patch work properly for anyone on 1.6.2.x? I'm seeing really weird behaviour with 1.6.2.17.2 here.

(1) As soon as I start spying, an outgoing call from a spied-upon doesn't go through. It stops before actually dialing out.
(2) When I start spying when the call is already up, I can hear the audio on the spying channel, but the spied-upon channel has no audio. (Even if the channel is not in the e(enforced) list.)

Yes.. this is a bit vague. I'll have to some more research to pinpoint exactly when it goes bad.

Anyone else seeing anything similar? Or does it work like it should except for my exotic configuration?
By: firstsip (firstsip) 2011-04-04 03:16:18

Could your point (2) be the same at this issue: https://issues.asterisk.org/view.php?id=19054 which itself is a dup of another issue https://issues.asterisk.org/view.php?id=18382 that is still pending a solution.
By: Walter Doekes (wdoekes) 2011-04-04 04:08:33

Well.. I'm not using whisper mode and ASTERISK-17029 seems to mention that that is required for the bug to manifest itself. But yes, it could be.
By: maatohewetbi (maatohewetbi) 2011-04-12 05:46:04

Hello, I am new here, so don't be angry if I write something wrong. I confirm every version I download (1.8.1.1,1.4.40,1.6.2.17.2) causes hanging up while I want to spy a user...But I have version downloaded from Digium. Is there any difference? How to solve this problem?
By: maatohewetbi (maatohewetbi) 2011-04-12 06:12:10

Fixed! I downloaded svn version 1.6.2.-r313278 and it's ok.
By: maatohewetbi (maatohewetbi) 2011-04-12 11:09:04

There is still another problem...When there is a call between my user and other person, and I want to spy my user. During it I want to spy, and before end of conversation I want to hangup spying but I can't. I have to wait until call between my user and other person is ended...What's wrong with it?
By: Gabriel Ortiz Lour (elbriga) 2011-04-20 08:42:26

Debug log from 1.4.40:

[2011-04-20 10:18:09] NOTICE[1700]: app_chanspy.c:225 start_spying: Attaching SIP/1204-0000001f to SIP/teste03-0000001e
[2011-04-20 10:18:09] DEBUG[1700]: channel.c:1578 ast_softhangup_nolock: Soft-Hanging up channel 'SIP/pabx_gism-0000001d'
[2011-04-20 10:18:09] NOTICE[1700]: app_chanspy.c:225 start_spying: Attaching SIP/1204-0000001f to SIP/teste03-0000001e
[2011-04-20 10:18:09] DEBUG[1700]: channel.c:1578 ast_softhangup_nolock: Soft-Hanging up channel 'SIP/pabx_gism-0000001d'
[2011-04-20 10:18:09] NOTICE[1700]: app_chanspy.c:225 start_spying: Attaching SIP/1204-0000001f to SIP/pabx_gism-0000001d
[2011-04-20 10:18:09] DEBUG[1700]: channel.c:1578 ast_softhangup_nolock: Soft-Hanging up channel 'SIP/teste03-0000001e'
[2011-04-20 10:18:09] DEBUG[1696]: rtp.c:3084 bridge_native_loop: Oooh, something is weird, backing out


Is it normal that the line "Attaching to" is duplicated (The same orig attached to the same dest)?
By: Walter Doekes (wdoekes) 2011-05-23 07:52:48

@firstsip et al.: my particular problem with hanging calls was due to ASTERISK-17907

All my chanspy problems are solved.
By: Matt Jordan (mjordan) 2013-09-16 09:03:50.392-0500

I'm going off of Walter's comment that this is actually a duplicate of ASTERISK-17907 and was fixed by it.

If anyone is still having this problem in recent versions of Asterisk 1.8, please let a bug marshal know in #asterisk-bugs and we'll be happy to reopen it.