[Home]

Summary:ASTERISK-01261: [patch] Update monitor app to exec custom script when channel closes
Reporter:scrubb (scrubb)Labels:
Date Opened:2004-03-21 14:53:01.000-0600Date Closed:2008-01-15 14:57:10.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) monitor.patch
( 1) monitorv2.patch.gz
( 2) monitorv3.patch.gz
( 3) monitorv4.patch.gz
( 4) monitorv5.patch.gz
Description:Update monitor app to:

a) have an option to exec a custom script with the individual file legs or soxmixed file as paramers once the monitor resource releases the files.

b) Ensure that all parameters are available to the monitor aplication from the manager interface.

****** ADDITIONAL INFORMATION ******

My primary reason for wanting to do this, is the ability to issue a monitor command on a channel from the administrator interface and have the file e-mailed to a specified address once the call is done and the soxmix option executes.

A more general approach in my mind is to exec a script or executable that is specified to the monitor app or administrative command.  The scipt would get executed once the recording files are safely closed, and would receive the names of the recorded or mixed file(s) as command line parameters.

I can see value here for not only e-mailing the files, but mpeg'ing them off line (non blocking) or archiving them and inserting info into an archiving database.

I hope to be working on this in the next few weeks.  But if someone is just chomping at the bit to do something like this or in process, please let me know.

Comments:By: scrubb (scrubb) 2004-04-05 22:44:41

Ok, I've tested this out localy as much as I could. I'd be thrilled if others could as well.  I managed to forget to update the syntax, etc before I uploaded the patch.  I'll update these and upload a new patch.  Esentially, I added a last parameter to the Monitor app that will be a script to execute when the monitoring stops.

I also added admin interface options when starting monitoring to set the mix flag and executable file name.

I'll upload the documented patch in a bit.

By: scrubb (scrubb) 2004-04-06 00:09:55

Sorry for the premature upload, if you can delete the first one, that would help.  I have tweaked out a bug and added the description text.  If anyone out there can test this as well, I'd appreciate it.  I'll keep testing as well.

By: scrubb (scrubb) 2004-04-06 14:27:53

Latest patch fixes segfault if not all the flags are there.

By: twisted (twisted) 2004-04-07 03:11:28

I upladed res_monitor_custom.diff to also handle this.. it allows the 'c' flag in Monitor() to use callmerge.sh in the default path, and the added callmerge.sh script (if you want, it *IS* an example provided by slePP), also, the following dialplan rules provided by slepp work well with his example script.

exten => s,1,GotoIf($["${CALLFILENAME}" = ""]?2:6)
exten => s,2,SetVar(CALLFILENAME=${TIMESTAMP}-${CALLERIDNUM}-${MACRO_EXTEN})
exten => s,3,Monitor(wav,${CALLFILENAME},c)
exten => s,6,NoOp

I think this would add more versatility to the joining of the files, as you can technically do anything you want with them via shell scripting.

By: Olle Johansson (oej) 2004-04-07 03:14:13

I think you should not use system() - there's a new safe system() replacement - please check in app_voicemail how we call the mailer from within Asterisk.

By: twisted (twisted) 2004-04-07 03:16:54

I should have done that, yes, considering I am partially the cause for ast_safe_system() to have been created :P


I will update the patch accordingly

By: twisted (twisted) 2004-04-07 03:33:07

Patch updated to use ast_safe_system().. I also updated all system calls in monitor.c to use ast_safe_system(), just to be 'safe'.

By: scrubb (scrubb) 2004-04-07 09:54:10

I'm not following.  Twisted, are you proposing your patch as an alternate means of accomplishing the goal?  It looks like a patch against a clean res_monitor.c and not against a patched res_monitor.  

Anyway.  There's no reason they can't both work at the same time.  Why? you might ask.  So different calls can have different things done with the recorded or mixed files when they are done.  i.e. depending on the line or manager that initiated the recording, the file gets send diferent places or filed differently.  Anyway, I'll update my patch to use ast_safe_system().  I was having wierd behaviour that was returning a -1 from system even when it was successful.  Anyone know what thats about?

I'm not sure how to merge both patches together.  Is there a way to do that?

