Summary:	ASTERISK-00247: [patch] Change ZapBarge into ZapScan to allow monitoring of active channels
Reporter:	davetroy (davetroy)	Labels:
Date Opened:	2003-09-11 13:57:05	Date Closed:	2008-01-15 14:40:16.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) app_zapbarge_patch_1_01.gz ( 1) app_zapbarge.c-add-scanning-patch[1].txt ( 2) app_zapbarge[1].c-change-to-zapscan ( 3) app_zapscan.c
Description:	A fairly simple modification to ZapBarge that automatically scans for active Zap channels and monitors those, skipping on-hook channels.  Switch between channels with # key.  If there are no active channels that app will exit.
Comments:	By: John Todd (jtodd) 2003-09-11 14:19:23 Thinking about the way that ZapBarge is used, and then looking at your very useful extension to it, wouldn't it make more sense to just modify ZapBarge such that it would be used like this: ZapBarge([channel[|s]]): Barges in on a specified zap channel or prompts if one is not specified.  Returns -1 when caller user hangs up and is independent of the state of the channel being monitored.  If the "s" argument is provided, then scan through the off-hook Zap channels starting with the specified channel, using the "#" key to increment through active channels. By: davetroy (davetroy) 2003-09-11 14:32:43 Yeah, that makes some sense.  I had a very specific application that prompted me to do it this way, but maybe I'll just do that... By: davetroy (davetroy) 2003-09-13 15:21:11 OK, I took your suggestion and implemented it as you described.  With Mark's blessing this should be ready to go into CVS. http://asterisk.toad.net/app_zapbarge.c-add-scanning-patch.txt By: davetroy (davetroy) 2003-09-13 15:26:44 As a side note, I'd be interested in trying to adapt this code to create a SIPBarge or something comparable.  Of course I know SIP calls can't be monitored if they have been reinvited, but anything going through * should be accessible.  How feasible is this? By: John Todd (jtodd) 2003-09-13 20:30:18 I have no specific knowledge about how that would work, but I can't imagine it's terribly difficult.  The RTP streams, if locally parsed (because of a "t" dial modifier, or a "canreinvite=no", or a Monitor or a host of other reasons) will go through the same place as the Zap audio channels.  However, your patch goes through the Zap channel drivers specifically (since that's what ZapBarge does) so I don't know if you'd have to re-invent the wheel to put this functionality into all channels (why limit it to SIP?) By: Brian West (bkw918) 2003-09-13 21:01:18 I vote for the ability to bust in and scan all calls!  :) bkw By: davetroy (davetroy) 2003-09-14 13:02:23 I'll start doing some experimentation on it.  I get the impression from the ZapBarge code that the conferencing/monitoring functionality is based on Zap resources, whether real or dummy;  like perhaps you have to overlay all of your SIP/whatever channel resources you'd want to monitor into a real or imagined TDM resource as a way of getting them all into a common format.  Anyway, I'll play with it some.  Meantime let's go ahead and add the scanning patch to CVS. By: hex (hex) 2003-09-19 06:28:53 Could a service observing beep option be added (required in some states even though most people don't use it anyway) to alert the parties they are being monitored.  I also have a strange requirement where I would like to play an entry/exit tone to one party only (the agent) but I can figure out how to do that after the other feature is added :P Finally, any ideas of how to restrict that pool of calls to cycle through down to a context or billing code (hosting multiple applications/clients comes to mind)? edited on: 09-19-03 06:07 By: John Todd (jtodd) 2003-10-27 12:29:03.000-0600 Dave - any work on getting additional channel scanning added?  That would be a knock-out feature, and it may lead to other useful tools if you can make it based on channel name for any channel instead of just Zap channel name. (and if you could make it optionally dump into a context and be bi-directional with the audio stream, that would solve a large number of other issues, such as the lack of "whisper" in Dial) By: davetroy (davetroy) 2003-11-09 11:19:03.000-0600 I have done some playing with monitoring other sorts of channels (namely SIP in my case) but don't know enough about asterisk's channel structures to really know where to start.  If anybody has ideas, let me know.  I will continue to look at it. Meantime, I have added a significantly better version of the app_zapbarge.c patch (to allow Zap scanning) which is ready to be rolled into CVS. The service observing beep can probably be done readily enough as well as scanning by other sorts of attributes, but I consider that to be outside the scope of my capability and need at the moment. By: jrollyson (jrollyson) 2003-11-20 13:24:25.000-0600 Couple things I'd like to go along with this, for one, a QueueScan, and for another, the option to not hang up the line when there are no channels. By: zoa (zoa) 2003-11-20 13:32:47.000-0600 i tried app_zapscan.c (the patched app_zapbarge.c renamed to app_zapscan.c) It works sweet and without problems, although it might be usefull to exclude the zaptel chan you might be dialing to to do the scanning. eg. i have my app_zapscan linked to a channel on my E1, and when you listen to yourself its a very loud screeming sound :) maybe also include a parameter like zapscan(1-32,60-120) to be able to only monitor parts of the zaptel channels. (for privace reasons, eg to make sure that no one is listening to the callcenter managers. The existing version is ready to include AS A SEPERATE FILE/APP into the cvs if you ask me. By: Brian West (bkw918) 2003-11-20 13:35:19.000-0600 or make the patch smarter.. not allow scanning of src channel.  Also something more generic if it starts to work with more than just zap and sip.. how does ChanScan sound .. input? By: davetroy (davetroy) 2003-11-20 14:00:58.000-0600 jrollyson: If you check bug ASTERISK-211, the queue modifications I have done allow for recording of calls in a queue (regardless of the channel type, BTW). zoa: As written, the scanning app *should* exclude the channel you're calling from; it checks that (if channel_to_scan==me then don't).  I'll check that though. bkw: Yes, ChanScan is what I started to work on, though I really don't know how to do it.  Since live monitoring is essentially setting up a 3 way conference, there seems to be a significant amount of black magic that involves the Zap & conferencing code, which I am not sure it's easy to get around.  May be better to do recording than live monitoring -- it's certainly easier.  I will continue to keep this on my horizon, though. By: zoa (zoa) 2003-11-20 14:12:31.000-0600 in this version its also possible to listen to it when there are no zap channels in use. i tried the zapscan for 3 days and seemed to work fine, although i sometimes had the impression that i could not hear the "number" of the chan when switching. (but that could be just an impression, if someone else noticed this, maybe the announcement should have a small delay). For a call center, live monitoring is quite important. By: zoa (zoa) 2003-11-20 14:14:15.000-0600 maybe also add an option not to monitor zap channels that are still ringing. (I could hear tuuut... tuuuuut .... tuuuut... a lot, the sound before someone answers a call.) By: jrollyson (jrollyson) 2003-11-20 18:22:58.000-0600 davetroy: that records queue calls, but not live monitor. Also, can a call be live  monitored at the same time as recording is being used? also, barge by agent is imho essential. Supervisors tend to keep an ear out on a callcenter floor for phrases like. "I want to help you, but if you continue to use abusive language, I will terminate the call", and will want to be able to quickly find the channel in question. Looking to the future, maybe ZapScan could support direct access at the same time, perhaps by dialing the channel number while in scan mode. Another question, is the barge-in implementation detectable to the caller or to an agent? (Clicks, loss of volume, tones, etc) If the mic starts out muted, can it be unmuted from the monitoring mode? By: davetroy (davetroy) 2003-11-23 11:55:40.000-0600 > davetroy: that records queue calls, but not live monitor. Also, can a call > be live monitored at the same time as recording is being used? Yes, that should be possible. > also, barge by agent is imho essential. Supervisors tend to keep an ear out > on a callcenter floor for phrases like. "I want to help you, but if you > continue to use abusive language, I will terminate the call", and will want > to be able to quickly find the channel in question. Yeah, I agree, I just don't know how to do it yet. <g>  Recording the call, though, gets you consistent, persistent evidence of any such activity and would probably be more useful overall. > Looking to the future, maybe ZapScan could support direct access at the same > time, perhaps by dialing the channel number while in scan mode. Yeah, if you call it without the |s parameter you can enter a channel number. Put that on a different extension. > Another question, is the barge-in implementation detectable to the caller or > to an agent? (Clicks, loss of volume, tones, etc) If the mic starts out > muted, can it be unmuted from the monitoring mode? It looks to me as though it puts the parties into a conference where the monitoring channel is read-only; possibly changes could be made where it could become read-write in realtime, but again, the whole thing seems to hinge on the conferencing code, and once the conference is started, I'm not sure that's possible. zoa: It should not be listening to ringing channels unless ringing channels are listed as 'up'.  I'll check though to see if that can be refined.  All of my Zap channels are inbound (FXO, not FXS), so I never came across that myself. By: apnaisp (apnaisp) 2003-12-06 02:16:39.000-0600 Hi there ... The above patches are for only the Zap devices .... i would really appreciate if some can design a SipScan application, which listens any SIP Phone like GS or XLite (from either Zap or Sip phone). Azher By: zoa (zoa) 2004-01-09 20:15:47.000-0600 can app zap_scan be added to the cvs ? it works sweet for me, and i've been using it daily for quite some time now. Apnaisp's request was cross posted on http://bugs.digium.com/bug_view_page.php?bug_id=0000633 By: zoa (zoa) 2004-01-09 20:15:53.000-0600 can app zap_scan be added to the cvs ? it works sweet for me, and i've been using it daily for quite some time now. Apnaisp's request was cross posted on http://bugs.digium.com/bug_view_page.php?bug_id=0000633 By: zoa (zoa) 2004-01-09 20:16:05.000-0600 can app zap_scan be added to the cvs ? it works sweet for me, and i've been using it daily for quite some time now. Apnaisp's request was cross posted on http://bugs.digium.com/bug_view_page.php?bug_id=0000633 By: jrollyson (jrollyson) 2004-01-09 22:30:34.000-0600 As this is done as a new application, this shouldn't break anything too badly. I've been running it for a couple weeks in production and it works fine. By: Brian West (bkw918) 2004-01-11 01:48:02.000-0600 Added to CVS. By: Digium Subversion (svnbot) 2008-01-15 14:40:16.000-0600 Repository: asterisk Revision: 1935 U   trunk/apps/Makefile A   trunk/apps/app_zapscan.c ------------------------------------------------------------------------ r1935 | jeremy | 2008-01-15 14:40:15 -0600 (Tue, 15 Jan 2008) | 2 lines add new application 'zapscan' Bug ASTERISK-247 ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=1935