Incoming call strangeness

I’ve just installed Asterisk and FreePBX for the first time in ages and I decided to test out PJSIP, it took me awhile to get it to register with my provider but once i figured that it tried calling the number.
It connects to Asterisk fine and goes where ever specify in my inbound route but the audio is silent on the phone ringing the system.
I also noticed it would disconnect me from the console when using, I’ve got a log below (personal info has been sanitized)

Anyone got some ideas

Connected to Asterisk 14.6.0 currently running on ip-IPADDRESS (pid = 5367)
    -- Contact USERNUMBER/sip:[email protected]:5060 is now Reachable.  RTT: 23.053 msec
  == Endpoint USERNUMBERis now Reachable
  == Setting global variable 'SIPDOMAIN' to '13.210.13.123'
    -- Executing [s@from-pstn:1] Set("PJSIP/USERNUMBER-00000000", "__DIRECTION=INBOUND") in new stack
    -- Executing [s@from-pstn:2] Gosub("PJSIP/USERNUMBER-00000000", "sub-record-check,s,1(in,s,dontcare)") in new stack
    -- Executing [s@sub-record-check:1] GotoIfUSERNUMBER-00000000", "0?initialized") in new stack
    -- Executing [s@sub-record-check:2] SetUSERNUMBER-00000000", "__REC_STATUS=INITIALIZED") in new stack
    -- Executing [s@sub-record-check:3] SetUSERNUMBER-00000000", "NOW=1500625119") in new stack
    -- Executing [s@sub-record-check:4] SetUSERNUMBER-00000000", "__DAY=21") in new stack
    -- Executing [s@sub-record-check:5] SetUSERNUMBER-00000000", "__MONTH=07") in new stack
    -- Executing [s@sub-record-check:6] SetUSERNUMBER-00000000", "__YEAR=2017") in new stack
    -- Executing [s@sub-record-check:7] SetUSERNUMBER-00000000", "__TIMESTR=20170721-181839") in new stack
    -- Executing [s@sub-record-check:8] SetUSERNUMBER-00000000", "__FROMEXTEN=unknown") in new stack
    -- Executing [s@sub-record-check:9] SetUSERNUMBER-00000000", "__MON_FMT=wav") in new stack
    -- Executing [s@sub-record-check:10] NoOpUSERNUMBER-00000000", "Recordings initialized") in new stack
    -- Executing [s@sub-record-check:11] ExecIfUSERNUMBER-00000000", "0?Set(ARG3=dontcare)") in new stack
    -- Executing [s@sub-record-check:12] SetUSERNUMBER-00000000", "REC_POLICY_MODE_SAVE=") in new stack
    -- Executing [s@sub-record-check:13] ExecIfUSERNUMBER-00000000", "0?Set(REC_STATUS=NO)") in new stack
    -- Executing [s@sub-record-check:14] GotoIfUSERNUMBER-00000000", "2?checkaction") in new stack
    -- Goto (sub-record-check,s,17)
    -- Executing [s@sub-record-check:17] GotoIfUSERNUMBER-00000000", "1?sub-record-check,in,1") in new stack
    -- Goto (sub-record-check,in,1)
    -- Executing [in@sub-record-check:1] NoOpUSERNUMBER-00000000", "Inbound Recording Check to s") in new stack
    -- Executing [in@sub-record-check:2] SetUSERNUMBER-00000000", "FROMEXTEN=unknown") in new stack
    -- Executing [in@sub-record-check:3] ExecIfUSERNUMBER-00000000", "10?Set(FROMEXTEN=("PJSIP/USERNUMBER)") in new stack
    -- Executing [in@sub-record-check:4] GosubUSERNUMBER-00000000", "recordcheck,1(dontcare,in,s)") in new stack
    -- Executing [recordcheck@sub-record-check:1] NoOpUSERNUMBER-00000000", "Starting recording check against dontcare") in new stack
    -- Executing [recordcheck@sub-record-check:2] GotoUSERNUMBER-00000000", "dontcare") in new stack
    -- Goto (sub-record-check,recordcheck,3)
    -- Executing [recordcheck@sub-record-check:3] ReturnUSERNUMBER-00000000", "") in new stack
    -- Executing [in@sub-record-check:5] ReturnUSERNUMBER-00000000", "") in new stack
    -- Executing [s@from-pstn:3] ExecIfUSERNUMBER-00000000", "1?Set(__FROM_DID=s)") in new stack
    -- Executing [s@from-pstn:4] SetUSERNUMBER-00000000", "CDR(did)=s") in new stack
    -- Executing [s@from-pstn:5] ExecIfUSERNUMBER-00000000", "0 ?Set(CALLERID(name)=INBOUNDCID)") in new stack
    -- Executing [s@from-pstn:6] SetUSERNUMBER-00000000", "__MOHCLASS=") in new stack
    -- Executing [s@from-pstn:7] SetUSERNUMBER-00000000", "__REVERSAL_REJECT=FALSE") in new stack
    -- Executing [s@from-pstn:8] GotoIfUSERNUMBER-00000000", "1?post-reverse-charge") in new stack
    -- Goto (from-pstn,s,10)
    -- Executing [s@from-pstn:10] NoOpUSERNUMBER-00000000", "") in new stack
    -- Executing [s@from-pstn:11] SetUSERNUMBER-00000000", "__CALLINGNAMEPRES_SV=allowed_not_screened") in new stack
    -- Executing [s@from-pstn:12] SetUSERNUMBER-00000000", "__CALLINGNUMPRES_SV=allowed_not_screened") in new stack
    -- Executing [s@from-pstn:13] SetUSERNUMBER-00000000", "CALLERID(name-pres)=allowed_not_screened") in new stack
    -- Executing [s@from-pstn:14] SetUSERNUMBER-00000000", "CALLERID(num-pres)=allowed_not_screened") in new stack
    -- Executing [s@from-pstn:15] NoOpUSERNUMBER-00000000", "CallerID Entry Point") in new stack
    -- Executing [s@from-pstn:16] GotoUSERNUMBER-00000000", "ext-featurecodes,*43,1") in new stack
    -- Goto (ext-featurecodes,*43,1)
    -- Executing [*43@ext-featurecodes:1] GotoUSERNUMBER-00000000", "from-internal,*43,1") in new stack
    -- Goto (from-internal,*43,1)
    -- Executing [*43@from-internal:1] SetUSERNUMBER-00000000", "CONNECTEDLINE(name-charset,i)=utf8") in new stack
    -- Executing [*43@from-internal:2] SetUSERNUMBER-00000000", "CONNECTEDLINE(name,i)=Echo Test") in new stack
    -- Executing [*43@from-internal:3] SetUSERNUMBER-00000000", "CONNECTEDLINE(num,i)=*43") in new stack
    -- Executing [*43@from-internal:4] AnswerUSERNUMBER-00000000", "") in new stack
ip-IPADDRESS*CLI>
Disconnected from Asterisk server
Asterisk cleanly ending (0).
Executing last minute cleanups

Well I setup an extension using PJSIP too and it does the same thing

You may be a victim of a known Asterisk bug, if you are using Asterisk 13.15 or 13.16 try downgrading with:

yum downgrade asterisk13*13.14.0
fwconsole restart

The fix is in 13.17 which will be available soon.

Alternatively, you may have the external IP, local networks or other NAT settings set incorrectly in Settings, Asterisk SIP Settings. Router misconfiguration can do this as well, make sure to disable SIP ALG or any other SIP handling in the router.

I’m running Asterisk 14 currently and it appears that Asterisk is restarting but no suggestion as to why in the logs.
The server is running on AWS