By: twisted (twisted) 2004-04-07 17:40:45

Actually, I was proposing this as a different way of handling this.  It is a patch against a clean res_monitor.c.  If you want to merge the two together, feeel free.   I am still learning most of this stuff, so, quite honestly, I have no idea how to merge the two, other than to look at res_monitor, patched with one or the other, and go about patching it by hand with the left-over patch.

By: scrubb (scrubb) 2004-04-07 23:48:57

I like your work, and I need to update my patch to use ast_safe_system.
However, I would suggest that the "exec" option allows vastly more flexibility.  It allows a unique script with unique parameters to be run on each different call recording thread.

There may be many reasons why different recordings should be mixed in different ways (in=left / out=right stereo, mpg, wav, etc.).  In my case I have different dept heads wanting their people's calls recorded, mixed, and e-mailed or filed in a voicemail box very differently.  I like being able to have different scripts to handle these functions based on channel variables.

Additionally, by ommiting the "m" option you can custom mix the legs yourself in the exec'd script.  When the "m" option is omited, the exec script is handed both file names instead of a single mixed file.

By: scrubb (scrubb) 2004-04-08 00:08:23

Updated patch to use ast_safe_system

By: scrubb (scrubb) 2004-04-12 16:26:21

Sent disclaimer to Digium.  Just waiting on testing now.  My test are golden except that I get a -1 returned from the system command regardless of succes or failure of the program.  So I disabled the warning messages on return of -1.

So unless someone has a fix for that, this should be good.

By: jamieg (jamieg) 2004-04-15 09:52:06

Hi I am trying your patch, and was keen to see how well it worked and all, however, I got the latest CVS and attempted to apply the patches above, but they did not want to apply without errors.

