FOP2 + hotdesking some users not displaying call details

DLNoahDLNoah
in Support
We have an Asterisk 11.5.1 server, running FOP 2.28. Our users are set up in a hotdesking configuration, which I've previously described here: http://forum.fop2.com/conversation/post/4634

FOP has been working pretty well for the past 2 years (mostly on 2.24 or 2.26 during that time). At some point within the past 2 months, we've started having intermittent problems with some (but far from all) users not displaying their call detail information on their "button" in the extensions section. At first it seemed like it was just newly set up users, so I kinda back-burnered working on it. Recently, however, we swapped the physical phone for one of our established users, and he is now effected by the problem (and a couple of the most recent new hires are working just fine).

I've verified that my configuration files are still the same as they were when I had it working as referenced in my previous thread. The upgrade from FOP 2.26 to 2.28 did not change the behavior (although it did wipe out my autobuttons.cfg file and didn't back it up correctly, which is probably a separate issue). Any suggestions on where I should start looking, or where there might be logging to help run down what's happening?

Comments

  • nicolasnicolas
    edited January 2015
    Hi,

    FOP2 does this: when the UserEvent is fired with the userdeviceadded or removed, it will map the user number (USER/xxx) with the actual device (SIP/xxxx). When the remove event is received, it removes that device from the mapping.

    Then, when there is any event, the button match is done using any mapped devices (Based on the one created when receiving the userevents in runtime, or by querying the astdb on startup).

    So, if some buttons stop displaying status, it is because that mapping is broken. The thing is to verify *when"* does that break (I asume it works at the beginning but after a while it fails?)

    Unfortunately, trying to figure out that looking at the fop2 debug log is kind of impossible, at least the log file will be huge and only a few related events are the ones you would like to see, and finding the ones that you are interested in in a huge log file with no apparent time stamps is hard.

    To enable the debug log you can edit /etc/sysconfig/fop2 and set the OPTIONS line something like this:

    [fixed]
    OPTIONS="-d -X 511 -l /var/log"
    [/fixed]

    Then restart the fop2 service. You will have a fop2_debug.log in /var/log with full information. Then it is up to find the events when the map, you can look for the "device" string, or also "main channel for xxxx is yyyy"

    You should try to log some user, then make a call, verify if it works, then you can reload fop2 (service fop2 reload), and make another call and see if it still works, to see if a reload can trigger an issue.

  • DLNoahDLNoah
    For the effected users, it seems to work none of the time now, even after a FOP2 restart (a script reloads it at 0100 every morning, so that it picks up new users, etc).

    I verified before doing the upgrade today that at least one of the users who isn't working had the correct astdb entries.
  • nicolasnicolas
    Try to capture some logs to see if the astdb entries are being queried/get correctly (search for device and the strings I mentioned before). That might give me an idea of what could be wrong. Or try to catch me on the live help to chat/review your server config.
  • DLNoahDLNoah
    It looks like I forgot to mention this previously, but the "status" indication within the Queues list is always correct (in use / not in use) for the users, it's just the Extensions button that isn't showing call information for the effected user.

    I generated a test call from an extension that is showing call detail in FOP (342) to one that isn't (322). The startup log entries for 322 are below, I'm PMing you with the log file from the test call.

    /var/log/fop2_debug.log:main channel for 322 is SIP/58BFEA10AA0C
    /AMPUSER/322/device : 322

  • DLNoahDLNoah
    edited January 2015
    After much assistance via my log file and remote support, the problem was pinpointed as duplicate "logged in devices" -- I had deleted some extensions without making sure they were logged out, and then when a new user logged into the device that the old extension was logged into, FOP wound up seeing both users logged in. Resulting race condition wound up with the higher numbered extension usually "winning" -- which was the deleted extension.

    Cleaning up the duplicate /DEVICE/<extension>/dial keys in my astdb and then restarting FOP2 fixed the issue.
Sign In or Register to comment.

© Asternic Corp 2024