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

[Robert Moss (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-23381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=216150#comment-216150 ] 

Robert Moss edited comment on ASTERISK-23381 at 3/5/14 4:55 PM:
----------------------------------------------------------------

Description along with sample call and dialplan

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


was (Author: themrrobert):
Description along with sample call and dialplan

> 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: description.txt
>
>
> <strong>I have a completed patch, however I'm waiting for the legal team of this site to accept my agreement before I can publish it.</strong>
> 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.
> 7145551234 = My cell phone
> 111.222.111.222 = IP Address of SIP Client
> 9987 = my extension on PBXSales
> 999015 = agent extension being spied on
> *225XXXXXX = command which initializes chanspy
> 208.0.0.254 = random IP from the carrier processing the call
> 207.0.0.132 = same as above for the 1st call
> 123.45.67.89 = IP Address of PBXSales
> I added some debugging code to app_chanspy to help me get a better idea of what's going on.
> 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.
> 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 and since both channels are up, 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)