Call Monitor Recordings?

[kmcdaniel]

Why wouldn't there be an option to save all call recordings as an mp3 file? Anyone know why it must be WAV?

 

[Samot]

Why wouldn't there be an option to save all call recordings as an mp3 file? Anyone know why it must be WAV?

Because there currently isnt support in Asterisk to record in mp3 format.

 

[kmcdaniel]

Anyone have experience saving recordings off the system to another destination, either by changing the path or using a cronjob to cp/mv the files elsewhere for easy playback if needed? What's a good option out there for those that may have done this? Looking to save 2-3 years of recordings, but would like an average user to be able to go back, browse and playback those call recordings if need be.

 

[dicko]

Easiest way is to bindmount a network share, nfs or sshfs over /var/spool/asterisk/recordings, if you do that, look at the cache recordings in

Asterisk Main Configuration File - Asterisk Documentation

docs.asterisk.org

to handle stale nfs mounts or network stutters

 

[Halea]

Anyone have experience saving recordings off the system to another destination, either by changing the path or using a cronjob to cp/mv the files elsewhere for easy playback if needed? What's a good option out there for those that may have done this? Looking to save 2-3 years of recordings, but would like an average user to be able to go back, browse and playback those call recordings if need be.

Our corporate policy requires that all calls are recorded. On top of that we run multiple country specific PBXs. Thus we generate a large number of records every day.

We do two things on these PBXs:

First, using basic symbolic links we redirect the recordings (directory) to a separate disk volume on the same hardware/virtual machine. The volume is mounted through fstab at boot time. That gives us seamless access through the FreePBX CDR window or integrated capabilities. Asterisk & FreePBX don't even know that the location of the recordings has been changed.

Second, we use a home grown bash script to periodically (twice a day batch mode) copy those records into a remote centralized server. We keep the wav audio files as is (legal requirement for us), but we change the file name to a different structure with more useful information so that the raw collection of files is more easily searchable with common Linux search tools. At the same time we create indices in a sql database for other processing requirements.

Hope this helps to validate your thoughts about your next step.

 

[Samot]

The good news is, support for recording in mp3 is being worked on right now. Support for mp3 playback already exists.

It will be ported in 18, 20 and 21 when completed.

 

[dicko]

If you have Mac, Windows and Linux systems, then the inability of all of them to commonly agree on the format by 'extension' of a file, plus of course it's 90% compression, first motivated the conversion of WAV/wav to mp3 but in the last 15 years or so .ogg evolved which is natively recognized by all, has equal or better compression and sounds marginally better than mp3,

 

[kmcdaniel]

Our corporate policy requires that all calls are recorded. On top of that we run multiple country specific PBXs. Thus we generate a large number of records every day.

We do two things on these PBXs:

First, using basic symbolic links we redirect the recordings (directory) to a separate disk volume on the same hardware/virtual machine. The volume is mounted through fstab at boot time. That gives us seamless access through the FreePBX CDR window or integrated capabilities. Asterisk & FreePBX don't even know that the location of the recordings has been changed.

Second, we use a home grown bash script to periodically (twice a day batch mode) copy those records into a remote centralized server. We keep the wav audio files as is (legal requirement for us), but we change the file name to a different structure with more useful information so that the raw collection of files is more easily searchable with common Linux search tools. At the same time we create indices in a sql database for other processing requirements.

Hope this helps to validate your thoughts about your next step.

Are you using vultr for any of your vps? I would be interested to learn more about your separate disk volumes for vps.

 

[Halea]

Are you using vultr for any of your vps? I would be interested to learn more about your separate disk volumes for vps.

Nowadays, we run all our business on our own hardware that we hand pick and colocate in first tier data centers (on three continents, 6 countries). The machines are mostly high-end Dell or HP blades.
Long term storage on these serves consists of integrated RAID arrays, some based on HDD, some on old style SSDs.
Our highest performance servers, where we do real time data collection and processing, use NVME RAID arrays.

All data volumes including those for the PBXs are virtual volumes located on these underlying storage types.

