Call history plugin loses database connection

rennesrennes
in Plugins
Plugin Call History loses connection to database from time to time. I installed call history plugin and it seems to work erratically. It works for a few hours and then it says: No records found. After I logout and login again, the data is there again. Is this a known bug? I use Version 2.30.02

Comments

  • nicolasnicolas
    It is not a known bug. What happens if you right click and refresh the frame source when you notice the problem? Do records show up when the frame is refreshed?
  • rennesrennes
    Just tried it, no it didn't fix the problem. Data only comes back when I refresh the whole page. At the same time also the recordings page shows "no records"
  • nicolasnicolas
    Then it does not make sense. Refreshing the iframe will reload the php file responsible for that, and the php file, when run, will open a new mysql connection every time. If its a mysql connection that stalls, then a refresh will "heal" it, everytime.
  • rennesrennes
    I'll check the apache logs next time it happens, to see if and what it reloads
  • nicolasnicolas
    Ok.. .perhaps the problem is a different one? Perhaps php session variables are reset/expired by your php.ini configuration?
  • rennesrennes
    I had commented out these lines, as recommended in other thread in this forum:

    if($allowed <> "yes") {
    echo "<div class='container-fluid text-center'><br/><h3 class='animated tada'>You do not have permissions to access this resource</h3></div>";
    die();
    }

    Now when I commented this back in, I get "You do not have permissions to access this resource"
    I also noticed, that when I had seemingly working plugin (calls where there etc) when I reloaded the frame, I ended up with no data.
  • nicolasnicolas
    That is a php session issue then. It seems PHP sessions expire after some time in your setup/environment. You might want to increase session gc lifetime in php.ini or see if you have any external processes that clears session data after a while, and prevent them from doing so that often.
  • rennesrennes
    That it was, after setting the gc lifetime longer, the issue is gone. Thank you so much :)
  • kelmorekelmore
    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: 1440

    Should I set the master longer, to equal the local value?
  • nicolasnicolas
    What do you mean with "update"? A failed mysql connection will display nothing in the CDR , instead of "lost" the connection after a while.

    Best regards,
  • kelmorekelmore
    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!
  • nicolasnicolas
    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 is*not* related with FOP2 at all.

    Best regards,
  • kelmorekelmore
    edited March 2016
    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.
  • nicolasnicolas
    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,
  • kelmorekelmore
    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
  • kelmorekelmore
    This is doubly confusing because we have a pjsip inbound trunk, and a sip outbound trunk! I am lost trying to construct the correct query here to get all the calls without getting some bogus stuff.
    Hope you can help!
  • nicolasnicolas
    edited March 2016
    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,


  • kelmorekelmore
    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.php

    Find 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.
  • kelmorekelmore
    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;
  • kelmorekelmore
    Additionally, we are seeing outbound calls show up as dummy when the call history is not showing recent calls.
  • kelmorekelmore
    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/0

    that'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,Hangup

    I 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
  • nicolasnicolas
    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.

Leave a Comment

BoldItalicStrikethroughOrdered listUnordered list
Format
Heading 1Heading 2
QuoteCodeSpoiler
Emoji
:)=);):/:o:s:p:'(B):#:3<3
Url
Image
Align leftAlign centerAlign rightToggle HTML viewToggle full pageToggle lights
Drop image/file
Home • PluginsComment As ...

© Asternic Corp 2024