Summary: | ASTERISK-06287: MIXMONITOR_FILENAME is not available on SIP -> ZAP calls for script processing. | ||
Reporter: | reformed (reformed) | Labels: | |
Date Opened: | 2006-02-10 23:35:42.000-0600 | Date Closed: | 2008-01-15 17:11:33.000-0600 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Applications/app_mixmonitor |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) extensions.conf ( 1) fail.txt ( 2) full.txt ( 3) patch_app_mixmonitor.patch ( 4) worked.txt | |
Description: | On calls SIP -> ZIP when SIP client hangs up before ZAP client MIXMONITOR_FILENAME variable does not exist. The <command> portion of MixMonitor application is unsusable in this situation because filenames cannot be passed to stripts. This is because MIXMONITOR_FILENAME does not exist when mixmonitor_thread prepairs its post_process string for parsing because it went down with SIP channel. | ||
Comments: | By: BJ Weschke (bweschke) 2006-02-13 21:32:31.000-0600 can we get a debug/trace of this along with an example of how you are calling MixMonitor in your dial plan attached to this bug please? Thanks. By: reformed (reformed) 2006-02-14 05:34:15.000-0600 I stripped the extensions.conf to just relevant part (where the call somes though). In fail.txt SIP call was done to another SIP device (GSM gateway, but same thing happens to SIP->ZAP calls as well) and the originatig SIP phone has hangup first. IN worked.txt the SIP/vblue2s device hangup first. The only difference is the last line where you can see that the MIXMONITOR_FILENAME was not evaluated when mixmonitor pased the command for execution. Is this the information you were looking for? By: BJ Weschke (bweschke) 2006-02-14 05:52:23.000-0600 We also need debug / verbose info from "set debug 10" and "set verbose 10" on the "full" logger channel set in logger.conf. Thanks. By: reformed (reformed) 2006-02-14 06:26:13.000-0600 I'll be...... As soon as i set debug 10 it works every single time! The full.txt has 3 calls (all were called but not answered). The first 2 were done without debug 10 the last one is and the variable was processed. COuld it be that the variable proccessing is done in one of the if(debug){} somwhere in the code? With debug 10 it works all the time but would obviously be undesirable to run full debug log on a busy system. Is there anything else i could do to help find it?? By: reformed (reformed) 2006-02-16 04:46:15.000-0600 I fixed it.. Its a timing issue. The channel variables sometimes get destroed before mixmonitor gets a chance to build its post_process string. Thats the reason why it works when debug is on. It gets junt enough time to to finish its while loops and build the string. Since all channel variables are the same at the begining of the recording and the end we can move the post_process string build to above the first while loop. Please see attached patch. By: BJ Weschke (bweschke) 2006-02-16 05:44:07.000-0600 reformed: That's a good idea. Do you have a disclaimer on file? By: reformed (reformed) 2006-02-16 05:50:34.000-0600 No i dont. I didnt add any code, just moved an if() block. I didnt think that moving 5 lines of code would warrant a disclaimer :) By: BJ Weschke (bweschke) 2006-02-16 05:53:28.000-0600 reformed: this is always a little grey area. Technically, I don't think this warrants a disclaimer either. Can you at least note in this bug that you disclaim rights to this patch so I can commit it and get you some karma? :) If you're going to be putting in patches in the future, it'd probably save everyone some trouble to put a disclaimer on file. BJ By: reformed (reformed) 2006-02-16 06:05:29.000-0600 Boris Bakchiev (reformed) hereby disclaims all copyright interest in the changes and enhancements made by Boris Bakchiev to the program "asterisk" (the "Program"). Boris Bakchiev affirms that it has no other intellectual property interest that would undermine this release, or the use of the Program, and will do nothing to undermine it in the future. Boris Bakchiev , 02/17/2006 Authorized Signature Date I will send an official fax to digium our Monday morning. Thank You By: reformed (reformed) 2006-02-23 19:08:37.000-0600 Just faxed the disclaimer to Digium. By: reformed (reformed) 2006-03-03 22:45:24.000-0600 Too bad this fix didnt make it to 1.2.5 :) By: BJ Weschke (bweschke) 2006-03-04 05:54:15.000-0600 Commited to 1.2 and /trunk. Thanks! By: Digium Subversion (svnbot) 2008-01-15 17:11:32.000-0600 Repository: asterisk Revision: 11778 U branches/1.2/apps/app_mixmonitor.c ------------------------------------------------------------------------ r11778 | bweschke | 2008-01-15 17:11:32 -0600 (Tue, 15 Jan 2008) | 3 lines Substitute variables in the post_process string (if it exists) before those variables could possibly disappear (channel hangup) ASTERISK-6287 ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=11778 By: Digium Subversion (svnbot) 2008-01-15 17:11:33.000-0600 Repository: asterisk Revision: 11779 _U trunk/ U trunk/apps/app_mixmonitor.c ------------------------------------------------------------------------ r11779 | bweschke | 2008-01-15 17:11:33 -0600 (Tue, 15 Jan 2008) | 11 lines Merged revisions 11778 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r11778 | bweschke | 2006-03-04 06:45:37 -0500 (Sat, 04 Mar 2006) | 3 lines Substitute variables in the post_process string (if it exists) before those variables could possibly disappear (channel hangup) ASTERISK-6287 ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=11779 |