[Asterisk-Users] Monitor application temporary hack
John Brown
jmbrown at chagresventures.com
Mon Aug 18 08:25:33 MST 2003
So how does one emit the legally required ( in some locales)
10 to 30 sec soft beep, letting people know they are being recorded ??
very cool trick using the end point as the anchor for mixing
the sounds :)
:wq
On Sun, Aug 17, 2003 at 10:48:25PM -0700, John Todd wrote:
> [apologies for no line wrap; config lines at bottom]
>
> I have mentioned on several threads here that the Monitor application doesn't do exactly what one would expect: the originating and answering legs of a call are unsynchronized by the duration of the interval that it takes for the answering leg to pick up the phone. This can be very distracting in a final mixed version of the file.
>
> Brian West (brian at bkw.org) came up with a clever solution to this. Since we know the ENDING times to both channel recording files, if we started the final mixing process and worked from the rear of the file forward, we'd have a (usually) synchronized conversation that could be distilled into a single file. So, he suggested that the "reverse" feature of sox be run against each channel file, then the file gets mixed, and then the single output file was reversed again.
>
> I am happy to say this trick appears to work like a charm. I've enclosed snippets of my config files that reference Monitor below, including the reversal application. I've added some comments so that this can be made mostly portable.
>
> Note: I use "soxmix" to mix the channels, which is a part of more recent versions of sox. "wxmix" will also work if you're storing things as inefficient .wav files.
>
> Note2: From my testing, it seems that 1 minute of two-leg gsm soundfile equals almost exactly 100k of diskspace.
>
> Note3: DTMF, unless you are using in-band, of course is not recorded.
>
> Note4: Recording volume is a little quiet; you may need headphones to hear things well. You may twiddle with some of the features in sox to change this.
>
> JT
>
>
> ; -- start --
>
> [globals]
> ; These variables are to avoid the irritating problem
> ; with inability to use regexp's on strings that have
> ; not been defined.
> ;
> ; These are used in [macro-record-on] and
> ; in [macro-record-cleanup]
> ;
> CALLFILENAME=foo
> FOO=foo
>
>
>
> [macro-record-on]
> ;
> ; This routine is called as a macro before a "Dial" statement, in order
> ; to record a call into a set of files. It is used hand-in-hand with
> ; the "macro-record-cleanup" routine.
> ; I use an AGI to get the base filenames, which are created using the
> ; date in form YYYYMMDD-HHMMSS which is then added to the ${EXTEN} and
> ; ${CALLERIDNUM} strings to form the complete filename.
> ;
> ; Call this routine with Macro(record-on,${EXTEN},${CALLERIDNUM})
> ;
> ; 2003-06-15 This macro has limited usefulness. Currently, there is
> ; no synchronization between channels, and the second channel starts
> ; recording on "answer" received. In other words, there is a gap of
> ; N seconds between the voice of the caller and the voice of the
> ; called party where N is the number of seconds it took to answer
> ; the phone. Packet loss will further corrupt timing between the
> ; two channels. Mahmut and Mark have discussed possible solutions,
> ; but no pending patch yet. See the hack in the record-cleanup macro
> ; that handles things for the time being by mixing files starting
> ; from rear to front.
> ;
> ;
> ; Note that I set CALLERIDNUM=foo up in my [globals] section, due
> ; to the inability of Asterisk to compare against the null case.
> ; Long story, but you really should have that variable set up in
> ; [globals] if you use this.
> ;
> ; Note: Legality of call recording varies by nation and state. Consult
> ; a very good lawyer before turning this on, or preface all your in/out
> ; calls with 'This call may be recorded.' to give yourself some minimal
> ; grounds to stand on (though that may not be enough.) It is almost
> ; certainly illegal in any US state to record a party without their
> ; knowledge, and may even be a federal crime.
> ;
> ; GSM files, after mixing 2 channels into 1, equate to about 100kb for
> ; every 1 minute of spoken conversation.
> ;
> ; Contents of the file /var/lib/asterisk/agi-bin/set-timestamp.agi:
> ;
> ; #!/bin/sh
> ; longtime=`/bin/date +%Y%m%d-%H%M%S`
> ; echo SET VARIABLE timestamp $longtime
> ;
> ; I could just use the built in ${DATETIME} to create a timestamp,
> ; but I really hate the date format used (DDMMYYYY) since it is
> ; silly. (least specific to most specific, left to right is the
> ; best way to create timestamps, IMHO)
> ;
> exten => s,1,AGI(set-timestamp.agi)
> exten => s,2,SetVar(CALLFILENAME=${timestamp}-${ARG2}-${ARG1})
> exten => s,3,Monitor(gsm,${CALLFILENAME})
>
> [macro-record-cleanup]
> ;
> ;
> ; If we have recorded a call, it is to our advantage to change the
> ; format of the call from a two-file system (blah-in.gsm blah-out.gsm)
> ; into a single file that contains both legs of the call, and then
> ; compress the call into some reasonably small filesize using gsm
> ; compression. This routine should be called out of the "h" priority
> ; in a context. If the call was not recorded, this macro will
> ; not cause any harm, so calling it on each hangup isn't a problem.
> ;
> ;
> ; First, did we record this call? If ${CALLFILENAME} is equal to
> ; the variable ${FOO} (remember, we set them to be equal to "foo"
> ; up in the [globals] section) then we can be fairly certain that
> ; this call wasn't recorded, so just jump to the end of this macro
> ; and return out of routine. Otherwise, post-process the sound
> ; files into something more space efficient (one gsm file)
> ;
> exten => s,1,GotoIf($[${CALLFILENAME} = ${FOO}]?11:2)
> exten => s,2,SetVar(MONITORDIR=/var/spool/asterisk/monitor)
> ;
> ;
> ; The problem with Monitor is that the second leg of the call doesn't have
> ; recording start until the call answers. This leaves a variably-timed
> ; gap between the start of the recording for the originating leg, and
> ; the start of the recording for the answering leg. However, both legs
> ; end at the same time, so if we mix BACKWARDS, we can get them sync'ed
> ; up to some reasonable degree. Note that IP packet loss may cause
> ; some un-synced intervals to start to build up over time, so this
> ; is not a perfect method. However, until this unusual "feature" of
> ; Monitor is repaired or reprogrammed, this will have to suffice.
> ;
> ; Thanks to Brian West (brian at bkw.org) for the really clever idea of
> ; reversing the two files, mixing them, and then reversing again. 2003-08-15
> ;
> ; SECURITY HAZARD: Someone particularly clever might be able to pass
> ; variables and commands to your system if they are able to manipulate
> ; the data in the CALLERID field or DNIS field. This is especially
> ; possible with SIP calls, where end devices may be in the hands of
> ; unfriendly callers.
> ;
> ; Call "sox" and reverse the in channel and the out channel soundfiles...
> exten => s,3,System(/usr/local/bin/sox ${MONITORDIR}/${CALLFILENAME}-in.gsm ${MONITORDIR}/${CALLFILENAME}-in-rev.gsm reverse)
> exten => s,4,System(/usr/local/bin/sox ${MONITORDIR}/${CALLFILENAME}-out.gsm ${MONITORDIR}/${CALLFILENAME}-out-rev.gsm reverse)
> ;
> ; Delete the old files; we don't need them anymore
> exten => s,5,System(/bin/rm ${MONITORDIR}/${CALLFILENAME}-in.gsm ${MONITORDIR}/${CALLFILENAME}-out.gsm)
> ;
> ; This part of the routine mixes the in and out .gsm files into one .gsm, and then
> ; cleans up the original files (removes them)
> ;
> ; Turn the two in/out .gsm files into a single .gsm file with both channels
> ; Make sure you're using sox-12.17.4 or greater (includes "soxmix")
> exten => s,6,System(/usr/local/bin/soxmix ${MONITORDIR}/${CALLFILENAME}-in-rev.gsm ${MONITORDIR}/${CALLFILENAME}-out-rev.gsm ${MONITORDIR}/${CALLFILENAME}-rev.gsm)
> ;
> ; Remove the old .gsm files - we don't need them anymore.
> exten => s,7,System(/bin/rm ${MONITORDIR}/${CALLFILENAME}-in-rev.gsm ${MONITORDIR}/${CALLFILENAME}-out-rev.gsm)
> ;
> ; Now, reverse the final mixed file and store the finished product.
> exten => s,8,System(/usr/local/bin/sox ${MONITORDIR}/${CALLFILENAME}-rev.gsm ${MONITORDIR}/${CALLFILENAME}.gsm reverse)
> ;
> ; So, the final file has been created, we can delete the temporary reverse file; we're done
> exten => s,9,System(/bin/rm ${MONITORDIR}/${CALLFILENAME}-rev.gsm)
> ;
> ; End of routine, return to calling point (note: NoOp required for GotoIf
> ; called from priority 2)
> exten => s,10,NoOp
> ;
> ; This line in here to see if I can prevent the double-ring issue 2003-05-02
> ; It may not be necessary.
> exten => s,11,Hangup
>
>
>
>
> [from-sip]
> ; Now, let's give a quick example of how to use those call recording macros.
> ;
> ; Let's say all my inbound calls from SIP peers end up in the context [from-sip]
> ; so I turn on the recording here, and then pass the call off to the "real"
> ; context which handles those calls.
> ;
> exten => _.,1,Macro(record-on,${EXTEN},${CALLERIDNUM})
> exten => _.,2,Answer
> exten => _.,3,Wait(2)
> exten => _.,4,Playback(this-call-is-being-recorded)
> exten => _.,5,Goto(from-sip-post,${EXTEN},1)
>
> [from-sip-post]
> ; Now, send the call to where it's really supposed to go, while recording.
> ;
> exten => 1234,1,Dial(SIP/1234,40,r)
> exten => 1234,2,Busy
> exten => 1234,102,Voicemail2(b1234)
>
> exten => 5554,1,Dial(SIP/5554,40,r)
> exten => 5554,2,Busy
> exten => 5554,102,Voicemail2(b5554)
>
> ; after the call is over, make sure to clean up the files and translate them
> ; appropriately...
> exten => h,1,Macro(record-cleanup)
>
>
> ; --end--
>
>
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
More information about the asterisk-users
mailing list