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 ([EMAIL PROTECTED]) 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 ([EMAIL PROTECTED]) 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
> [EMAIL PROTECTED]
> http://lists.digium.com/mailman/listinfo/asterisk-users
_______________________________________________
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
