FreePBX



  • Hi,

    Hope I am not posing a common question…I did have a good hunt around for a solution. Unfortunately, the guides have not fully fixed the issue. I am running FreePBX 14 behind a pfsense firewall. I have a dedicated static WAN IP for the pabx server (virtual IP in pfs) and a server static internal IP which is Natted 1:1 to the WAN virtual IP. The server runs within the trusted LAN and remote logs into the sip trunk provider.

    I have followed a couple of guides which improved the time between drop outs from 15mins to 60mins but calls still drop at the 60 mins mark, precisely. I have changed the firewall optimisation setting to conservative and also Disabled the Firewall Scrub, this is how I increased the time from 15min to 60mins.

    I am guessing its still the firewall which is cancelling some udp state after a long period…keen to hear any ideas as what to try next.

    Thanks!

    PABX Log for from the call drop is detailed below (note: My number has been starred *** out)

    -- Channel SIP/Aus_Phone_Co-00000005 left 'simple_bridge' basic-bridge <f0b079b3-7c8e-4bc9-8d13-8b24f5df1300>
    -- Channel SIP/210-00000004 left 'simple_bridge' basic-bridge <f0b079b3-7c8e-4bc9-8d13-8b24f5df1300>
    

    == Spawn extension (macro-dialout-trunk, s, 32) exited non-zero on 'SIP/210-00000004' in macro 'dialout-trunk'
    == Spawn extension (from-internal, 93685602, 6) exited non-zero on 'SIP/210-00000004'
    -- Executing [h@from-internal:1] Macro("SIP/210-00000004", "hangupcall") in new stack
    -- Executing [s@macro-hangupcall:1] GotoIf("SIP/210-00000004", "1?theend") in new stack
    -- Goto (macro-hangupcall,s,3)
    -- Executing [s@macro-hangupcall:3] ExecIf("SIP/210-00000004", "0?Set(CDR(recordingfile)=)") in new stack
    -- Executing [s@macro-hangupcall:4] NoOp("SIP/210-00000004", "SIP/Aus_Phone_Co-00000005 monior file= ") in new stack
    -- Executing [s@macro-hangupcall:5] AGI("SIP/210-00000004", "attendedtransfer-rec-restart.php,SIP/Aus_Phone_Co-00000005,") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/attendedtransfer-rec-restart.php
    -- <SIP/210-00000004>AGI Script attendedtransfer-rec-restart.php completed, returning 0
    -- Executing [s@macro-hangupcall:6] Hangup("SIP/210-00000004", "") in new stack
    == Spawn extension (macro-hangupcall, s, 6) exited non-zero on 'SIP/210-00000004' in macro 'hangupcall'
    == Spawn extension (from-internal, h, 1) exited non-zero on 'SIP/210-00000004'
    -- SIP/210-00000004 Internal Gosub(crm-hangup,s,1) start
    -- Executing [s@crm-hangup:1] NoOp("SIP/210-00000004", "Sending Hangup to CRM") in new stack
    -- Executing [s@crm-hangup:2] NoOp("SIP/210-00000004", "HANGUP CAUSE: 16") in new stack
    -- Executing [s@crm-hangup:3] ExecIf("SIP/210-00000004", "0?Set(__CRM_VOICEMAIL=)") in new stack
    -- Executing [s@crm-hangup:4] NoOp("SIP/210-00000004", "MASTER CHANNEL: 1547877720.4 = 1547877720.4") in new stack
    -- Executing [s@crm-hangup:5] GotoIf("SIP/210-00000004", "0?return") in new stack
    -- Executing [s@crm-hangup:6] Set("SIP/210-00000004", "__CRM_HANGUP=1") in new stack
    -- Executing [s@crm-hangup:7] AGI("SIP/210-00000004", "sangomacrm.agi") in new stack
    -- Launched AGI Script /var/lib/asterisk/agi-bin/sangomacrm.agi
    -- <SIP/210-00000004>AGI Script sangomacrm.agi completed, returning 0
    -- Executing [s@crm-hangup:8] Return("SIP/210-00000004", "") in new stack
    == Spawn extension (from-internal, h, 1) exited non-zero on 'SIP/210-00000004'
    -- SIP/210-00000004 Internal Gosub(crm-hangup,s,1) complete GOSUB_RETVAL=



  • @mgbolts No, not necessarily. Which phones are you using? Snom phones have a peculiar setting. In case you use them, I'll look up the details.

    Anyway, 60 minutes does not sound like a router issue. I'd start with things like reINVITES and "session timers".



  • @jsphgttgns

    Thanks for the response.

    I have been testing this install with an analog phone connected to an SPA112 and also voiper on a windows PC. Tests comprised calling a normal PSTN line.

    The results are the same for both SPA112 and Voiper. I have a sample yealink unit on its way, will be testing this during the week.

    I reviewed the SPA112 and noted the following:

    Voice > Line 1 > Proxy and Registration > Register Expires : 3600
    Voice > Line 1 > Proxy and Registration > Proxy Fallback Intvl: 3600

    I tried setting this 60 and the call lasted more than 60 sec. Will try setting to > 3600 later to see if the call time is longer than current 60mins.

    I have not changed any NAT settings on the SPA, I have assumed not relevant given its not acting as a NAT (?). The settings are as follows:

    NAT Mapping Enable: No
    NAT Keep Alive Msg : $NOTIFY
    NAT Keep Alive Enable: No
    NAT Keep Alive Dest: $PROXY

    Thanks



  • Tried a couple of more things. Changed SPA settings to 7200 and the issue continues on external calls...drops after 60mins

    Voice > Line 1 > Proxy and Registration > Register Expires : 7200
    Voice > Line 1 > Proxy and Registration > Proxy Fallback Intvl: 7200

    I then tried an internal call zoiper (Win7) to SPA112 (analog phone) and it does not drop after 60 minutes, sitting at 75 mins so far. Will test to check if it goes beyond 7200s (2hrs).

    Based on the above, I am guessing its either sip provider timeout or a NAT issue now....

    Edit: Hung up internal call of 2 1/4 hrs, good enough for me...



  • I guess the SPA112 is one of Cisco's small ATA devices and it is connected locally to FreePBX.

    Another thing to look at is at the Asterisk messages when it is about time to fail. I would "core set debug 1" and "sip set debug on" or on the relevant peers. If it is a reINVITE problem, you should see what Zoiper is doing and what the ATA box is doing differently.

    If one has something to work with, one should look at the various other parameters like "directmedia", etc. It's difficult to say, if one does not have the log entries. If there is an INVITE and no ACK, then there a couple of things to look at, for example.

    Other than that, you could try to set "session-timers=refuse" for the SPA112 and maybe the outside line and see what happens. Session timers are basically a feature that allow telcos to more stably detect dead lines, but one can check this and than work backwards to see what the real problem ist. I know a telco that actually requires this setting for the outside lines.

    7200 means that the re-registration starts at 7200/2 = 3600, so this still looks like a timer problem to me.



  • Thanks for your input, I have learnt a great deal from trying to decode the logs, but still only a fraction of what I wish to know!

    BTW, as of a couple of hours ago (Monday morning here now), the SIP provider support has responded. They have confirmed that they had restricted calls to max of 60 minutes. Now that this is lifted, I will test again.

    Thank you for your assistance and sorry to waste your time....

    Regards



  • @mgbolts Occasionally I run into similar problems and then I am thankful for any hints myself, ☺.


Log in to reply