Outgoing SIP trunking works, incoming says # not in service

Outgoing calls work great. I have created an incoming route for this number with DID number set to 17182805372, that leads directly to a ring group which I tested as working. When I attempt to place a call to the freepbx system, I see the following. I know that the setup is registered, I see the call making it through to the PBX in the CLI, and I know outgoing calls work, so I am stumped here. It plays the message that this number is not in service instead of routing it to the appropriate ring group.

Is there anything simple I am missing here?

]# asterisk -vvvvvr
Asterisk 11.19.0, Copyright (C) 1999 - 2013 Digium, Inc. and others.
Created by Mark Spencer <[email protected]>
Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details.
This is free software, with components licensed under the GNU General Public
License version 2 and other licenses; you are welcome to redistribute it under
certain conditions. Type 'core show license' for details.
=========================================================================
Connected to Asterisk 11.19.0 currently running on localhost (pid = 2019)
  == Using SIP RTP TOS bits 184
  == Using SIP RTP CoS mark 5
    -- Executing [[email protected]:1] Set("SIP/FIVE-00000002", "__FROM_DID=+17182805372") in new stack
    -- Executing [[email protected]:2] NoOp("SIP/FIVE-00000002", "Received an unknown call with DID set to +17182805372") in new stack
    -- Executing [[email protected]:3] Goto("SIP/FIVE-00000002", "s,a2") in new stack
    -- Goto (from-pstn,s,2)
    -- Executing [[email protected]:2] Answer("SIP/FIVE-00000002", "") in new stack
    -- Executing [[email protected]:3] Log("SIP/FIVE-00000002", "WARNING,Friendly Scanner from 54.175.63.250") in new stack
[2016-01-12 21:31:24] WARNING[2766][C-00000002]: Ext. s:3 @ from-pstn: Friendly Scanner from 54.175.63.250
    -- Executing [[email protected]:4] Wait("SIP/FIVE-00000002", "2") in new stack
       > 0xb75339b0 -- Probation passed - setting RTP source address to 54.175.63.248:16234
    -- Executing [[email protected]:5] Playback("SIP/FIVE-00000002", "ss-noservice") in new stack
    -- <SIP/FIVE-00000002> Playing 'ss-noservice.ulaw' (language 'en')
    -- Executing [[email protected]:6] SayAlpha("SIP/FIVE-00000002", "+17182805372") in new stack
    -- <SIP/FIVE-00000002> Playing 'letters/plus.ulaw' (language 'en')
    -- <SIP/FIVE-00000002> Playing 'digits/1.ulaw' (language 'en')
    -- <SIP/FIVE-00000002> Playing 'digits/7.ulaw' (language 'en')
    -- <SIP/FIVE-00000002> Playing 'digits/1.ulaw' (language 'en')
    -- <SIP/FIVE-00000002> Playing 'digits/8.ulaw' (language 'en')
    -- <SIP/FIVE-00000002> Playing 'digits/2.ulaw' (language 'en')
    -- <SIP/FIVE-00000002> Playing 'digits/8.ulaw' (language 'en')
    -- <SIP/FIVE-00000002> Playing 'digits/0.ulaw' (language 'en')
    -- <SIP/FIVE-00000002> Playing 'digits/5.ulaw' (language 'en')
    -- <SIP/FIVE-00000002> Playing 'digits/3.ulaw' (language 'en')
    -- <SIP/FIVE-00000002> Playing 'digits/7.ulaw' (language 'en')
    -- <SIP/FIVE-00000002> Playing 'digits/2.ulaw' (language 'en')
    -- Executing [[email protected]:7] Hangup("SIP/FIVE-00000002", "") in new stack
  == Spawn extension (from-pstn, s, 7) exited non-zero on 'SIP/FIVE-00000002'
    -- Executing [[email protected]:1] Macro("SIP/FIVE-00000002", "hangupcall,") in new stack
    -- Executing [[email protected]:1] ExecIf("SIP/FIVE-00000002", "0?Set(CDR(recordingfile)=.)") in new stack
    -- Executing [[email protected]:2] GotoIf("SIP/FIVE-00000002", "1?theend") in new stack
    -- Goto (macro-hangupcall,s,4)
    -- Executing [[email protected]:4] Hangup("SIP/FIVE-00000002", "") in new stack
  == Spawn extension (macro-hangupcall, s, 4) exited non-zero on 'SIP/FIVE-00000002' in macro 'hangupcall'
  == Spawn extension (from-pstn, h, 1) exited non-zero on 'SIP/FIVE-00000002'

your DID is identified as

so you need to use the context from-pstn-e164-us on that trunk to fix that

I misclicked and had E164 set to true for my provider when it should have been off. My head has been removing the + from that log all day… wow.

Thank you for that!