Could you please point out to me where I am going wrong..
I apply the patch with the comment
patch < monitor.patch
and
patch < res_monitor_custom.diff  (This one appears to reference files that are not in the default locations as according to a /usr/src/asterisk build dir.

UPDATE: Doing a full FRESH cvs update fixed this..  ???? (Why I don't know)

edited on: 04-15-04 21:20

By: scrubb (scrubb) 2004-04-15 09:54:43

please dont do the res_monitor_custom.diff.  This is not part of my patch.  This was uploaded by twisted and it is a copmletely different way of doing this.  My opinion is that it needs to be removed from this bug thread to avoid confusion such as this.  The monitor.patch is all you need.

By: scrubb (scrubb) 2004-04-15 09:59:51

Here's how simple it is to use this:

exten => s,1,Monitor(wav,testrecord,m,/var/lib/asterisk/scripts/sendfile)

My sendfile app reads:
/usr/bin/metasend -F "test@asterisk.local" -t myemail@server.local. -s "test" -e base64 -D "Sound File" -m audio/x-wav -f $1 -S 10000000 -b

So I get all my calls recorded, mixed, and sent to me in e-mail.

By: jamieg (jamieg) 2004-04-15 11:47:57

Reminder sent to scrubb

Ben,
I actually have an idea for a small addition to this little feature we have.  And that would be, after monitoring and joining/compressing the recorded calls, store them in a directory for up to  X days, or Y meg of disk space usage.. and.

Allow the caller dial a certain extension and it will get the last call on his extension and EMAIL it to him.  Have to think out how difficult this will be. AGI or real coding needed?

And also make some type of WEB page for browsing the calls for the archival period set.

James


By: scrubb (scrubb) 2004-04-15 11:57:28

My thought is that these "features" don't need to be part of the res_mointor thread itself.  The idea that a custom script would be executed is to allow pretty much all of what you described to be done externally.

For example.  The script that get executed stores the mixed file in a users special directory.  Then a cron job actually prunes the directories for how long the files should stay there.  Elsewhere in your dial-plan you can have a section where the user can login and listen to any files in that directory.  

All of this is possible with fairly simple perl scripts, some minor dial plan additions, and the existing patch.

By: jamieg (jamieg) 2004-04-15 23:42:32

I have got this working and have discovered a bug as follows..
I have been Monitoring GUEST IAX connections and my analog dial in (No CID)
The following recorded files where created.
For the IAX call:
20040416-125644-"Guest IAX User-2104-in.wav
20040416-125644-"Guest IAX User-2104-out.wav
For the X100P modem POTS call:
20040416-132204-"Unknown (CallerID OFF)--in.wav
20040416-132204-"Unknown (CallerID OFF)--out.wav

NOTE: the "m" option did not JOIN the files, and having a " in the filename never good.
I imagine the mangled file names above confused the MIXING functionality.

I would also like to mention that the documentation is confusing in that the "m" option will mix the audio.  What is the option to NOT mix the audio?
For example
Monitor(wav,file,m,ScriptToRunAtEnd)
Monitor(wav,file,,ScriptToRunAtEnd) is implied for not mixing the files.
Maybe the option "n" should be used for No MIX,  The documentation does not logically follow and I find it very confusing.

By: twisted (twisted) 2004-04-17 19:31:40

scrubb:  the reason it was added HERE and not in a different bug was to avoid duplicate bugs.  oej: Please DOCUMENT your actions, also, don't just go removing people's work.  

ALL: If you want a copy of my version of this patch, forget it.  I lost my HD in a crash the other day, and the copy i had here was THE ONLY ONE I HAD.  Thanks oej.

By: Olle Johansson (oej) 2004-04-18 04:11:40

Twisted: I'm awfully sorry. Accidentally convinced myself you had it in another bug #. This is combination with your dead HD caused a disaster. My apologies.

By: twisted (twisted) 2004-04-18 10:41:20

S'ok.  I'll look into recreating it, or possibly slePP has a copy..  Sorry if I seemed harsh.. Got a few things going on at once over here.  I understand the best intentions.  :)

By: scrubb (scrubb) 2004-04-22 14:32:05

jamieg: Thanks for testing this patch.
Yes, I'm sure the " messed things up.  neither my code nor the mixing code attempts to escape the command line.  I'd be happy to look at some kind of fix, but I'm not sure what the best approach would be to handle escaping characters.  Both the mix code and my code simply "system" a call.
Anyone have any suggestions on handling "'s or other special characters for a system command?

I was just adding on after the "m" addition.  I assumed that it was clear that the "m" was a flag, and its abscence indicated no mixing.  
Again, any suggestions on command line's to fix confustion or are you just suggesting better documentation.


twisted:  Sorry bout the patch confusion.  I'll see if I still have a copy somewhere as well.

By: Mark Spencer (markster) 2004-05-02 14:08:51

My suggestion here has been that you simply permit a variable (e.g. MONITOR_EXEC) which can override the default of soxmix.  It would be just a few lines of code change and highly unintrusive.

By: slepp (slepp) 2004-05-02 19:53:26

The lost file, did it come back? I have them all, since I'm using this patch in production with my callmerge.sh script. (It's working like a charm, and I don't think I had the problem with spaces in names, but maybe I did).

By: scrubb (scrubb) 2004-05-02 20:30:06

Ok, I will change my patch in the following way:

a) MONITOR_EXEC if set will override the m option and NOT mix the files.
b) MONITOR_EXEC will contain an application AND arguments
c) the MONITOR_EXEC application will get passed both in/out sound files as the LAST two arguments.
d) I will leave in the manager interface commands to enable mixing and add the MONITOR_EXEC parameter so these can be done while a call is active by an external app (one of my goals).  The Execute application will still override the "m" flag in this case as well.

I'll upload the patch when I've got these tweaks in it.

By: scrubb (scrubb) 2004-05-04 02:46:37

Patch created.  Local testing before uploading a new copy.

By: Mark Spencer (markster) 2004-05-23 20:16:03

How's it looking?

By: scrubb (scrubb) 2004-05-24 10:09:23

I've got the patch written and then we had our new baby.  So I have not tested it any more than compile-ability.  I can upload just the patch if others are willing to test.

By: scrubb (scrubb) 2004-05-24 11:06:27

The .gz is the new patch.  It compiles and loads.  Please test test test

By: Mark Spencer (markster) 2004-05-24 11:25:18

Okay a few things:

1) pbx_builtin_getvar_helper is your friend.  No need to reinvent it.

2) I don't see any need for ast_monitor_setexecute since we're using a variable. the field doesn't need to be added right?

