Incoming calls being Terminated

VitalPBX Community Support General Discussion Incoming calls being Terminated

  • Post
    BrentNorrisKY
    Participant

    After the update last night all of my incoming Dahdi calls are being terminated.  They progress through the switch and then suddenly they go to Termination: Hangup Call.

    I don’t see anything in the logs that explains why this is happening.

     

    0
Viewing 12 replies - 1 through 12 (of 12 total)
  • Replies
    BrentNorrisKY
    Participant
    Up
    0
    Down

    It looks like something has happened to a bunch of my inbound routes.  The ones that are there seem to have their destinations cleared but there are also several that seem to be gone.

    0
    Up
    0
    Down

    Place a full log of an incoming call

    0
    BrentNorrisKY
    Participant
    Up
    0
    Down

    I found the issue.  It is the DB or the UI one.  All of my inbound routes have had their destinations cleared in the UI.  I am going back through now and setting them back to the correct locations.  As soon as I fix one then the calls start working again.

    No idea what would have caused all of the destinations to get cleared though and with all of my direct dials it is taking forever to put them back in.

    0
    BrentNorrisKY
    Participant
    Up
    0
    Down

    It looks like whatever happened it cleared the destinations for a lot of stuff.  My queues don’t have final destinations either.

    0
    Up
    0
    Down

    Do you have a backup of your system generated by the backup module of VitalPBX.

    From which version did you make upgrade?

    what did you have as destinations?

    0
    BrentNorrisKY
    Participant
    Up
    0
    Down

    I don’t. I literally just set that up yesterday, so the first one happened last night.

    Here is the grep from the yum log

    [root@vitalpbx ~]# grep vitalpbx /var/log/yum.log
    Apr 11 13:25:50 Installed: vitalpbx-custom_contexts-1.0.0-1.x86_64
    Apr 11 13:26:44 Installed: vitalpbx-phone-books-1.0.0-2.x86_64
    Jun 26 09:10:47 Updated: vitalpbx-asterisk-configs-2.0.3-3.x86_64
    Jun 26 09:10:50 Updated: vitalpbx-sounds-2.0.3-3.x86_64
    Jun 26 09:10:55 Updated: vitalpbx-sounds-es-2.0.3-3.x86_64
    Jun 26 09:11:00 Updated: vitalpbx-monitor-2.0.3-3.x86_64
    Jun 26 09:11:00 Updated: vitalpbx-themes-2.0.3-3.x86_64
    Jun 26 09:11:24 Updated: vitalpbx-2.0.3-3.x86_64
    Jun 27 13:16:29 Installed: vitalpbx-bulk-extensions-1.0.0-1.x86_64
    Jun 27 13:56:04 Installed: vitalpbx-task-manager-1.0.0-1.x86_64
    Jun 27 13:56:33 Updated: vitalpbx-phone-books-1.0.0-5.x86_64
    Jul 16 13:19:57 Updated: vitalpbx-sounds-es-2.0.4-1.x86_64
    Jul 16 13:20:00 Updated: vitalpbx-asterisk-configs-2.0.4-1.x86_64
    Jul 16 13:20:01 Updated: vitalpbx-sounds-2.0.4-1.x86_64
    Jul 16 13:20:01 Updated: vitalpbx-themes-2.0.4-1.x86_64
    Jul 16 13:20:04 Updated: vitalpbx-monitor-2.0.4-1.x86_64
    Jul 16 13:20:12 Updated: vitalpbx-2.0.4-1.x86_64
    Jul 16 13:20:13 Updated: vitalpbx-custom_contexts-1.0.1-1.x86_64
    [root@vitalpbx ~]#

    0
    BrentNorrisKY
    Participant
    Up
    0
    Down

    Just got this when I tried to update my IVRs with the destination after it had been blanked:

    SQLSTATE[42S22]: Column not found: 1054 Unknown column ‘5e9fd4dce07ec548f7ec66e66264d4aa.’ in ‘where clause’ With Query: select `5e9fd4dce07ec548f7ec66e66264d4aa`.`ivr_id` as `ivr_id`,`5e9fd4dce07ec548f7ec66e66264d4aa`.`option` as `option`,`5e9fd4dce07ec548f7ec66e66264d4aa`.`destination_id` as `destination_id`,`5e9fd4dce07ec548f7ec66e66264d4aa`.`enabled` as `enabled`,`5e9fd4dce07ec548f7ec66e66264d4aa`.`sort` as `sort` from `ombutel`.`ombu_ivr_entries` as `5e9fd4dce07ec548f7ec66e66264d4aa` where `5e9fd4dce07ec548f7ec66e66264d4aa`.“ = ? at file /usr/share/ombutel/www/includes/db.php on line 0

    0
    Up
    0
    Down

    The patches were not applied, execute the following script and post any output:

    php /usr/share/ombutel/scripts/apply_patches
    0
    Storm18
    Participant
    Up
    0
    Down

    The problem looks to be due to using the mysql service with no password.
    It seems that if you changed the mysql password to an exact password to allow communication between the SwitchBoard and other programs that use the the db. The script was not trying to use a password which means that in order for the patches to be applied the mysql root password needs to be set back to blank.
    Tried looking at the script to see if it was possible to use the password, but the file is encrypted with ioncube.
    If anyone is still having the same issue then it looks like resetting the mysql root password back to blank or none fixes this issue.

    0
    Up
    0
    Down

    Sure @storm18 the mysql root password must not be set/changed.

    0
    Up
    0
    Down

    We just release a patch to fix some issues in the version 2.0.4-1. Please update to version 2.0.4-2

    From console:

    yum clean all 

    rm -rf /var/cache/yum

    yum update vitalpbx
    0
    BrentNorrisKY
    Participant
    Up
    0
    Down

    Looks like the patch fixed the stuff that was outstanding.  Thanks for the help for sure!

    0
Viewing 12 replies - 1 through 12 (of 12 total)
  • You must be logged in to reply to this topic.