Last week, I received a support call from a company that was using FreePBX® version 10 with Asterisk 1.8 on CentOS (basically Elastix) and they had an interesting issue. The call came from a company that installed this system in a call center running in “deviceanduser” mode and most of their phones are set as Ad-hoc so the agents can be assigned a desk for the week and work there. The agents earned better seats based on their performance. As such, moving from seat to seat, the agents rarely had the same phone each week. Yet, the reports had to be based on the agent, not the phone or device id.
With the version of the products that were installed, the reports being generated were a cross between extensions and device ids, depending on inbound or outbound calling. What I found is that the CDR was being generated incorrectly. The ‘src’ field was remaining that of the device id, even after the FreePBX® code updated the caller-id. Explaining this issue, I found a bug report on Asterisk:
http://issues.asterisk.org/jira/browse/ASTERISK-18699
This bug report gave the clue I needed. From Asterisk 1.6 to Asterisk 1.8, the ANI caller-id field is not updated when ‘number’ or ‘all’ are updated. With this, I searched for the correct place to modify the FreePBX® code.
In functions.inc.php, located in admin/modules/core/, near line 2267, I found a line like this:
$ext->add($context, $exten, ”, new ext_set(‘CALLERID(all)’, ‘”${AMPUSERCIDNAME}” <${AMPUSERCID}>’));
Under this line, I added the following:
//Fix CDR for ad-hoc devices, from Switzer Business Solutions, LLC
$ext->add($context, $exten, ”, new ext_set(‘CALLERID(ani)’, ‘${CALLERID(number)}’));
Once this was in place, I went to the FreePBX® web interface, opened an IVR (it could have been anything), then clicked Save Changes. This was only done to get the “Apply Changes” bar to appear. When it did, I clicked it.
Once this is done, the next time a call is made from an internal phone, the callerid(ani) field is updated to match the user’s extension, which causes the ‘src’ CDR field to properly reflect the source user of the call, rather than the source device. Unfortunately, the CDR data that was generated prior to the fix was all incorrect, but there’s not much we could do reliably about that.
The next problem we had to solve was reporting. The reporting module they had running was looking at the ‘channel’ field instead of the ‘src’ field. This seems like the wrong way to do it, since the field has extra characters. Example: ‘SIP/4321-5r97hfd873r’ rather than ‘4321’. Once the reports were modified to look at the correct field, all was performing as expected.
We hope the information about will help you to fix the problem that you or your customer is having. We’d like to hear back regarding your success or challenges. Thank you!