Asterisk offers two ways to spy/barge/whisper on active calls. ChanSpy which allows you to spy on channels (PJSIP/100, IAX/100, Local/100) and ExtenSpy which allows you to spy based on ext@context (100@from-internal). These are widely used functions in call centers and other agent based scenarios.
FreePBX’s currently only uses ChanSpy and the implementation is as basic as it comes. It allows any users to spy on any active call and in a lot of use cases, this can be problematic. The lack of restrictions and configuration of ChanSpy have recently left FreePBX users with a bad taste in their mouth. I have started to work on a module that will address these concerns.
I am hoping that in the next couple of weeks it will be ready for late alpha/early beta testing. It currently will provide the following functionality (quick run down):
It will disable the 555 ChanSpy feature code used by default in FreePBX and replace it.
Multiple Spy Codes (feature codes). This will allow for more than one feature code to initiate spying. Allowing for each Spy Code to have its own feature set.
Choose whether the Spy Code is ChanSpy (default) or ExtenSpy
It will allow for an authentication PIN to be set. This will require any user to provide the PIN in order to spy.
It will allow you to configure which options are available such as Barge, Whisper, Private Whisper, etc.
Extension Restrictions - restrict which extensions can be spied on.
Spier Restrictions - restrict which users can use the Spy Code.
Spy Groups - Create Spy Groups, add extensions to the Spy Group and restrict Spying to one or more groups. If the extension is not in one of the groups, it can’t be spied on.
Spy Recordings - Allow for the recording of channels/extensions being spied on. May not be in the initial release as I feel there should be an interface to view/listen to said recordings.
the pathetic joke of chanspy is it is a one line fix in extensions_overide_freepbx conf to add a PIN. exten => 555,1,Authenticate(somePINnumber)
I note Lorne was telling people to go buy class of service to fix it instead.
@lgaetz or @theJames Is there a decent way for me to extend the dialplan classes from extensions.class.php in the libraries? One that doesn’t require me to use an old functions.inc.php file in the module? While there’s ext_chanspy class I need to add one for ExtenSpy and one or two other apps/functions in Asterisk that doesn’t currently exist in extensions.class.php.
Otherwise, I guess I’ll need a framework PR to get these in.
on *another forum, I kind of poked fun at someone who raised the “chanspy major security issue” to the Sangoma CEO as evidence that Sangoma does not have security as a top concern.
Yeah, this is basically it. Disable the feature code and write your own two lines of dialplan with a PIN. Or use this override. For luxury and comfort, use Tom’s new module
James certainly knows more than I do about this, but I don’t think there’s a way to do this without adding the new classes you need. Going from very old memories, but I recall there being a generic function for adding dialplan applications that were not already coded, but I don’t see anything like that in the extensions.class.php library.
Thanks. I will wait to see what James has to add. I’ve just modified extensions.class.php with the new stuff for now. Since I’m already getting warnings, what is one more
If there isn’t a generic method for this, perhaps this might be the time.
Edit: Look like you can just call new \extension('Full dialplan here') and it works. Just no syntax validation.
one line, setup when admin installs, its done, as only the tech and client managers would have it.
Dont know why you’d poke fun at anybody for calling sangoma out for, it is a security problem, how many people have listened into calls they shouldnt have, hope you dont have EU clients with that attitude, the GDPR might bite you on your ass, even if you live in US, your liable for EU users.
Did you also note how Lorne told everyone that the community was free to submit updates/changes to fix ChanSpy how they wanted? For as long as Sangoma has said they aren’t going to do anything with ChanSpy they’ve said the community could go to town and it would be accepted into the project. Instead of making a community fix people just flexed about their one liners of code. Then they complained that Sangoma wasn’t doing anything.
As far as I can tell, I’m the first person to actually address the issue in a real manner. Because of that, I’m not going to let this kind of stuff derail my thread where I asked for input and suggestions on solving this issue everyone seems to be up in arms about. On both forums I’ve got zero input or response back from any of the community on what they would like to see or any other input.
You want to complain about Sangoma, that’s fine do it in your own thread. Any future comments complaining about Sangoma and their handling of ChanSpy will just be flagged as inappropriate for this thread.
In the final stretch in alpha testing. I’m guessing by the end of the week I’ll have this ready for use. Need to do some final testing on what I can and get everything ready and up on Github.
The first release will be 100% beta and will need some testing done in real scenarios, I can only have so many calls with myself for the testing.
Notice the Event Log and Generate Hint options. You will be able log spy actions to the CEL. It will capture who the spier was, when they started spying, the spy code used. Can’t capture DTMF and different channels spied-on (that does get captured in the full log) but when the spier hangs up it will capture the end time and the last channel spied on.
As well, it you will be able to generate a BLF hint that you can monitor to see when a specific spy code has been activated.
