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. _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
