vicidial.org

How can I force recording on manual dial when using route initiated recording..


I am using route initiated recording because some remote web agents sometimes have connectivity problems and 1 in ever hundred recording is missing. Now the issue was the one we missed every now and then is a sale.

So we switched to route initiated recording. This meant none of the recordings from the auto dialing were missing. GREAT...

BUT wait, now manual dials are not being recorded at all as route initiated recording doesn't support it.

How can we have forced recordings from the server side to force recording for auto dialing and manual dialing on the same campaign

There is currently no option to do that outside of the agent screen, since with manual dial the call is initiated within the agent screen.

Matt, I like how you checked the forum and replied to all 6 unanswered Support questions one after another over the course of a few hours. I guess you had to get some work done in between)))

Nice.

JM

We're actually doing our 3-day training session here in Florida right now, so we're extra busy right now

As for this specific topic, we are looking into options to streamline this process, because it is a frequent problem for our stable-network-challenged clients.

Yes I agree, it's very important. Are you saying that if your network is stable, setting Campaign Recording to ALLFORCE and selecting No on Routing Initiated Recording will record all calls, auto dial and manual?

So if you want auto and manual calls recorded don't use Routing Initiated Recording. It depends on how many manual calls you make. In my business, our call backs are where we close some sales, so it's important to record manual calls.

John

The Routing Initiate Recordings setting currently has no effect at all on Agent Manual Dial calls.

What we are looking into is some way to streamline the agent manual dial process to include starting recordings.

Both of those features only seem to be necessary because of clients with unstable or unreliable networks. We have many clients with no missing recordings that don't use Routing Initiated Recordings.

The issue, is that we have remote agents that is why we miss the recordings.

I just added Manual-Dial-compatible Routing Initiated Recordings, you must enable setting at the campaign level and have a 0 recording delay. Please upgrade to the newest svn/trunk revision and try it out!

Any particular reason for 0 recording delay?

What if the recording delay was always 0 for Manual-Dials of routing initiated recordings?
And for autodial the recording delay was picked up from the recording delay settings for routing initiated recordings?

Because 100k-200k recordings a day start to slow down the ftp directory...Adding a recording delay of 12 seconds for us brings that number down to just 10k-20k. Having these route initiated.
So if recording = route initiated & manual-dial then recording delay = 0; sort of condition would allow for a variable recording delay maybe...

But again, thank you as usual. I will upgrade to the latest svn/trunk revision and try this out on tomorrow's shift.

The problem that Routing Initiated Records solves is mostly for companies that have network problems that cause recordings to be started too late or not at all, so the 0 delay requirement makes sense. Also, the routing process is complete when the call goes to the agent, so you can't do routing initiated recording on a delay anyway.

Hi,

I just did an svn up on /trunk and I see revision 2992 and I noticed there are only about 25 new files. Are these files the only ones that will be updated when you run the upgrade? I'm just wondering what files I need to be prepared to restore from a backup. For example i dont see the file dispo_send_email.php will it not be overwritten with this revision?

And one other thing, in upgrading revision does the database schema always change with a new revision, so that you must always run the mysql upgrade script?

Thanks
John M

Normal upgrade overwrites ALL files. So back up everything. There's a backup script in /usr/share/astguiclient, it backs up everything needed except client audio recordings. It does have options for which types of files to include in the backups set (like VM, Web, DB ...)

Any files you've edited will lose their edits.

Thanks William. And does the db schema upgrade with each revision upgrade?

John

Thanks, works great. no more missing recordings so far.

thephaseusa wrote:Thanks William. And does the db schema upgrade with each revision upgrade?

John

Each upgrade is unique. Many upgrade DB, many upgrade scripts, many upgrade both.

You can check the last line of the db upgrade script to see if the new one has any extra entries which would require running those new entries. It's not actually necessary to run the whole file, we just run the new files since present version when we upgrade a system. Very rare to have a conflict. Those that do are usually during an upgrade from a Very Very old revision.

Okay thanks. I think I'm clear on that now.

Version: 2.14b0.5
SVN Version: 2975
DB Schema Version: 1543
DB Schema Update Date: 2018-05-04 16:24:39

That's where my database server is now. Looking at the new upgrade script, there are new schemas 1544,1545,1546,1547, and 1548 with the update schema statement coming at the end of each new schema group of commands. So I could just start with 1544, copy everything below it, paste to create a new upgrade script, run it, and skip the stuff before my current schema. Then run perl /usr/src/astguiclient/trunk/install.pl on each box in the cluster, and upgrade finished.
Correct?

John Merritt

Valid summary. We usually copy the upgrade script and delete everything above what we want (copy/paste could alter line breaks ... it's prone to inexact copying, but deleting lines without altering the lines we want is much safer).

When you run perl install.pl, be sure to include the copy sample conf option at the CLI (use --help if unsure). This way if there are any changes to the configuration files required to support any new code ... you don't miss them. This does require that ANY changes to stock .conf files be redone after any upgrade. This is why we don't change any of the stock files with the sole exception of the externip value in sip.conf.

Thanks for the extra details.

JM