Page 1 of 1
vicidial Recording into other server/share drive
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Thu Dec 30, 2010 6:58 pm
by gurugee1
Hi,
I want to record my all recorded calls in separate server instead of /var/spool/asterisk/monitorDone/ORIG.
Can I make changes in /etc/astguiclient.conf file.
# Paths used by astGUIclient
PATHmonitor => /var/spool/asterisk/monitor
PATHDONEmonitor => /var/spool/asterisk/monitorDONE
into
PATHmonitor =>
http://10.128.210.22/recordings
PATHDONEmonitor =>
http://10.128.210.22/records
both servers (vicidial and recording) are on same LAN.
Please advise, bcz I planned to seperate my database. so I think its better to save the recordings also into another server.
please help
thank you
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Thu Dec 30, 2010 9:20 pm
by williamconley
read the manual regarding the ftp transfer to the archive server.
this is what it was designed to do.
when it initially "mixes" and stores the recordings locally (a couple minutes after the call ends), they will become available on the vicidial server, and be linked to the lead record (clickable in the web interface for listening).
when the ftp transfer script runs (a few minutes later OR once a day, however you set it up) the link will be modified to link to the new location automatically
![Smile :)](./images/smilies/icon_smile.gif)
so the recordings will always be accessible before and after the ftp transfer, completely transparent to the user, after you set up ftp transfer.
of course you HAVE read the manual, right? (free on eflo.net, but i highly recommend the paid version, it is very helpful if you have paycheck riding on this equipment, commit it all to memory and you will increase your capabilities a great deal!)
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Sun Jan 02, 2011 3:37 am
by gurugee1
Thank you very much for your help.
I just need few hints to fix the issues, I do not have the full document.
I think I should point it to my ftp server, and change the paprameters accordingly. right ?
# FTP recording archive connection information
VARFTP_host => 10.128.211.25
VARFTP_user => cron
VARFTP_pass => test
VARFTP_port => 21
VARFTP_dir => RECORDINGS
VARHTTP_path => 10.128.211.25
By doing this, Can I save my system resources in terms of cpu usage during calls or it will be increase bcz now the server is transfering the files to other server, but both servers are on LAN.
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Sun Jan 02, 2011 10:16 am
by williamconley
This is not a method to reduce system resource usage. The only ways to reduce system resource usage is to use the system less (stop recording? make less calls?) or add another server to the system with Vicidial installed (making this a vicidial Cluster instead of a single vicidial server).
The easiest method to Cluster Vicidial is to add a MySQL server.
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Wed Apr 06, 2011 8:41 pm
by dspaan
Hey guys, i need your help to setup ftp transfer or recordings to another server. I posted in this thread because it is similar.
I uncommented this line in crontab by removing the # symbol:
2,5,8,11,14,17,20,23,26,29,32,35,38,41,44,47,50,53,56,59 * * * * /usr/share/astguiclient/AST_CRON_audio_3_ftp.pl --MP3
I edited asguiclient.conf and changed this to my ftp server:
# FTP recording archive connection information
VARFTP_host => 192.168.1.180
VARFTP_user => *****
VARFTP_pass => *****
VARFTP_port => 99
VARFTP_dir => RECORDINGS
VARHTTP_path =>
http://192.168.1.180
I also changed 'Alternate Recording Server IP' in the Administration>Servers web interface to 192.168.1.180
I rebooted the server and made a few test calls. I don't see any recordings being FTP'ed to my server and when i go to my agent stats i still see the old IP adress in the path of the recordings URL (and when i click the link it downloads the recorded mp3 file). Even after 10 minutes it's still the same.
Where did i go wrong?
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Wed Apr 06, 2011 9:02 pm
by williamconley
- Code: Select all
perl /usr/share/astguiclient/AST_CRON_audio_3_ftp.pl --MP3
and find out
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Wed Apr 06, 2011 9:33 pm
by dspaan
Now why didn't i think of that?
When i do that i get this:
mv: cannot stat `/var/spool/asterisk/monitorDONE/MP3/MISDAAD_leysner01_20110324-114920_0115691899-all.mp3': No such file or directory
mv: cannot stat `/var/spool/asterisk/monitorDONE/MP3/PICCOKOU_chotoe01_20110405-130440_0226312408-all.mp3': No such file or directory
mv: cannot stat `/var/spool/asterisk/monitorDONE/MP3/PICCOLO_vera01_20110114-125543_0735480655-all.mp3': No such file or directory
mv: cannot stat `/var/spool/asterisk/monitorDONE/MP3/MISDAAD_vera01_20110317-083531_0135341000-all.mp3': No such file or directory
over and over again
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Thu Apr 07, 2011 12:28 am
by DhwaniTechnologies
Make sure you can FTP into your FTP server before you expect the Vicidial scripts to work. Also, make sure the permissions you set on your FTP server allow the FTP user to write files to the directory.
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Thu Apr 07, 2011 1:48 pm
by williamconley
since the FTP script first checks for the contents of those directories and then begins to transfer the files ... why does it believe those files are there and begin to try to transfer them? Are they there?
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Thu Apr 07, 2011 8:00 pm
by dspaan
Dhwani was right i was not even able to connect to my FTP server. I made two different FTP servers on a windows server with different ports (one server on port 21 and the other on port 99), i thought that would work but obviously not....
I made a new FTP server now on another machine and i can FTP fine to it. I tested by making a few calls and my recordings were succesfully transfered to the FTP server by the ViciDial script.
Some remaining problems:
1.When i go to my User Stats section i can see the link to the recordings like this:
http://192.168.1.150/2011-04-07/T-PICCO ... 20-all.mp3
That is indeed the FTP server (ViciDial is 192.168.1.201) but when i click the link the recording can't be downloaded. Do i need to configure my FTP server as a web server as well to do that?
2.I noticed the recordings made today and all the days before still have the wrong IP adress (from the FTP server i created yesterday that didn't work) in their URL in the User Stats report. Does ViciDial run a nightly process to change all the URL's or something?
3.When i check my ViciDial server with WinSCP i can see all the recordings now are in /var/spool/asterisk/monitorDONE/FTP/.
I tried running the script manually again this time and it did not give any errors but the files are still sitting there in that FTP dir. Is there a nightly process that will move them? I checked the description in AST_CRON_audio_3_ftp.pl and there it says it runs the script every 3 minutes which i can also see with crontab -l.
Do i need to edit these values in AST_CRON_audio_3_ftp.pl as well?:
# Default variables for FTP
$VARFTP_host = '10.0.0.4';
$VARFTP_user = 'cron';
$VARFTP_pass = 'test';
$VARFTP_port = '21';
$VARFTP_dir = 'RECORDINGS';
$VARHTTP_path = 'http://10.0.0.4';
This is what my astguiclient.conf looks like:
# FTP recording archive connection information
VARFTP_host => 192.168.1.150
VARFTP_user => *****
VARFTP_pass => *****
VARFTP_port => 21
VARFTP_dir => RECORDINGS
VARHTTP_path =>
http://192.168.1.150
4.What do VARFTP_dir and VARHTTP_path do? I noticed when i made the recordings on the ViciDial server itself it just dumped all the recordings in /var/spool/asterisk/monitorDONE/MP3/ but now on my FTP server it makes folders with the date of the recording which can also be seen in the recording URL's. What should be the correct values for these two parameters in my case? Does the VARFTP_dir need to be the same as my FTP server directory?
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Thu Apr 07, 2011 8:20 pm
by williamconley
Have you read the manual and docs folder regarding these items? (usr/src/astguiclient/VERSION/docs ...?)
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Thu Apr 07, 2011 8:48 pm
by dspaan
Thanks for that directory tip Bill, i never knew about that, lots of information in there!
Only i could not find any info about the FTP archival process in there, can you tell me which specific document in there i should look at?
Of course i checked the manual, but could not find any info about the FTP process either. Found some clues on the forum but i'm still stuck with questions 2,3 and 4. I did change my FTP location into a webserver so now i can open the recordings with the URL's in the User Stats report. Only for some reason my chrome browser now opens them in the browser instead of downloading them. Don't understand why that is happening.
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Thu Apr 07, 2011 9:07 pm
by williamconley
not really designed for chrome. i have never actually read any directions for the FTP, just assumed they would be in there "with everything else". Played with it until it worked.
you should NOT change default values for the FTP inside the scripts, set them in the astguiclient.conf (there are two sep sets: one for recordings and one for "backup"/"reporting", set them both and get those backups running!!)
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Thu Apr 07, 2011 9:14 pm
by dspaan
I didn't change the scripts, only astguiclient.conf.
Do you have any idea how the changing of the URL's works? Don't understand why i still see the address of that old FTP server in all the previous made calls.
Also don't understand why all the previous made recordings are still sitting in that FTP directory.
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Thu Apr 07, 2011 9:17 pm
by williamconley
there is no mechanism for "changing the ip of the server" modifying previous recordings. multiple IP addresses usually just means multiple servers.
if you search this forum a bit you'll find a query that will allow changing the IP from old to new ... and that should break the dam.
when the update server ip script runs, it does not modify this field. so the recordings honestly believe they belong to that server. since there is no server with that IP address ... there's no way to access or alter them. they just sit there.
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Fri Apr 08, 2011 4:26 am
by mflorell
There IS a process for updating the URL of a recording in the database:
ADMIN_update_archive_url.pl
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Fri Apr 08, 2011 10:01 am
by williamconley
and now i remember it, too. from a couple months back. thanks matt
![Cool 8)](./images/smilies/icon_cool.gif)
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Fri Apr 08, 2011 10:59 am
by dspaan
Could it be that some process has run this script? Because somehow all my old recordings are pointing to the archive server i had created but were the recordings are not located.
Anyway how do i run this script?
Old URL =
http://192.168.1.180/DATE/
NEW URL =
http://192.168.1.150/ (without the date)
What should my statement look like? I tried this:
vicibox:/usr/share/astguiclient # perl ADMIN_update_archive_url.pl
http://192.168.1.180/ http://192.168.1.150/ADMIN_update_archive_url.pl - updates the url in the recording_log
command-line options:
[--debug] = shows the sql as it is being executed.
[--test] = activates debuging and does not actually
execute the updates.
[--old-server-url] = the old url used to access the recordings.
This is a required argument.
[--new-server-url] = the new url used to access the recordings.
This is a required argument.
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Fri Apr 08, 2011 1:53 pm
by williamconley
"old recordings are pointing to" ... are you referrring to the URL in the admin.php page or the values in the databaase?
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Fri Apr 08, 2011 2:12 pm
by dspaan
I'm referring to admin.php page. When you go to Reports>User Stats>user>bottom of the page:Recordings for user and then the URL's you see on the right.
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Fri Apr 08, 2011 2:14 pm
by williamconley
compare those to the values in the database. then compare them to the actual recording name's and locations. list ALL and we'll figure out what you're talkin' about. I'm moving too fast today. LOL
remember that "Admin->Servers" has the ability, under the right circumstances, to alter what the admin.php page will show (changing it from the database value before displaying it).
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Sun Apr 10, 2011 3:17 pm
by dspaan
ok in vicidial user stats it displays:
In phpmyadmin in the recording_log table i see:
In Admin>Servers i have set:
By now i have moved the recordings which were sitting in the /var/spool/asterisk/monitorDONE/FTP/ folder manually to the 192.168.1.150 machine.
edit: Weird thing is that some of the url's point to the failed FTP server i tried to setup and some seem to be succesfully altered by the admin>servers setting:
![Image](http://img228.imageshack.us/img228/9469/recordingsdiff.jpg)
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Sun Apr 10, 2011 8:35 pm
by williamconley
I would, FIRST, get a fresh recording to follow the Proper Path and land where it belongs with the standard setup. Once you have that done ... you can mimic the process manually for any old files.
So create a recording, allow the FTP to move it where it belongs, moving the file, changing the database entry, naming the file correctly ... THEN worry about the old recordings and how/where to move them.
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Mon Apr 11, 2011 5:36 am
by dspaan
I already did that, when i make a new recording it gets this URL:
http://192.168.1.150/RECORDINGS//2011-0 ... 20-all.mp3
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Mon Apr 11, 2011 5:44 am
by williamconley
Ok. Is that ... good? Correct? Proper path? Right names?
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Mon Apr 11, 2011 7:51 am
by dspaan
I just tested again and it works when i removed RECORDINGS from the URL like this:
http://192.168.1.150/2011-04-07/T-PICCO ... 20-all.mp3
I can open this fine. So i guess i should remove VARFTP_dir from astguiclient.conf?:
# FTP recording archive connection information
VARFTP_host => 192.168.1.150
VARFTP_user => *****
VARFTP_pass => *****
VARFTP_port => 21
VARFTP_dir => RECORDINGS
VARHTTP_path =>
http://192.168.1.150
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Mon Apr 11, 2011 8:14 am
by williamconley
just blank it out, i'm not sure if you'll need to '' or "" or / or actual blank.
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Mon Apr 11, 2011 8:22 am
by dspaan
Never mind about that astgui.conf setup it works fine, i gave you an URL from friday. I just made another testcall and it provides me this:
http://192.168.1.150/2011-04-11/T-PICCO ... 20-all.mp3
And i can open that fine.
Now back to the remaining problem. How can i correct the existing URL's in the system?
dspaan wrote:Anyway how do i run this script?
OLD AND EXISTING URL =
http://192.168.1.180/DATE/NEW NEEDED URL =
http://192.168.1.150/ (without the date)
What should my statement look like? I tried this:
vicibox:/usr/share/astguiclient # perl ADMIN_update_archive_url.pl
http://192.168.1.180/ http://192.168.1.150/ADMIN_update_archive_url.pl - updates the url in the recording_log
command-line options:
[--debug] = shows the sql as it is being executed.
[--test] = activates debuging and does not actually
execute the updates.
[--old-server-url] = the old url used to access the recordings.
This is a required argument.
[--new-server-url] = the new url used to access the recordings.
This is a required argument.
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Mon Apr 11, 2011 8:29 am
by williamconley
i tried this trick once and it worked like a charm:
put the files (obviously test with one or two and then a group first!) BACK in monitorDONE.
you may need to modify the sql data first to match the correct server ... but you may not.
![Smile :)](./images/smilies/icon_smile.gif)
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Thu Apr 14, 2011 7:16 am
by dspaan
Thanks Bill, that worked like a charm
I moved the recordings back to monitorDONE\MP3 and now it has been moved back to my FTP server in a date folder and the URL in admin.php has been updated!
I'm so happy
![Razz :P](./images/smilies/icon_razz.gif)
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Thu Apr 14, 2011 9:56 am
by williamconley
there are a lot of toys in vicidial.
![Cool 8)](./images/smilies/icon_cool.gif)
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Wed Nov 30, 2011 8:16 pm
by actiondave
williamconley wrote:read the manual regarding the ftp transfer to the archive server.
this is what it was designed to do.
when it initially "mixes" and stores the recordings locally (a couple minutes after the call ends), they will become available on the vicidial server, and be linked to the lead record (clickable in the web interface for listening).
when the ftp transfer script runs (a few minutes later OR once a day, however you set it up) the link will be modified to link to the new location automatically
![Smile :)](./images/smilies/icon_smile.gif)
so the recordings will always be accessible before and after the ftp transfer, completely transparent to the user, after you set up ftp transfer.
of course you HAVE read the manual, right? (free on eflo.net, but i highly recommend the paid version, it is very helpful if you have paycheck riding on this equipment, commit it all to memory and you will increase your capabilities a great deal!)
I purchased vicidial manager manual for ViciDial release 2.2.1 months ago and have read through it and continue to look at varioius pages but do not see anything regarding this process.
Can anyone point me to the area of this manual this is discussed?
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Wed Nov 30, 2011 8:35 pm
by williamconley
I don't actually read the manual any more.
but i do know that Vicibox's new installation system includes an archive server (and it works, i've used it).
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Wed Nov 30, 2011 8:50 pm
by actiondave
Thanks William.
If I add an archive server, what will actually be archived and does it automatically archive at a certain time and can this be adjusted?
![Post Post](./styles/vicidial/imageset/icon_post_target.gif)
Posted:
Wed Nov 30, 2011 11:12 pm
by williamconley
the items to be archived are basically in three groups.
1) it is possible to replicate the database. I'm not even going to attempt to discuss that here. but it needed mentioning.
2) recordings
3) backups
Recordings are pushed to the archive server via the ftp script in crontab -e. You'll need to check that script for its functionality. It is disabled by default. execute it with --help for options.
Backups require the addition of the admin backup perl script to the same crontab -e setup (duplicating the other crontab -e setup is good). Execute it with --help as well.
The credentials are in the /etc/astguiclient.conf file for each. Be sure they run successfully from the command line, and do not ever ASSUME they are working. CHECK.
Be sure files are arriving at the destination as expected.
Be sure your backup file has the expected content (unzip/untar/uncompress all the files and be sure they are in there ... be sure the database file actually has a viable database in it ... I even go so far as to be sure the last lead entered into the system is in the backed up database by restoring it to a junk server and looking). Remember that a non-tested backup is a bad day waitin to happen.