vicidial.org

I am trying to pass the recording file name variable on the disposition call URL but its not passing even though I can use it on the scripts, and on the web form URL..
Does anyone know which file to hack so it can also grab this variable from the DB, the recording file name becomes available as soon as the call is established so I do not know why it woudent be available at the end of call...

I would also like to pass to my CRM the called_count from the vicidial list table...

Which PHP file is the one that controls these variables from coming up, this way I can add the php sql code to include these also....

sounds like you've got a bit of a bug. i'd suggest an upgrade before "coding" just to be sure you're not fixing something already fixed.

also: please post your installation method (which may or may not be related to your issue ... but i'd also advise a vicibox redux install just to be safe, or perhaps a VMWare test box to see if this problem exists there ... if not, it may be time for a re-install)

I have a clean box install on CentOS 5 and my Vicidial version is 2.4-364a,

Is there anywhere you can think of that when setting up the Vicidial recording features this will interfere,

What passes is the whole VAR code so its ignoring the --A-- and --B-- like if it dosent know what to do with it, so my end result is
--A--recording_filename--B--
--A--recording_id--B--

But everything else I am passing goes through fine..

And I verified on the web form URL's it works perfectly, but I also noticed that the result for talk time variable passes just like on my scenario of the dispo call URL, which is suppose to since the Dispo and Talk Time are not available yet.

So guess what I am saying is that these fields might not be programmed to pass on the Dispo URL since they behave how the talk_time field does on the WEB FORM URL. But then again the Dispo variable just stays blank which is what I would imagine they should all be doing if its not available instead of passing the whole VAR code....

WEB FORM OUTPUT
Array ( [recording_file] => 20120920-100821_2126954400 [call_result] => [five9_dnis] => 2126954400 [five9_agent] => Testing 1002 [talk_time] => --A--talk_time--B-- [comments] => 244 [five9_campaign] => 002 [lead_id] => 33727760-2950-6015-1c7c-5052920691b7 [sugar_user] => a080a73b-8d6a-9d51-0129-504763e2c899 [vicidial_call_id] => 1348150091.1244 [vicidial_record_id] => 1915 [sugar_direction] => Outbound [sugar_call_status] => Held )

DISPO URL OUTPUT
Array ( [recording_file] => --A--recording_filename--B-- [call_result] => B [five9_dnis] => 2126954400 [five9_agent] => Testing 1002 [talk_time] => 56 [comments] => --A--recording_id--B-- [five9_campaign] => 002 [lead_id] => 33727760-2950-6015-1c7c-5052920691b7 [sugar_user] => a080a73b-8d6a-9d51-0129-504763e2c899 [vicidial_call_id] => 1348150091.1244 [vicidial_record_id] => 1915 [sugar_direction] => Outbound [sugar_call_status] => Held )

You may be bumping into a logic problem. The recording file will not be created for several minutes after the completion of the file (when the cron jobs mix/compress/ftp that file based on cron settings). Also: upgrading to the latest "Goautodial" is not "upgrading to the latest". The latest right now is 2.6, which may not be "released" yet, but is far beyond 2.4. Also, 2.4 has bug fixes in SVN that may not be in the "latest" goauto. And then you have to consider the "modifications" to the system by gardo for goauto ... which have been known to cause inconsistencies.

Advice: Install Vicibox 4.X in a virtual machine and run a test call in it (works great ... for ONE call!) and see if the behavior has changed. But do remember that the recording does not yet exist. It may be better to use the lead_id to link to the lead record in your other app and use that to link to the recording table and GET the recording after it exists and has found its final resting place. Better yet, use mysql to link to that location "live" so if the recording ever moves, you'll be linked to the new location!