Call history plugin loses database connection
-
How long did you set gc lifetime?
My history is not updating either. I've restarted my computer, which should initiate a new PHP session anyway, but it still does not update. FOP2 2.30.04, FreePBX 13.0.70
I just checked in freepbx under Reports>phpinfo and see:
session.gc_maxlifetime: local value: 2592000 master value: 1440Should I set the master longer, to equal the local value?
-
-
The Call History is populating, both in the Button and in the Profile Drop Down>History Window, but it is populating only with old information.
It shows my last Incoming call was 11 days ago, when it should be today, and it shows my last Outgoing call as 6 days ago, when it should be today. Other users on my installation are seeing similar information.
Thanks for the help!
-
Call history data comes straight from the Mysql CDR table that is populated and mantained by asterisk, not by FOP2. It sounds like your Mysql CDR is broken in Asterisk itself. Grep for "cdr_mysql" in the full log:
grep cdr_mysql /var/log/asterisk/full
To check for errors... if you have problems with cdr, it isnot related with FOP2 at all.
Best regards,
-
That command returns no entries in the log. I do return errors in the log when I search for some other text, so the log is working.
When I check CDR Reports in freepbx, I am able to see two outbound calls that I made today, but these aren't present in the FOP2 History.
-
Perhaps your CDR records do not have a channel and dstchannel fields matching the ones expected in FOP2 relating your own extension. This is the where condition to search for records:
(src='$extension' OR channel LIKE 'SIP/$extension-' OR dst='$extension' OR dstchannel LIKE 'SIP/$extension-' )
where $extension is your extension number, like '100'.
That would be something like
SELECT * FROM cdr WHERE (src='100' OR channel LIKE 'SIP/100-' OR dst='100' OR dstchannel LIKE 'SIP/100-' )
You can run that query directly via mysql and see if it retrieves anything. If you have CDR constructed in a different way, then you will need to customize that query/code in the calldetailrecords.php file.
Best regards,
-
Thanks, this pointed me in the right direction. After doing some digging, I unearthed the difference in the query results, and found that we were not getting all of the results because our voip 'channel' is actually a PJSIP channel, rather than a SIP channel.
After changing it in both places in the the $mifilt IF statement within calldetailrecords.php, I'm now seeing what might be all the calls. Is there anywhere else in the file this should be updated?
Maybe we could add a wildcard in front of the SIP to account for either voip setting?
Kevin -
-
Having trunks as SIP should not make a difference. Having mixed SIP/PJSIP extensions could. The condition is to match only extensions, as the cdr page is only interested in finding records that could be matched to an extension either as a src/channel or dst/dstchannel. src and dst are extension NUMBERS, channel/destchannel are extension DEVICES. The SIP/xxxx-_____ construction is done only on the device field. So, if you use PJSIP and the channel name in the CDR matches the convention of SIP, then just changing SIP to PJSIP in the conditional should be enough. The channel name convention used for the SQL query is
TECH/EXTENSION-12345678
Where 12345678 is the random session string. So the LIKE sql query is SIP/$extension-________ by default, and changing it to PJSIP/xxx should be enough. Check to see in the CDR entries if the session part is 8 chars long. They query will also use the $extension variable/number in the channel name, that should exclude any entry for a trunk that will generally have a name or an ip address instead.
Try to catch me on the live help, if you can give me access to your server I can inspect the CDR and mysql queries and see if we can come up with the correct one.
Best regards,
-
We seem to have resolved our issue. Since we have PJSIP extensions, I updated these two files:
/var/www/html/fop2/admin/plugins/callhistory/callhistorybsgrid.php
&
/var/www/html/fop2/calldetailrecords.phpFind all instances of SIP/ and change them to PJSIP, I think there are 5 in each file. This seems to be wokring for me just fine. I believe a future FOP2 update may account for both types.
Thanks Nicolas. -
We needed to custom edit the call detail records for PJSIP. Since a recent upgrade, the call history has not been working right (in both the plugin button and the popup). Sometimes it correctly shows call history, other times, it seems to show only calls that happened before the upgrade happened (14 days ago in this case). I can't get to the bottom of it. I recreated the query from plugings/callhistory/callhistorybsgrid.php for this particular extension, and all of the recent calls pull up fine from the query. But currently, the plugin button is not showing the same data.
SELECT calldate,concat(IF(dst='".6603."' OR dstchannel LIKE 'PJSIP/6603-' ,src,dst),'!',clid) as number,duration,disposition,uniqueid FROM cdr WHERE (src='6603' OR channel LIKE 'PJSIP/6603-') order by calldate desc limit 50;
-
-
We followed this post, but it seems our file is already including the fix you proposed for another customer, so the dummy must be coming from somewhere else.
http://forum.fop2.com/1331-pickup-call-function-cause-dummy-entry-in-database/0that's where I found it.
It's in /etc/asterisk/extensions_override_fop2.conf
[fop2-dummy]
exten => dummy,1,Answer
exten => dummy,n,Wait(1)
exten => dummy,n,NoCDR()
exten => dummy,n,HangupI also commented out #push @allreturn, $return; in FOP2Callbacks.pm in the LEAVE section. Will see if that resolves it. Sorry to make so many posts! This helps me keep track of what I tried and when haha
-
The post you mention talks about a dummy call made when you drag a call out from a queue in FOP2, those calls won't show up on call history in FOP2 in any way as the source channel is a dummy channel of type Local/xxxx and not a device (either sip or pjsip).
If you run the query you see on the calldetails php file and see any particular result, the same results you should see in the results from the .php itself. Hard to tell what is going on without looking at the actual queries performed by calldetailrecords.php and results from your cdr tables.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login