Depends. I don't recall any requirement for any beeps. Just a disclaimer
that their call may be recorded. In Oklahoma state you don't have to let
the other party know. Single party state. How great is that! :P
Or you can use a ghetto beep.. just press a button on the phone every now
and then! :P
bkw
PS: The worse that can happen is it can't be used in court.
On Mon, 18 Aug 2003, John Brown wrote:
> 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
>
_______________________________________________
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
