[asterisk-dev] Implementing control over ChanSpy and its users

[Technique]

Hi asterisk-dev list,

This is my first letter to the asterisk-dev list.

It's rather long. If you wish to understand, you'll need to go through 
it in its entirety.

I have a complicated problem that needs a proper description to be 
understood fully, so here goes. This is not simply a problem, as it is 
also a way of solving the problem, and I am seeking approval, comments, 
or general ideas that will help me in this quest, hence the development 
relation.

As you all know, Asterisk has an application called ChanSpy 
(app_chanspy.c) that allows one party to "spy" on calls (regardless of 
not they are bridged or not, I have been able to spy on people on 
musiconhold). ChanSpy also handles the very important "w" option, which 
allows the spy, or person listening, to whisper to one of the parties.

However, ChanSpy is flawed. Chanspy might seem all well and good until 
you try to implement it in the real world. There are a number of things 
that one must keep in mind with the use of ChanSpy. If you'll allow me, 
I will detail them here:

Note: I am using the word "spy" in the sense of "whisperer" here. Which 
is, someone who "whispers" to someone in a bridged call.

1. The spy cannot spy on everyone.
2. The spy can be able to whisper on the local party of an incoming 
call, or an outgoing call.
3. The spy must not be whispering to the client or all is lost.
4. The three previous rules must not conflict with one another.

1. is easy. It makes no sense to allow someone (most likely a 
supervisor) to spy or whisper on the CEO of a company. This makes no 
sense at all and is a serious security issue.

2. is easy too. Calls that need coaching (or whispering if you will) can 
be coming two ways. What if the client called the representative? The 
representative cannot have coaching because the call was incoming? This 
obviously makes no sense.

3. can be understood by anyone. If a whisperer is mistakenly talking to 
the client, it's over.

4. is where it gets complicated. Not in understanding it, but in 
realizing it.

We have some ground rules. What rules are not currently fulfilled by 
chanspy? Well I'm sorry to say, 1, 2 and 3.

Let me explain when/how all those rules are violated. Let's say the 
company has three people that must be supervised, one is at extension 
SIP/1000, the other at SIP/2000, the third at SIP/3000. You have one 
supervisor watching over the three people. How do you allow the 
supervisor to spy on only those three channels? You might want to 
specify a <chanspec>, but it matches only the beginning of the string. 
Put SIP as a <chanspec>? Ok, you'll catch all three, but you'll also be 
whispering on the boss at SIP/4000. Not a good idea? You bet. You also 
have to think... what else could a chanspec of SIP catch? Of course it's 
going to catch conversations between the boss and an employee. It's 
going to catch conversations between employees and other employees. It 
makes limited sense, but it's a fun toy to use for sure.

So now the question becomes, how do I limit my supervisor to ONLY the 
the people he has to whisper to? And only when they are engaged in 
conversations with the outside world?

Now I know the educated masses that make up the readers of this mailing 
list will surely be yelling "What about SPYGROUP!", throwing various 
objects at this message. Well my enraged friends, a spygroup can only be 
set on an outgoing call. Setting this variable on an incoming call leads 
to pandemonium. The supervisor will then be whispering to the client. 
And lots and lots of deaths will ensue. For sure.

And I know. "You forgot ExtenSpy!" I all hear you expound. Well it IS 
specified in ExtenSpy that it can only attach to outgoing calls. So much 
for that one.

Here comes my intended, maybe ignorant or even crackpot solution, but I 
think it deserves a moment of consideration by even you, distinguished 
readers. I am also seeking guidance, and possibly even a little 
enlightenement. I'd like constructive comments, suggestions or other 
ways of doing what I'm proposing. As always you can keep and should keep 
non-constructive comments to your own distinguished self.

What you have to understand at this point is that one of the faces of 
the enemy is this "*". The "*" key during the use of chanspy. The "*" 
key searches for another channel to attach Chanspy to, as you all know. 
So... knowing my enemy, I propose as a FIRST possibility to add an 
option to app_chanspy to disable the use of the "*" key. Now now, I know 
it's not much, but I think it's a start, and would alleviate the ability 
to get into the boss' conversation. It still doesn't change the fact 
that the supervisor will be able to spy on conversations between 
employees, but it makes it possible to use dialplan logic to "lock" the 
supervisor to whisper on only one channel. He would then have to 
"re-dial" the Chanspy extension, enter his password, enter the extension 
he wishes to whisper to, after a quick check against a database, chanspy 
attaches to the extension, if allowed. This is a simple, borderline 
idiotic, or maybe even downright idiotic fix, but as far as simplicity 
versus functionnality goes, it's definitely a winner. I know it is 
annoying, but I don't think I have a choice here.

Then, let us move on to the second, more complicated solution, that 
would actually still make use of the "*" key, and I think it's 
definitely the one that would be wanted. What I am proposing here, is 
bold and daring, maybe a little crazy, but nice nonetheless. So my 
proposal relies on a couple of things, some will work, some won't. Help 
me out.

So what I am thinking, is that by pressing the "*" key, instead of 
attaching to the "next" channel like it actually does, it will check: Is 
that next channel sip? Is it bridged? What is it bridged to? Mister 
Russell Bryant told me that all these questions can be answered by 
ast_bridged_channel().

So I say, instead of mindlessly attaching to the next channel, let's 
attach to SIP, so we know we're on our side, and that we are actually 
whispering to our employees.

And here it gets tricky. We still have the boss problem. This will not 
prevent listening in and talking to the boss. So my idea, is that 
ChanSpy should "return" to me a variable that contains the next found 
channel. Chanspy should stop. I could then manipulate that variable and 
run it against my allowed extensions database. If it is allowed, then 
I'm going to re-run chanspy, with the new found, allowed channel. If you 
realize, this will allow you to:

1. Be sure you are connected to a channel you have the right to attach to.
2. Be sure you are talking to your guy.
3. This will allow you to whisper on calls both ways (incoming or outgoing).

Now it all makes sense, but there's a problem. One big unsolved problem. 
What if the next channel is not in my allowed list of channels? What do 
I attach to next? It's not app_chanspy's problem at any rate though.

And of course also remains the question: Is it possible?

Have a better way to do this? Questions? Suggestions? Criticism? Harsh 
Criticism? Expletives?

I realize it must seem like a half-baked idea to you, developers. I'm 
doing the best I can, I'm new to developing for asterisk, and I'm stuck 
between a rock and a hard place.

One thing is for sure though, you can keep any of the previous to 
yourself if they are not constructive.

If you read this then you took the time to read it all, and I thank you 
for it, even if you have nothing to say.

Of course I am not requesting a feature, I am offering to do this 
myself, and following your suggestions to boot.

Yours in asterisk,

Joe Tester

And many thanks to russellb and putnopvut, as usual.

Therr migth bbe typooes, apolloigiez.