Null UUID's are not very kind. They will sneak into your CDR's when you aren't looking and break an otherwise very nice database INSERT statement. We cannot tolerate that sort of behavior.
* record_name verification
* record_name better verification
when you carry on some updates from 4.0 to 4.2 and then 4.4, old dialplans do not create all the variables, record_session is created, but record_name (and record_path) are not null, set and lenght zero, "" in otherwords.
Then, in the db record, record_name and record_path are empty, regardless if the recording file exists. Therefore, they are not shown in the CDR app.
This fixes this issue.
* Bug fix: No answer_stamp in CDR
Here's a fun little bug that took me a longer than it should have to figure out. When a person make a call and then cancels the request there is no "answer_stamp" written to the CDR. Because of this, v_call_recordings.call_recording_name gets imported as NULL. This causes all the canceled calls to show up in the Call Recordings app first in the list and with no date set.
* Update xml_cdr.php
* Update v_xml_cdr_import.php
Add check for duplicate call records. Duplicate records will cause the entire db insert to fail. I have tested this with the /app/xml_cdr/xml_cdr_import.php method for cdr insertion.
This grabs a recording if started by bind_digit_action "*2" or by "nolocal:api_on_answer=uuid_record ${uuid} start ${recordings_dir}/${domain_name}/archive/${strftime(%Y)}/${strftime(%b)}/${strftime(%d)}/${uuid}.${record_ext}".
FusionPBX
Nate
konradSC
Luis Daniel Lucio Quiroz
Alexey Melnichuk