Summary:	ASTERISK-02903: [patch] press a key, record a call. Configured via dialplan variables.
Reporter:	twisted (twisted)	Labels:
Date Opened:	2004-11-30 00:39:56.000-0600	Date Closed:	2011-06-07 14:05:21
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_features
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) onetouchmonitor.txt
Description:	summary pretty self explanitory, but let me go int a little example of it's use: exten => _10XX,1,SetVar(RECORDKEY=*) exten => _10XX,2,SetVar(MYMONITOR=wav|${UNIQUEID}|m) exten => _10XX,3,Dial(SIP/${EXTEN},h) This will set the monitor to record when the * key is pressed (overriding the * to disconnect), and ONLY accept the * key from the local channel (not the caller, but the callee on an incoming call and vice versa on an outgoing call - this is the default behaviour, regardless of the direction of the flags).  Currently, this requires at least one option to be turned on to avoid the bridge, as I haven't ahd the time to hack up the rest of the files to add YADF (yet another dial flag).  The MYMONITOR variable are just normal options passed to Monitor(), and the RECORDKEY var is the key you wish to use to activate/deactivate recording. ****** ADDITIONAL INFORMATION ****** Disclaimer on file ;)
Comments:	By: twisted (twisted) 2004-11-30 00:43:26.000-0600 Oh, forgot to mention, whatever key you assign using RECORDKEY will override any other functionality of that key during that particular call.  Also, the DTMF for that key will be muted to the other side. By: connor (connor) 2004-11-30 21:20:05.000-0600 I assume this only works on calls that are proxyed (no-reinvites).. Correct? (Even though technically, depending on the DTMF (inband, rfc2833, info) those DTMF tones/info would still goto asterisk in the event of a key-press..   If this doesn't work with re-invites, how hard would it be to make it re-issue another re-invite to proxy the media stream again to facilitate the monitor? By: egnarf (egnarf) 2004-12-02 07:17:12.000-0600 The if-block below seems odd. If who is not the same as chan, doesn't that mean that the "wrong" side pressed a key? In any case, it seems at least to be pointless. (or i'm blind =)) if (who != chan)  reckey = pbx_builtin_getvar_helper(chan, "RECORDKEY"); else  reckey = pbx_builtin_getvar_helper(chan, "RECORDKEY"); By: twisted (twisted) 2004-12-02 09:41:33.000-0600 Yes, it is sorta pointless, but this patch is also in the beginning phases..  You should have seen the comment I had in there before ;P By: b4 (b4) 2004-12-02 21:54:13.000-0600 It works and is quite useful :) would be more appropriate if the record key and other parameters are defined as a general entry in the conf? By: twisted (twisted) 2004-12-04 00:38:14.000-0600 cosmetic update ;) By: twisted (twisted) 2004-12-04 00:58:32.000-0600 and remove the two end beeps from the recording :P By: twisted (twisted) 2004-12-15 20:55:11.000-0600 C'mon folks, test it out, modify it, make it change the diapers on your kids, but don't let my patch go stale!  I put hard time into it, and I'd have to have to close it!  hehe... basically, I don't have the time to add a flag to prevent the bridge, so if anyone can, and add that patch here, would be much appreciated ;) By: egnarf (egnarf) 2004-12-16 09:04:23.000-0600 I don't understand how you control which channel is allowed to start the recording. I want to be able to start it when someone calls me, or when I call someone but they should not be able to start the recording. By: egnarf (egnarf) 2004-12-17 03:51:41.000-0600 Just installed and tested it out with asterisk v1.0.2 Apparently it does the "right thing" wrt. who is allowed to record, although I don't understand how =) Care to enlighten me? Other than that I like it, and it works great! Would love to see it in CVS (and stable, if that's possible =)). Thanks! By: twisted (twisted) 2004-12-17 11:14:09.000-0600 basically we only allow our local channel to record.  when you recieve a call, you are the channel.  when we make a call, you are the channel.  Basically it's setup not to care where the call originates, but to only use the local channel - Whereas  the T and t options change where we listen for the dtmf from chan to peer depending on the flags.  Quite simple really ;)  Some call it magic. hehe. By: mochouinard (mochouinard) 2004-12-31 10:59:04.000-0600 Ok I love this patch... Ive created patch 003205 that allow to specify in app_dial only to make the DTMF process for res_features. Current example show to use 'h' as flag (also now you need to put a timeout time in the dial command, just do Dial(SIP/blah,,h) (bug 003205 will be b or B) I wonder if the flag bB in app dial should now be an application that set that flag... So that it will work with any app that does call bridging instead of just Dial.   The patch is working fine over here. By: mochouinard (mochouinard) 2005-01-04 14:55:14.000-0600 should this patch be closed in favor of 3241 ? By: twisted (twisted) 2005-01-05 02:16:58.000-0600 no, as 3241 is for transfer, this is recording i'm in oklahoma/texas right now, will update when I get back. By: Anthony Minessale (anthm) 2005-01-05 13:16:46.000-0600 you may want to take a look at the new CVS there has been a new feature DTMF processing system implemented recently by mark that will break most lingering patches to res_features/app_dial After mourning the death of my attended transfer patch which was obliviated by the new CVS, I took a look at the new stuff and was able to reimpliment most of it very rapidly using the new way (I lost tbe ability to set the keyprefs from app_dial but you still can set it system-wide in features.conf) I soon realized that one touch record was also very easy to implement using the same new code so it was able to make that in like 15 min flat so 3241 does also incude one touch record. By: twisted (twisted) 2005-01-05 15:07:22.000-0600 Fine.