Upon reboot of 3CX PBX instance, must run firewall check to enable incoming call routing

Discussion in '3CX Phone System - General' started by Stephen Hellriegel, Feb 7, 2018.

Thread Status:
Not open for further replies.
  1. Stephen Hellriegel

    Joined:
    Jan 1, 2018
    Messages:
    6
    Likes Received:
    2
    System Configuration:
    3CX PBX system, installed as the "3CX linux distro" from 3CX.
    3CX PRO version 15.5.6354.2
    2 SBC, (raspberry PI3), each with about a dozen phones (yealink T21P E2 ,1 BLF per phone)
    The SBCs and the PBX are all on separate global IP networks (and ISPs).


    When I reboot the 3CX PBX linux box, everything comes back up.
    SIP trunks are registered.
    station to station calling works (both intra and inter SBC).

    However, all inbound routes fail. External callers get a busy signal.

    My SIP trunk provider sends me an error message for every inbound call.
    "A call to your DID nnnnnnnnnn from nnnnnnnnnn has failed at 5:57pm on 02/06/2018 MDT. We received 'CONGESTION' when attempting to route the call to your server or device. This number is configured to route to the peer IPQUAD on the account bozosRus."

    All outbound routes fail. Even though they are listed as "registered" and I confirm at the SIP provider the trunks are online. Internal callers receive an "cannot complete call at this time" message.
    On my dashboard, my "Firewall Check" is "Firewall test OK"

    Upon re-running the Firewall test, All inbound and outbound routing immediately starts working.

    It seems like a service is not starting in the correct order upon reboot. Or perhaps a dependency is not met?
    For example, when running the firewall checker, the 3CX SIP server and Tunneling Proxy are restarted and fully operational well before the 3CX media server is restarted due to the delay in the port scanning of ports 9000...9255. During normal boot, the services start in rapid succession.
     
  2. JCLloyd

    JCLloyd New Member

    Joined:
    Oct 5, 2017
    Messages:
    112
    Likes Received:
    19
    Running the firewall check is in essence bouncing all of the services. The Media Server service would be my first place to look (FN1). Interpreting the wording of the error seems to indicate to me that the connection to the negotiation with the Raspberry PI3 doesn't properly occur at the correct time, as you are speculating.
    . Try stopping and starting just the Media Server service, first. I found that bouncing the SIP Server service bounces the IVR Server & Media Server services, which means that they are related. I don't use call queues, but you may need to consider that service... maybe.

    ___________________
    FN1 - https://www.3cx.com/blog/docs/media-server/
    "... In these cases, the Media server completely handles negotiations with the participant. It provides its own SDP when it contacts the destination agent and not the SDP of the caller agent. Therefore in this mode each agent negotiates RTP messages directly with Media server and in turn the Media server encodes the audio stream for the agents. In other words, both agents send RTP to Media server and Media server delivers to each. ..."
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  3. Stephen Hellriegel

    Joined:
    Jan 1, 2018
    Messages:
    6
    Likes Received:
    2
    Yes, I have all the extensions configured for PBX handles Audio and supports re-invite.
    I agree, doing the firewall check bounces all the services (so does rebooting the PBX)
    My observation is that for whatever reason, the bouncing of the PBX OS is not sufficient to get the 3CX system operation, I have to manually run the firewall check to re-bounce after the fact.

    Perhaps there is a command line I can execute in an rc.local script to force a reload of the media service.
     
Thread Status:
Not open for further replies.