* Redirect duplicated xml_cdr_import script
This replaces the duplicated code in v_xml_cdr_import.php with xml_cdr_import.php
This also adds a call to `$cdr->post();` in that file to then process the POSTed data from FreeSWITCH
* Use epoch times for CDR Imports
There has been some discussion of edge cases for CDR Importing time zones/time stamps.
This modification makes the start_stamp, answer_stamp, and end_stamp values use the corresponding _epoch times for import into the v_xml_cdr table to remove any chance of time zone mis-alignment.
* Set Call recording date with Epoch
Use the start_epoch to set the call recording date.
- If the server time is set to UTC then the search needs to account for the local time zone.
- Use the database to format the date in the most efficient way.
I have been debugging slow loading on our CDR pages for the last few days now.
One issue that we have encountered is that currently as the page loads, it checks the filesystem for each file one at a time. In our case, we move recordings to object storage after 1 week, so each time we check for a file it passes api calls which take over 1 second each to return a result. This causes this page to not load at all for us in many cases.
Regardless, this current method is unnecessarily I/O intensive and really page load is probably not the time to be checking for each file one by one.
So this PR is the simplest solution - remove the check entirely. I would contend that the administrator should remove the record_path from the database if the file was removed so this should be acceptable.
This solves this particular issue for us, but would need feedback from others if not checking for files makes sense.
Track whether or not a message was actually left in the voicemail box. Previously we only knew that voicemail answered, now we know whether the caller left a message.
Callers who didn't leave a message now show up in the "Cancelled" call filter in xml_cdr.php
Bonus: Fixed a bug with the originating_leg_uuid that was breaking extension summary from a previous commit and some other minor bugs/typos.
Excluded cc_side = agent calls from being marked as missed_call = true
Fixed the previous performance issue with adding the cc_side != 'agent' to the SQL and removed its filter from the rendering loop for the xml_cdr.
It is redundant to filter out LOSE_RACE when originating_leg_uuid is also filtered, there is an overlap where every call with LOSE_RACE also has an originating_leg.
For some unexplained reason, including the `"and cc_side != 'agent'` in the WHERE tanks the query performance from seconds to minutes on Postgres 9.4. It runs great on Postgresql 13. Reverting to the "blank content while writing the page content" approach for this value unless I can find the source of the problem. - Oh, also removed an unnecessary condition that prevents you from filtering by LOSE_RACE.
Same thing as in the xml_cdr.php page display. If the call is answered instantly, less than a second, then the difference is 0s, and the 0s is a visual indicator that the call was answered, it just took less than a second. Calls that didn't get answered have a large negative number stored in the TTA field, 0 is an answered call.
