I’m using the continuous ChanSpy script that Lorne has on his GitHub page. I’m using it “as written” except for two things:
Instead of searching for a SIP/PJSIP extension, I’m searching for an SCCP extension
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?
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.
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
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.
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”.
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.
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.
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.
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.