Fixing the CDR when upgrading your FusionPBX

FusionPBX current stable release (when writing this article) is 4.4.4. So far the best FreeSWITCH fronted I have ever found. However, there is no flawless software, and because of the highly complex structure within, FusionPBX is no exception.

The hardest part in FusionPBX, in my opinion, is keeping track when upgrading legacy systems. There are many factors: dialplans get upgraded but old tenants don't get them, LUA scripts are updated, FreeSWITCH upgrades all these conducts to variables change and then, new software looking for variables that are not provided by old dialplans is one of the darkest places to look for a bug.

I will write here about two issues I found: first, regarding the EYE icon, then about the CDR when recording the calls.

Detailed CDR Shows an Empty Page

When you go to the Call Detailed Record Menu, you will see al your calls. If you are having this issue, when you click on the eye icon you will see an empty page with no information.

This is caused because, in tye v_xml_cdr table, the json field has its content escaped. Like this \{\"propierty\":\"value\"\}. The json_decode function returns a null instead of an error or an exception. The FusionPBX doesn't verify what happens.

In order to fix this, I just called the stripslashes() function. Voilà, it is fixed. I have sent pull request #4051 and #4052 to fix this. They were accepted.

Recordings not Shown in the CDR

First, we are 100% sure the file exists and it is not a filesystem permission issue. After that, you will notice that on some domains the recordings are not shown but the actual file exists.

The root cause of this problem is that record_name and record_path variables are not set in the dialplans, therefore the CDR Importer fails to feed the database. The FusionPBX code verifies for the existence of the record_session variable and it assumes the other record_* ones exist. Therefore, it tries to call dirname(urldecode(null)) and basename(urldecode(null)). Then, it just reviews for an isset() which it fails because the variable exists isset() will return true, but it actually has an empty value or null one.

Then, the fix is not only verifying for isset(), but for is_null() and strlen() == 0. Pull requests #4053 and #4054 have been sent to fix this issue. When writing this article, they haven't been accepted yet. I will update the post if they are accepted.

UPDATE: April, 20^th 2019. These pull requested have been accepted.

Do not hesitate on contacting me about fixing your deployments.

Good luck!