Repeating ChanSpy script problem


(Dave Burgess) #1

I’m using the continuous ChanSpy script that Lorne has on his GitHub page. I’m using it “as written” except for two things:

  1. Instead of searching for a SIP/PJSIP extension, I’m searching for an SCCP extension
  2. I commented out the “hang up” line so that the script will repeat.

Here’s the snippet at the end with the changes:

; using a regex of SIP/${EXTEN}- will match both SIP and PJSIP channels, and the trailing - character should
; help to ensure there is only a single match. If multiple channels are returned the chanspy application will fail
exten => _.,n,set(spy_target=${CHANNELS(SCCP/${DEV}-)})
exten => _.,n,ExecIf($["${spy_target}"!=""]?ExitWhile) ; if an active channel is found exit the loop
exten => _.,n,EndWhile()
exten => _.,n,ExecIF($["${spy_target}"!=""]?ChanSpy(${spy_target},dnq)) ; q option suppresses channel announce on barge

;exten => _.,n,Hangup() ;comment this line with a semicolon to do infinite loop
exten => _.,n,GoTo(once-upon-a-time)
exten => _.,n,Hangup()

The customer tells me that the script is once and done. It works, and will sit in a loop waiting for a second call, but the second call apparently never gets picked up. Can anyone see what might be dragging me down?


(Lorne Gaetz) #2

Can you pastebin a trace?


(Dave Burgess) #3

Yeah, I can’t get on that host from here, so it will have to wait till I get back to my control station.


(Dave Burgess) #4

https://pastebin.freepbx.org/view/fd0cd6ae

The trace shows the script hanging up the chanspy at the end of the first call, but it doesn’t hang up the monitoring phone, so it just sits there in dead air while the extension we should be spying on goes on to the next call (this trace shows that). I’m stumped.


(Lorne Gaetz) #5

Apart from confirming what is being reported, I don’t see an issue with the trace. The ChanSpy line runs, but it never proceeds to the GoTo line and so doesn’t loop. /shrug


(Dave Burgess) #6

I’ll look at it some more. It’s a cool feature that should probably be pulled up to replace the default 555 code, but I need to figure out why it isn’t looping. Thanks for the look.


#7

Perhaps preaching to the choir here but

;exten => _.,n,Hangup() ;comment this line with a semicolon to do infinite loop
exten => _.,n,GoTo(once-upon-a-time)
exten => _.,n,Hangup()

has the first hangup commented but We don’t see what the ‘once-upon-a-time’ does priority nor does your pastebin show it’s arrival


(Lorne Gaetz) #8

Maybe this will reveal what’s going on:

dialplan show targeted-chanspy

(Dave Burgess) #9

It looks pretty much how you’d expect. The “h” and “s” steps hang up. The rest follows the script. I’ll patch the actual output when I get back to my console (I’m at the customer’s site now).

I ran it a little while ago and something about the exit from the Chan-spy app looks strange, just like it did in the first dump. When Chanspy finishes, it just says “Done spying on SCCP/108”. The rest of the script just stops like it won’t return to the context. Odd.

Ah ha moment - this is running on a Freepbx 13 system. That shouldn’t make any difference, unless there’s something in the 13 version that’s been “fixed”.


(Dave Burgess) #10

I worked on the script some more last night.

The problem appears to be in the exit from ChanSpy. In my system, when the monitored call ends, the log show that ChanSpy is done, but on the monitoring extension, the phone sits as if it was still monitoring the other extension even though the call has finished. I’m pretty sure that if the listening phone recognized that the monitored call had ended, it would continue through the custom context and we’d be rockin’. Since this is all being bridged into the same “conference”, is there something that needs to happen to notify the listening call that the bridge has terminated?

If I actually hang up the monitoring phone, the ‘h’ extension executes, so I’m sure the phone is in accessing the right context.


(Lorne Gaetz) #11

One of the ChanSpy args is:

E: Exit when the spied-on channel hangs up.

My own testing with SIP has not needed it, but perhaps you would get the desired behavior if you change the chanspy line to:

exten => _.,n,ExecIF($["${spy_target}"!=""]?ChanSpy(${spy_target},dnqE))

(Dave Burgess) #12

Can do! I’ll let you know how it goes tomorrow.


(Communication Technologies) #13

Excited to hear how this goes, this is a function we are also looking to implement.


(Dave Burgess) #14

The script, with the addition of the “E” option, changing the “sleep” steps to five seconds, and my change to spy on SCCP phones works awesome. The "E"nd did the trick; if that works with SIP calls, I’d say add it to the script permanently.

I called the customer to test it yesterday, and she was confused (“but you said it wasn’t working??”) so I had to call her again today for her test it this morning and it works 100%. She’s super happy, and my phone has stopped ringing every hour asking me when it’s going to start working.

We’re all good.


(Dave Burgess) #15

The code I used is basically what @lgaetz has on his GitHub account. I thought the 1 second sleep was too short, so I increased it to 5 seconds, and adding the “E” made is exit correctly when the SCCP phones hung up. It’s working now.


(Lorne Gaetz) #16

Code is here: https://gist.github.com/lgaetz/78c4e114952e79596c1ed4123559d3d3

I’ve tested Dave’s suggestion and no change for SIP functionality so it’s been added. One thing Dave, the infinite loop bothers me so I’ve also added a line to set an absolute timeout on the channel which should prevent a permanent hung channel in the case of something weird happening.


(Dave Burgess) closed #17

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.