We're looking a lot better :)

By: scrubb (scrubb) 2004-05-24 11:33:44

ast_monitor_setexecute is definetly needed.  The parameter needs to be not only setable from the variable, but from the Manager interface.  The function sets the struct member when this value is set from the Manager interface and this OVERRIDES any channel variable set in the dial plan.  

I will take a look at the pbx_builtin_getvar_helper.  Is there some set of docs somewhere that I can find API things like this documented?  I copied and pasted my variable finder code from another app because I didn't know about the helper function.

Will upload an updated patch soon.

By: scrubb (scrubb) 2004-05-24 14:30:00

OK patch v3 is up there now.  It uses pbx_builtin_getvar_helper.  Again, this will compile and install, but it needs to be tested.

By: Mark Spencer (markster) 2004-05-24 17:32:20

Why would it be run by the management interface?

By: scrubb (scrubb) 2004-05-24 18:42:32

Here is ver specific example of why call monitoring and ALL its options need to be accesible from the managment interface.  This is my scenario.  I am using Cisco7960's.  I have the "services" button linked to a menu.  One of the options on that menu is "record".  This button lets the user start call recording on any call or calls in progress.  The recording will then be delivered to their e-mail box as defined in the voicemail.conf when the call ends.  To do this, we need to connect via the managment interface and tell * to start recording a specific call, and what to execute when it is done.

In addition, when the "exec" option is set by the manager interface it should override the "exec" or "mix" option that is in the dialplan, allowing an admin or user to override default call recording parameters.

I'm sure there are a million and one other examples of how usefull it would be to control these options from a GUI or other external app.

By: Mark Spencer (markster) 2004-05-25 00:28:07

Let me make another suggestion then.  How about we allow the manager interface to set or retrieve an arbitrary variable associated with a channel then?  That would be much more general purpose.

By: scrubb (scrubb) 2004-05-25 14:19:48

Ok, Ok.
The patch to res_monitor is very simple. Just execs anything in the channel variable MONITOR_EXEC.  No manager interface ,no command arguments, nothing.  Simple.

This also patches manager.c and creates a very simple "Setvar" command that will set a channel variable on a channel.

Hows it look Mark?

By: scrubb (scrubb) 2004-05-27 16:59:00

Version 5 of the patch:
Ok, Mark and I worked this out.  Here's how this feature works:

the "m" flag means to "mix" the recording legs when done with recording.  NOTHING is executed unless there is an "m" flag.  
If MONITOR_EXEC is not set then the files are mixed with soxmix and the leg files are deleted
If MONITOR_EXEC _is_ set then whatever is in it is run in place of soxmix and the leg files are NOT deleted.  
In either case the executed program is handed 3 filenames, the in leg, out leg, and the name of the target file to mix them into.  

In order to allow this feature to be controllable via the manager interface the "m" flag is settable via the manager interface.

This patch also adds SetVar and GetVar functions to manager.c so not only can the MONITOR_EXEC variable be set from the manager interface, but so can any other variable.

I still do not have the facilities to test this beyond compile and load.  I am working on getting my test lab back.  Please take time to review and test this patch.

By: Mark Spencer (markster) 2004-06-03 10:41:14

Added to CVS with minor modifications.

By: jamieg (jamieg) 2004-06-07 00:23:43

Reminder sent to markster, scrubb

Hi, Jamieg here back to test this patch.  Been away for a while.  I see considerable work has been done since.  However, I am having problems applying the patch again.  Fresh CVS update, "patch < mopnitor5.patch" and... no go.
"can't find file to patch at input line 8"
Have looked the the patch and stumped as to why I have these problems.  Commands appriciated.

By: Digium Subversion (svnbot) 2008-01-15 14:57:10.000-0600

Repository: asterisk
Revision: 3137

U   trunk/manager.c
U   trunk/res/res_monitor.c

------------------------------------------------------------------------
r3137 | markster | 2008-01-15 14:57:10 -0600 (Tue, 15 Jan 2008) | 2 lines

Make monitor merge application settable via variable, allow setting of variables via manager interface, allow mix flag to be set via manager (bug ASTERISK-1261)

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=3137