Summary:	ASTERISK-09861: [patch]: Added automixmonitor feature / ability to use mixmonitor to record queue conversations on demand.
Reporter:	xmarksthespot (xmarksthespot)	Labels:
Date Opened:	2007-07-11 16:21:21	Date Closed:	2007-11-30 15:18:07.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_features
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 10185.patch ( 1) 10185v2.patch ( 2) mixmonitor_patch_version5.diff ( 3) mixmonitor_patch_version6.diff ( 4) patch_automixmonitor_branch_revision_75155_complete_with_dial.diff ( 5) patch_automixmonitor_branch_revision_75155_complete.diff ( 6) patch.diff ( 7) patchv2.diff ( 8) patchv4.diff
Description:	I needed to record queue conversations again on demand only. I found out about the option 'w' in app_queue, but found out it recorded using monitor and produced two sound files, as everyone knows. There was also the automon (*1 by default) feature, but that didn't help either, as I need it to work on a queue and produce only one file. I set out to find another way to do this, which led me to code this. What this patch does is add a new feature: automixmon, which is auto mix monitor. Now you can specify a new option in app_queue, which is called 'x', which lets the callee dial a string to get the conversation recorded by MixMonitor instead of monitor, and thus get only one file. I also added the 'X' function, just for the sake of being able to do all that Monitor does, and finally do away with it. ****** STEPS TO REPRODUCE ****** I'll just detail how it works here. I added the new feature in res_features and channel.h to add this feature. Then I modified app_queue to add the 'x' and 'X' options to trigger the automixmon function for the callee. It's actually pretty simple. It works fine, as long as you add automixmon=> *3 (I used *3 use whatever the hell you want) in features.conf. But it does have some caveats and todo-s left, which go in the next section. ****** ADDITIONAL INFORMATION ****** It's not perfect and I need guidance to complete this properly. I'll detail what's left to do to make it "worthy". Todo: -Add new channel variables like TOUCH_MONITOR and TOUCH_MONITOR_FORMAT to separate its function from Monitor. I don't know where to add new channel variables yet, so if you do, let me know. Probably they should be called TOUCH_MIXMONITOR and TOUCH_MIXMONITOR_FORMAT. For the time being, TOUCH_MONITOR and TOUCH_MONITOR_FORMAT apply the same way to automon as they do to the new automixmon. -Verify if MixMonitor is already running at the beginning of the builtin_automixmonitor()!!! Really important, otherwise you can sort of "recursively" MixMonitor a channel! MixMonitor(MixMonitor(MixMonitor(MixMonitor(... ...)))). I definitely don't want that. Otherwise it works fine, you can even specify the filename after the uniqueid to your liking, and chose a format for your file. It's all good. Please comment and help me out to finish this.
Comments:	By: Russell Bryant (russell) 2007-07-11 18:51:37 Most of your code is indented with spaces.  Please change them to tabs.  :) By: xmarksthespot (xmarksthespot) 2007-07-11 19:42:30 There we go! patchv2.diff features tabs (ooh, fancy)! I think I get it though, the channel variables are just set or not set, so I just have to change their names in the patch and use the dialplan Set() function on them! Should work! I forgot one very important caveat: I can't stop recording. Don't know how to do so. Maybe I just need to add a keypress for that in features. If you think of something let me know. At any rate it DOES stop when hung up. I think it's important to stop recording on demand. Very important is going to be to set a variable to know that this has been activated once, to prevent recursive use. I don't even want to know what happens if that can be done. By: xmarksthespot (xmarksthespot) 2007-07-12 11:36:40 Todo: <S>-Add new channel variables like TOUCH_MONITOR and TOUCH_MONITOR_FORMAT to separate its function from Monitor. I don't know where to add new channel variables yet, so if you do, let me know. Probably they should be called TOUCH_MIXMONITOR and TOUCH_MIXMONITOR_FORMAT. For the time being, TOUCH_MONITOR and TOUCH_MONITOR_FORMAT apply the same way to automon as they do to the new automixmon.</S> Done! It now uses TOUCH_MIXMONITOR and TOUCH_MIXMONITOR_FORMAT and some other variable for the output! We're moving forward! -Verify if MixMonitor is already running at the beginning of the builtin_automixmonitor()!!! Really important, otherwise you can sort of "recursively" MixMonitor a channel! MixMonitor(MixMonitor(MixMonitor(MixMonitor(... ...)))). I definitely don't want that. -Enable a keypress to stop the MixMonitor. Maybe the same when pressed a second time. By: xmarksthespot (xmarksthespot) 2007-07-13 17:14:34 Adding an insurance policy. I discussed this with putnopvut (he rocks!) and he thought of lots of brilliant stuff, and I just uploaded this one since it builds and it could potentially fix both remaining caveats... hence making the patch complete! And enabling people to use mixmonitor instead of monitor everywhere. Thanks to putnopvut! I'll resume testing monday. If it all works, all that will remain is a patch to trunk, and it will be DONE. By: xmarksthespot (xmarksthespot) 2007-07-13 17:25:43 Argh! I forgot to clear the flag, the sort of annoying little mistake you should get right the first time around otherwise it makes people waste time uselessly. By: xmarksthespot (xmarksthespot) 2007-07-17 13:19:22 Finally! It works! The patch_automixmonitor_branch_revision_75155_complete.diff has the automixmonitor working for queues! Dialing *3 starts it, dialing *3 again stops it on the channel. Thanks to putnopvut for all the help! By: xmarksthespot (xmarksthespot) 2007-07-17 16:38:17 Added a new patch, as it would make sense to be able to use the automixmonitor with the dial application too, in the same way monitor was used. The last patch covers everything I thought of until now, which is the use of the automixmonitor with queues and the dial application. By: Mark Michelson (mmichelson) 2007-11-13 11:18:40.000-0600 I have updated the patch since it had become outdated. Changes include using the audiohook API instead of chanspy, as well as accommodating for the 64-bit flags which app_dial uses now. I also fixed a few minor bugs I found in the original patch. Please give this a test and let me know if you encounter any issues. By: xmarksthespot (xmarksthespot) 2007-11-16 16:09:59.000-0600 I will test the automixmonitor patch as soon as possible, I need to get a trunk machine going here first. I should be able to try it soon. By: xmarksthespot (xmarksthespot) 2007-11-29 10:39:58.000-0600 Delays delays delays... I'm a little past the test date. I will do everything in my power to try it tomorrow. By: Mark Michelson (mmichelson) 2007-11-30 14:30:59.000-0600 Uploaded 10185v2.patch, which was made against trunk revision 90232. This should apply cleanly. By: xmarksthespot (xmarksthespot) 2007-11-30 15:09:35.000-0600 Tested on my asterisk trunk development machine, revision 90351. Tested both ways, calling in from a cell phone, out from a sip polycom phone. Worked flawlessly both ways, can provide files of recordings for verification purposes if needed. Good work everyone, especially putnopvut and myself. By: Digium Subversion (svnbot) 2007-11-30 15:18:07.000-0600 Repository: asterisk Revision: 90388 U   trunk/apps/app_dial.c U   trunk/apps/app_queue.c U   trunk/configs/features.conf.sample U   trunk/include/asterisk/app.h U   trunk/include/asterisk/audiohook.h U   trunk/include/asterisk/channel.h U   trunk/main/audiohook.c U   trunk/res/res_features.c ------------------------------------------------------------------------ r90388 | mmichelson | 2007-11-30 15:18:06 -0600 (Fri, 30 Nov 2007) | 15 lines Adding support for the "automixmonitor" dial and queue options. This works in much the same way as the automonitor, except that instead of using the monitor app, it uses the mixmonitor app. By providing an 'x' or 'X' as a dial or queue option, a DTMF sequence may be entered (as defined in features.conf) to start the one-touch mixmonitor. This patch also introduces some new API calls to the audiohooks code for searching for an audiohook by type and for searching for a running audiohook by type. Big thanks to joetester for writing the initial patch, testing it and patiently waiting for it to be committed. (closes issue ASTERISK-9861, reported and patched by xmarksthespot) ------------------------------------------------------------------------