So, We have been using FreePBX for years, not a nooblet here.
But something seems to be really off with the Call Event Logging report.
My first real gripe is that the filter field options say “source” and “destination” and the table instead says “Caller” and “Dialed.” Are these supposed to be the same thing or are they really meaning different things ? If they are the same then call them the same thing. Why is it necessary to be confusing ?
But here is what is happening, we get hundreds of calls on 13 different DIDs. we are in the USA and now most of the calls include the +1 so as an example +180846673xx can appear in the caller or the dialed columns. but no matter what I plug into the “source” or “destination” search fields, no results are found. Is the search treating the + sign like an escape code or something that it is being ignored ?
Also, the search seems to ignore any type of partial data, and Mid or right data. It appears to only do a left search on a “full word”. Searching for “80855” gets no results (even though the number does NOT show a +1) We have 3 different DiDs that end in 00. but If I search for 00, i get no results, even though we can clearly see them when there is no filter on.
Likewise, we are looking to identify calls that come from certain area codes, and again, no matter what we put in, no results are returned. Again going back to the + sign now being the problem, and that it cant show partial match results, only whole words.
Per the online docs, this fields use standard T-SQL wildcard characters. Like the underscore character for any single character, the percent sign for zero or more characters, etc. So if I was looking for +16145551212, I could use _16145551212. If I was looking for anything with a 614 area code, I could use %614%. And so on.
That UI logic reminds of when I had to sanitize and parameterize my own web pages for SQL injection’s sake way back in the early 2000’s, but that’s the long and short of it. 
Thanks. but nope. I just refreshed the page.
put %808% in source and hit refresh - zero results.
put %808% in Destination and hit refresh - zero results.
808 is the area code for Hawaii and virtually every call we get. - zero results, but they all show with no filtering on.
I ran my test of this on FreePBX v16, so I can’t speak to v17. If there indeed is a difference in how this page works. Maybe someone else on here can. Sorry!
I got inconsistent results using the % wildcard. Could’ve sworn it worked when I tried yesterday. Then again I don’t use this report at all and had never drilled around in it. But I did have more success today using the underscore wildcard. Meaning any single character. So if I was searching for anything with a leading 1 and 614 area code I would use _1614_______ as my filter. The leading plus sign in my case, followed by 1614. Then any seven trailing characters. This worked.
I can NOT believe that underscore works, but it does. WHY is that not listed in the (?) help pop up on the page ??? you click the question mark for help and the help is useless. “Filter by destination” - yea, no shit. It would be HELPful if it said you have to use underscores in place of characters, and it must equal the length of the number you are looking for.
This also confirms that the + sign in front is a problem. Our number is 808466**** it shows in the “dialed” column as +1808466****. Even if i type the entire number including the + sign in the destination filter, it will not show any results. I MUST use the underscore instead of the + sign and then it will show me results.
Since the project is primarily open source, I assume the source code for this feature is available. While I didn’t delve into it, I also assume that the filtering logic is pseudo T-SQL based. That being the assumption, the percent sign can be used for SQL injection in certain cases. So perhaps that’s why only the underscore character is allowed. And only digits are “searchable,” not the plus sign for sure.
Agreed, the help pop ups are pretty much meaningless placeholders for the page. I primarily use the CDR reports, and those definitely don’t behave like the CEL reports do when we look at searching/filtering the results.
Why are you using CEL for this stuff? That’s not really what it is for.
As opposed to what ? Then what is it “for” ?
FreePBX is a bit misleading on this as they have it labeled as Call Event Logging and that is incorrect. CEL stands for Channel Event Logging and it logs evens that each channel has. CEL doesn’t work on a fixed src/dst like CDR’s do. CEL’s work with (such as the search form) these main fields:
– cid_name << this is set from the channel’s current CALLERID(name) at the time the event. If not set field is blank
– cid_num << set from the channel’s current CALLERID(num) at the time of the event. If not set, field is blank.
– extension << the dialplan extension that was hit. Could be an actual “extension” or s or any other extension in the dialplan.
– context << the dialplan context that the extension was found in.
None of these fields are guaranteed to have data in them or even the data you think is in them. When it comes to “I want to know how many calls from 808555 were received between X and Y dates…” you use the CDRs because that will have consistent src and dst data for the call overall.