Summary:ASTERISK-23381: [patch]ChanSpy- Barge only works on the initial 'spy', if the spied-on channel makes a new call, unable to barge.
Reporter:Cy Sly (themrrobert)Labels:
Date Opened:2014-02-26 17:53:36.000-0600Date Closed:2014-05-12 17:04:28
Versions:11.6.0 11.7.0 Frequency of
Environment:CentOS 6.5, asterisk 11.7.0Attachments:( 0) app_chanspy.c.diff
( 1) description.txt
( 2) my.app_chanspy.c.c_unified.diff
( 3) my.app_chanspy.c.c.diff
Description:When barging, our monitors can use either a prefix, or the full extension to monitor a channel. Once the agent hangs up, they are still monitoring.

When a new call is connected to the monitor, listen+whisper still work, however barging does not. Only the spied-on agent can hear the monitor.

This happens both when monitoring a single channel, and when monitoring a group of channels, as soon as the initially monitored call closes, they are unable to barge on subsequent monitors. The workaround is to hangup and redial that monitor extension and then barge, which works fine so long as it's the first call being barged.

*NOTE: I have updated the issue with the details below, I now believe the above is misleading, and you should only pay attention to description below.*

I added some debugging code to app_chanspy to help me get a better idea of what's going on. See attachment for complete description, sample calls, and dialplan

Here is what I did:
* I called out from 999015 to my cell 7145551234
* After I answered, I dialed *225 999015 from 9987 to spy via chanspy(SIP/999015,d)
* At this point, it attaches both the whisper and barge channels immediately, even though it starts on listen mode. [@ 2014-03-05 13:53:09]
* I then pressed 6 to barge, and got no message in the log, and heard my voice on all channels as expected.
* I then hung up 999015, killing the call, but left the chanspy open on 9987
* I dialed my cell again from 999015, as soon as it started ringing, I heard chanspy connect to the call [@ 2014-03-05 13:53:09]
* Notice that it attaches the whisper channel immediately, and since the bridged party hasn't answered, it looks like that's why it's not able to barge, even after the line is picked up.
* Trying to barge at this point, only the agent 999015 can hear the spyer. Even though now everyone is on the call.
* While the call between 999015 -> 7145551234 was still active, I pressed * on 9987, to rotate the call [@ 2014-03-05 13:55:04]
* At this point, it reconnects me to the same place and since both channels are up at the time the spy function is started, it locks on to each of them, and now when i press 6 to barge it works on both channels.

Dialplan + Sample Call attached. Also attached is a patch i wrote that fixes the problem.
Comments:By: Rusty Newton (rnewton) 2014-02-27 16:36:02.246-0600

Thank you for taking the time to report this bug and helping to make Asterisk better. Unfortunately, we cannot work on this bug because your description did not include enough information. You may find it helpful to read the Asterisk Issue Guidelines http://www.asterisk.org/developers/bug-guidelines. We would be grateful if you would then provide a more complete description of the problem. At a minimum, we need:

1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).

This likely includes output from the console with debug level logging, a SIP trace (if this is SIP related), and configuration information such as dialplan (e.g. extensions.conf) and channel configuration (e.g. sip.conf). Thanks!

Specifically please include dialplan with instructions on how to use it to reproduce the issue easily. Also an annotated log from an instance of reproduction would be very helpful.


By: Cy Sly (themrrobert) 2014-03-05 16:51:34.437-0600

Description along with sample call and dialplan

Waiting to submit a patch, agreement needs to be reviewed by the sites legal team :S

By: Cy Sly (themrrobert) 2014-03-05 16:59:32.270-0600

Patch that fixes this issue by rehooking the bridged channel if the spied on channel was spied on before a bridged peer answered the call, which previously prevented barging from reaching the spied-on-bridged peer

By: Cy Sly (themrrobert) 2014-03-05 17:35:03.114-0600

The comment on line 647 is a bit off, that was from a different idea i was pursuing.

Also, i believe there should also be a
bridge_connected = 1;
assignment between lines 645-646, so that it's not trying each time on error. Unless this would be desired to patch in a channel first thought unavailable, I'm not yet that familiar with all of the code.

My patch is attached, however it's not yet visible in the attachments section. I can see it on history :)

By: Rusty Newton (rnewton) 2014-03-11 16:55:14.766-0500

Attaching Robert's patch in unified diff format so it'll be easier for those used to that.

By: Rusty Newton (rnewton) 2014-03-11 16:59:55.444-0500

Robert, you can go ahead and post your patch, in unified diff format, on Reviewboard if you would like.

[Instructions on Code Review|https://wiki.asterisk.org/wiki/display/AST/Code+Review]

It is a good idea, if you haven't before, to go over the [Code Review Checklist|https://wiki.asterisk.org/wiki/display/AST/Code+Review+Checklist] before submitting to reviewboard.

Once again, thanks!

By: Cy Sly (themrrobert) 2014-03-11 17:19:45.592-0500

Here is a cleaned up version in unified diff format

By: Jonathan Rose (jrose) 2014-04-29 17:10:50.922-0500

I've posted a cleaned up version of this patch on reviewboard under the review https://reviewboard.asterisk.org/r/3505/ since the previous review (https://reviewboard.asterisk.org/r/3331/) had stalled.

By: Matt Jordan (mjordan) 2014-05-11 18:38:24.535-0500

The patch as committed in r413557 broke the chanspy tests on trunk:


By: Jonathan Rose (jrose) 2014-05-12 17:04:29.927-0500

Reported by: Robert Moss

By: Jonathan Rose (jrose) 2014-05-12 17:26:28.797-0500

Reported by: Robert Moss

By: Jonathan Rose (jrose) 2014-05-12 17:35:29.225-0500

Reported by: Robert Moss