For call recording we use 512GiB virtual volumes that we connect to the PBX VM as a secondary drive through basic fstab mapping and mounting. Once a volume is 95% full it gets disconnected and replaced with a blank one in live mode (while the PBX is fully operational). The process is extremely fast and entirely automated through scripts periodically run by cron jobs.
After a while the oldest volumes may be deleted if there is space shortage. As I explained in a previous post the calls are also permanently archived on remote storage (similar storage hardware placed in alternate data centers).

Our engineers do lots of experimental things on RackNerd, Vultr and the like, but when it's time to deploy operationally, the project goes to our own hardware, which is virtualized via Proxmox (KVM).

 

[kmcdaniel]

I would be curious on others thoughts on this plan.

Using Vultr for production PBX-2027. I will leave the default storage on the PBX for all call recordings as /var/spool/asterisk/monitor/

I plan to mount via SFTP a cloud based storage of 1TB for $8 per month. This should be plenty for 2 years of recordings. I will mount this drive at /mnt/recordings using curlftpfs and placing in /etc/fstab.

Then I will set a CRONJOB for every day at 9PM to mv the files from /var/spool/asterisk/monitor/ to /mnt/recordings - thus taking them from the Vultr server and placing them onto the 1TB cloud based storage.

I will then give the administrator of the office access to the cloud storage to download and pull recording files as needed.

See anything wrong with this plan?

 

[dicko]

I would be curious on others thoughts on this plan.

Using Vultr for production PBX-2027. I will leave the default storage on the PBX for all call recordings as /var/spool/asterisk/monitor/

I plan to mount via SFTP a cloud based storage of 1TB for $8 per month. This should be plenty for 2 years of recordings. I will mount this drive at /mnt/recordings using curlftpfs and placing in /etc/fstab.

Then I will set a CRONJOB for every day at 9PM to mv the files from /var/spool/asterisk/monitor/ to /mnt/recordings - thus taking them from the Vultr server and placing them onto the 1TB cloud based storage.

I will then give the administrator of the office access to the cloud storage to download and pull recording files as needed.

See anything wrong with this plan?

Just that it has up to one day latency and you lose the linkages in cdr and cel reports, you could buy storage from vultr ($6/month per TB and S3 or other shared access) and mount it on /var/spool/asterisk/monitor/, it will behave like a local partition so won't need caching.and no other management of crons or rsync needed

For external access later, I like to (in the post recording script) add other 'organizations' of the recordings with hard links to directory structures of "/extension/direction/areacode/localnumber/year-month-day" and "/areacode/localnumber/direction /extention/year-month-day/" and any other order that makes sense in the use case. An ideal place for satisfying into mp3 if you want, very little extra storage needed and landing pages which allows directories starting at /var/spool/asterisk/monitor/ is all you need later

 

[kmcdaniel]

Just that it has up to one day latency and you lose the linkages in cdr and cel reports, you could buy storage from vultr ($6/month per TB and S3 or other shared access) and mount it on /var/spool/asterisk/monitor/, it will behave like a local partition so won't need caching.and no other management of crons or rsync needed

For external access later, I like to (in the post recording script) add other 'organizations' of the recordings with hard links to directory structures of "/extension/direction/areacode/localnumber/year-month-day" and "/areacode/localnumber/direction /extention/year-month-day/" and any other order that makes sense in the use case. An ideal place for satisfying into mp3 if you want, very little extra storage needed and landing pages which allows directories starting at /var/spool/asterisk/monitor/ is all you need later

Can you provide more insight into your post recording script 'organizations' steps you take? TIA

 

[dicko]

Freepbx sorts calls purely chronically, in retrospect however managers might want to sort primarily by agent or client , the post recording script additionally operates on the builtin construction of cdr into year month day etc, but any asterisk channel or cdr variable can also be used as '^{VAR}', construct the logical path, call 'mkdir -p /cons/tructed/path to make sure it exists and then modify something like

[SOLVED] How To Email Call Recordings Post Call Recording Script

I have figured out how to successfully figured out how to email call recordings, and there wasn’t a guide so I wanted to make one for anyone else who is trying to email their call recordings. Here is my bash script for emailing out the call recording that includes who called, and the number...

community.freepbx.org

to hard link the file to its new 'sorted' position, repeat as necessary as each hardlink (inode) only adds 2k to storage (but only work in the same 'volume') also the file exits as long as there is one inode referenceing it