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.
Merely the ability to create groups with permissions - who can spy on whom, essentially - would be a huge benefit.
Group HR can spy on anyone except Executive group.
Group Management can spy on Call center group only.
Stuff like that. I’ve been using some dialplan that @lgaetz wrote a few years ago and just adding onto that to get the functionality I need but I’d be very interested in testing this module out.
Just FYI, Kapil got me going but we found an issue during the process that’s going to require some document updates. They made a change to stop DoS of fake keys so now you doing the refresh or receive after the key has been signed won’t show any updates. Performing either:
gpg --keyserver hkps://keyserver.ubuntu.com --recv-keys <your-key> or gpg --keyserver hkp://keyserver.ubuntu.com:80 --refresh-key will not result in Updated: 1 as documented now. The key won’t be pulled.
There needs to be a modification to gpg.conf (which in most cases doesn’t exist so it needs to be created). So you will need to edit/create ${GNUPGHOME:-$HOME/.gnupg}/gpg.conf and add this line: keyserver-options no-self-sigs-only,no-import-clean
Again these two steps are needed:
Edit/Add ${GNUPGHOME:-$HOME/.gnupg}/gpg.conf
Add this line: keyserver-options no-self-sigs-only,no-import-clean
Once that is done, the refresh and recv-keys options will show the changes as well as --show-sigs.
It’s not up yet as I’m still in development phase. It will be on Github when it is ready for public testing soon. Which is why I wanted my key signing out of the way.
A list.
Not at this time. Extensions do not have to be associated with a user and vice versa so putting this in User Manager requires an association to exist. At best I would hook into the extension settings.
In common language, spies track targets. But, in your module, it sounds like “Spy Groups” will not be a group of spies; instead, “Spy Groups” are a group of targets, correct ? If so, then perhaps “Target Groups” would be more accurate of a label – not to replace “Spy Groups” however, you might consider both, along the lines of @adell4444’s points. Something more like:
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.
gpg: error reading key: No public key
gpg: key B53D215A755231A3: new key but contains no user ID - skipped
gpg: Total number processed: 1
gpg: w/o user IDs: 1
Wasn't able to find a valid key. Sorry
UPDATE: This can be disregarded. Thanks to @billsimon for the tip, just needed to add my full key at the end of the command. Now it signs without issue and passes signature checks.
Assumed earlier that these will be exposed on the Admin → Feature Codes page but not seeing screenshots of such as of yet… Will the new codes added by this module be configurable via FC page Customize/Enable/Disable options ? (Could be a layered security approach ).
I’ve decided to not do that because these really aren’t feature codes. This is more of an application thing. I have tied into the extension mapping so that conflict/existing checks are done.
).
thank you.