New Mexico is also a single party state :)
The financial service providers have a requirement for
beeps on the line.
Some states (don't remember which, but will research again)
require that you have a beep on the line. That may have
changed since the last time I really had to deal with this.
On Mon, Aug 18, 2003 at 11:05:35AM -0500, Brian West wrote:
> 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
_______________________________________________
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
