Help Understanding Inbound DID Failure

Hello All,

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.

My questions:

  1. 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?

  2. 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.

  3. Is it safe to have a DID set to ANY on and inbound route if I’ve disabled Anonymous Calls and stopped SIP Guests?

Correct.

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.

Stewart,

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[1131] chan_sip.c:
<— SIP read from UDP:[sip_provider_ip]:5060 —>
INVITE sip:[email protected][our_external_ip]:5060 SIP/2.0
Record-Route: sip:[sip_provider_ip];lr=on;ftag=as5fb47983;vst=AAAAAAEBAAICdAACBh4EeQYYHwQBHRwFBTguMTI5
Record-Route: sip:[sip_provider_ip2];lr=on;ftag=as5fb47983;vsf=AAAAAAAAAAAAAAAAAAAAAAAFAhgcBAgfHAMNFx8GAw01MDgw
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
Max-Forwards: 68
From: sip:+[my_cell_phone_num]@[sip_provider_ip2];tag=as5fb47983
To: 18775554422 sip:[email protected][our_external_ip]
Contact: sip:+[my_cell_phone_num]@[sip_provider_ip3]:5080
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
Supported: replaces
X-CallId:
Content-Type: application/sdp
Content-Length: 348
User-Agent: [SIP_Provider] SBC

v=0
o=[SIP_provider] 3390504 3390504 IN IP4 [sip_provider_ip3]
s=[SIP_Provider] GW
c=IN IP4 [sip_provider_ip3]
t=0 0
m=audio 16580 RTP/AVP 0 8 9 18 3 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

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[1794] chan_sip.c: Peer ‘noctrunk’ is now Lagged. (2049ms / 2000ms)
[2018-07-20 09:01:15] NOTICE[1794] chan_sip.c: Peer ‘noctrunk’ is now Reachable. (48ms / 2000ms)
[2018-07-20 09:32:02] VERBOSE[1729] asterisk.c: Remote UNIX connection
[2018-07-20 09:32:02] VERBOSE[25324] asterisk.c: Remote UNIX connection disconnected

Inbound DID arrives with a leading digit 1 which you can see for yourself in the DID column of the CDR. Your inbound route must match exactly for it to work as expected.

2 Likes

Thank you! After fiddling with it and trying yours and Stewarts suggestion it is now working correctly. I am very grateful for both your help as this was becoming a several day problem!

2 Likes

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.