[asterisk-bugs] [JIRA] (ASTERISK-23381) [patch]ChanSpy- Barge only works on the initial 'spy', if the spied-on channel makes a new call, unable to barge.

[Jonathan Rose (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-23381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Rose updated ASTERISK-23381:
-------------------------------------

    Reviewboard Link: https://reviewboard.asterisk.org/r/3505/  (was: https://reviewboard.asterisk.org/r/3331/)

> [patch]ChanSpy- Barge only works on the initial 'spy', if the spied-on channel makes a new call, unable to barge.
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-23381
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-23381
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_chanspy
>    Affects Versions: 11.6.0, 11.7.0
>         Environment: CentOS 6.5, asterisk 11.7.0
>            Reporter: Robert Moss
>            Assignee: Robert Moss
>            Severity: Minor
>         Attachments: app_chanspy.c.diff, description.txt, my.app_chanspy.c.c.diff, my.app_chanspy.c.c_unified.diff
>
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.2#6252)