AST_CRON_audio_2_compress ignores 'Recording Web Link' pref

[williamconley]

Mantis/Issue Tracker Link for the FIX: http://www.vicidial.org/VICIDIALmantis/view.php?id=440

Posted .diff file to resolve this little annoyance.

ST_CRON_audio_2_compress perl script ignores Server->Recording Web Link preference

To set the recording to appear on a URL accessible to managers, there is a preference for "Recording Web Link" to allow server_ip (default) or alt_ip or external_ip to be used.

This setting is not used by the AST_CRON_audio_2_compress script, it merely uses the $VARserver_ip astguiclient.conf setting.

Modified the system to piggyback the original mysql call (to get the recording filename) so it now also acquires the preference and other values. Then added a switch statement to set a new variable $recording_ip. Then modified the four "INSERT" statements to use the $recording_ip instead of the $server_ip. then tested on the client box.

Began with VERSION: 2.4-290, BUILD: 101127-2232 (client complaint of missing GSW files). Found there was a bug fixed in VERSION: 2.4-296 BUILD: 110111-1305, so upgraded the AST_CRON_audio_2_compress file to that version.

But then I found that preference/setting was being ignored so I fixed it and created a .diff file after testing the new file.

[mflorell]

That setting is for the web page links only, not the actual database link. It was never intended to alter the database value, only change the server that was linked from the admin.php and admin_modify_lead.php URLs.

[williamconley]

The admin.php results when viewing (for instance) a lead's recordings ... pull the link from the database. The database entry was placed there by this script. This script was ignoring the preference for "use the server_ip, the alt_ip or the external_ip" in the server settings.

This means that the manager tells the system that the recordings should use the "alt_ip" for the links (the stated purpose of that field), and then when the recordings are made ... they continue to use the "server_ip" instead. Which makes them of no value to those who cannot reach that IP address.

On the other hand ... it CAN be useful, and easily. And I had a client who needed to use it that way. And now it Does.

Concept: Vicidial's "IP" is an internal IP. 10.x.x.x. But that IP cannot be used by managers looking at admin.php's view of a lead's recordings who are not on that same subnet (if it's local, which it is in this case). The system works perfectly ... but the links are wrong until the sound files are sent to the FTP server, where the settings in the astguiclient.conf kick in.

This way the links are correct as soon as they are mixed and dropped into the appropriate GSW/GSM/etc folder. Now the managers can "listen" on an appropriate URL or FQDN very easily.

Since they have not yet set up their FTP server ... this was required for the managers to access the recordings. Works well, too, with that simple change.

I'm not sure if there is a later change that makes the admin.php NOT pull from the database, but this would mean that field is no longer in use anyway (so it does no harm), but now it works for this client quite well.

[mflorell]

I'm not sure I understand the problem, are you saying that the admin.php script is not changing the server to the set recording link server?

I have confirmed this is working on my dev setup so I would like to know how to duplicate this issue.

[williamconley]

I'm saying that when a recording is made and the client "searches for the lead" and then looks at the recordings for that lead ... the recording URL will be the "server_ip" as listed in the Admin->Servers server_ip. Unfortunately, if this is a LOCAL ip address, it is not accessible. So the URL to Play the recording may be "http://10.0.5.1/RECORDINGS/GSW/xxx...".

Patently inaccessible to an agent in a call center not local to the cluster. (Fairly normal for OUR setup.)

This value (10.0.5.1) is supplied to "admin_modify_lead.php?lead_id=xxxx" directly from the database however it was entered. The script that entered it has the server_ip value hard coded. I modified that script (AST_CRON_audio_2_compress) to use the preference from the Admin->Servers setting file for that server instead of merely using the server_ip variable from the astguiclient folder as was the previous behavior. So now when my client says he wants it to be the alt_ip (which he has set to the public ip) or the external_ip (which is set to the public ip's FQDN) it will substitute the appropriate value and not simply use the server's ip address that is impossible for them to surf to.

[mflorell]

We specifically do not want to change the database entry because other scripts might depend on the recording to be accessible locaclly, which it may not be using the external or alt server.

I looked at the admin_modify_lead.php script and found that only alt IP was coded to work, not external IP, so I will be fixing that.

[williamconley]

AFAIK the filename is already available in a sep field, and anything requiring that the URL be available ... would be the URL from the viewpoint of the MANAGER, who cannot reach the URL if it's non-local to him.

The local machines already know the filename (sep field) and the location (if it's not mixed by the mixing script, it's in monitor, then monitorDONE, if it's been compressed it's in the final GSW/GSM etc). I don't know of anything other than the "listen to the recording" link that would rely on the recording link ... since it's not a file pathway, it's a URL (can't be used to LOCATE the file for any manipulation other than listening).

[mflorell]

Imagine a multi-server system with the client using the AST_VDsales_export.pl script and the lead lookup script and the URL becomes very important.

I fixed the omission in SVN/trunk, so the display links will follow External IP now if that is set.

[williamconley]

which grabs the "location" field in question, stores in the the ivr_location variable, and then uses it in a "wget" to grab the file via web services (presumably to allow a single server to acquire these files even if they are not all on the same server where the command is run).

oddly enough, this would allow that function to work as well, as long as the URL works from the Vicidial server as well as it does from the Manager's Web Browser. That is, after all, the entire point is that the IP address in use as the "vicidial server ip" may be a local IP address, only usable on the local net, vs an "alt_ip" or FQDN that may be used anywhere on the web.

I could see it crashing if the substituted "alt_ip" is a "VPN" special of some sort, but I've not bumped into a situation where that was the case as yet. Since we are not talking about changing the path or filename, just the IP address (which is left up to the user ... and would need to STILL lead to that file).

I have a lot more clients using the "search for a lead, listen to the recording at the bottom" method than the "export sales" method, but this works for both in my tests so far.

[mflorell]

We have several clients on VPN and with wacky network setups which is why this was all set up in this way.

[williamconley]

And ... those would leave the "preference" on server_ip? (and the links would remain local?)

[mflorell]

That way the servers and scripts can run with local IPs as stored in the database field, and the people outside can use the external IP through the links in the web pages.

[williamconley]

Right. But the web pages don't have external links. They use "server_ip" as inserted by the audio_2_compress script. Unless the admin.php has a more recent change of which I am unaware and automatically uses a preference which overrides the value of the location field.

[mflorell]

They do a pattern match to replace the server_ip with the alt or the external:


$stmt="select recording_web_link,alt_server_ip,external_server_ip from servers where server_ip='$URLserver_ip';";
$rsltx=mysql_query($stmt, $link);
$rowx=mysql_fetch_row($rsltx);

if (eregi("ALT_IP",$rowx[0]))
{
$location = eregi_replace($URLserver_ip, $rowx[1], $location);
}
if (eregi("EXTERNAL_IP",$rowx[0]))
{
$location = eregi_replace($URLserver_ip, $rowx[2], $location);
}

[williamconley]

Weird. That wasn't workin' before, and I approached it from the "other angle" (change the value in the table).

But it works now! (without an update in the SVN.) I wonder how that happened.

Thanks for workin' me through it!

[mflorell]

no problem glad I could help, and ended up finding and fixing a bug in the process

[williamconley]

LOL. But now I gotta give a customer back an hour. I hate that part.