I’ve been having issues with inbound calls and I found a post in the forums that helped, but now I don’t understand why it helped. Can someone help me understand the following scenario and why it worked?
I have a trunk setup using my SIP providers information. I have 1 outbound route that works just fine and I have 1 inbound route with the DID Field set to 8775551212 (random did for safety). With this setup, which is recommended by my provider, calls fail with either a busy signal or “number not in service” message. If I change the inbound route DID to be ANY it suddenly works.
Inbound route DID definitions are what allows me to have our 877 number dump to a queue vs our local number which dumps to and IVR. Right?
Why does it fail if I specify the DID, it’s the DID which is sent by the provider when they transfer incoming call packets. I don’t see anything in the logs that appears to be wrong.
Is it safe to have a DID set to ANY on and inbound route if I’ve disabled Anonymous Calls and stopped SIP Guests?
Many providers send an account number or other identifier in the SIP URI (the address on the INVITE line). At the Asterisk command prompt, type pjsip set logger on
if it’s a pjsip trunk, or sip set debug on
for a chan_sip trunk. Then make a test call; the SIP trace will appear in the normal Asterisk log.
If the DID number does not appear on the INVITE line but does appear in the To: header, change the context for your inbound trunk from from-trunk or from-pstn to from-pstn-toheader
Another possibility is that the provider is sending the number in an unexpected format, e.g. 18775551212 or +18775551212. Whatever you see in the incoming SIP is what you should put in the DID field of your Inbound Routes.
Normally, yes; I have a ‘catchall’ route on my own system. However, if that destination would allow an attacker to make an outgoing call and he can also bypass the trunk identification by spoofing a provider’s IP address, then removing the catchall would offer protection from an attacker who did not know your DID number.
Thank you for confirming that and thank you for the helpful information about inbound route DIDs and Catchall routes. I did run the “sip set debug on” and made a test call when the inbound route was set to ANY for the DID. I think this is the SIP message I need to see to set my inbound based on your post, correct? Please let me know if I failed to sanitize sensitive information.
[2018-07-20 12:01:06] VERBOSE chan_sip.c:
<— SIP read from UDP:[sip_provider_ip]:5060 —> INVITE sip:[email protected][our_external_ip]:5060 SIP/2.0
Via: SIP/2.0/UDP [sip_provider_ip];branch=z9hG4bK164f.b8c3e9d6979de8055e319240c15427dc.0
Via: SIP/2.0/UDP [sip_provider_ip2];rport=5060;branch=z9hG4bK164f.2abd8c53408766584a9fd653e8e7956d.0
Via: SIP/2.0/UDP [sip_provider_ip3]:5080;received=[sip_provider_ip3];branch=z9hG4bK56c19877;rport=5080
From: sip:+[my_cell_phone_num]@[sip_provider_ip2];tag=as5fb47983 To: 18775554422 sip:[email protected][our_external_ip]
Call-ID: [email protected][sip_provider_ip3]:5080
CSeq: 102 INVITE
Date: Fri, 20 Jul 2018 12:01:06 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
User-Agent: [SIP_Provider] SBC
I also have this appearing in my log quite often where the NOCtrunk is lagged and then reachable, if I am reading and understanding correctly it is talking about the response time of the domain/SIP Provider right? Also should I worry about the copious amounts of Remote UNIX Connection/Disconnected notices?
[2018-07-20 09:01:05] NOTICE chan_sip.c: Peer ‘noctrunk’ is now Lagged. (2049ms / 2000ms)
[2018-07-20 09:01:15] NOTICE chan_sip.c: Peer ‘noctrunk’ is now Reachable. (48ms / 2000ms)
[2018-07-20 09:32:02] VERBOSE asterisk.c: Remote UNIX connection
[2018-07-20 09:32:02] VERBOSE asterisk.c: Remote UNIX connection disconnected