Inbound calls not working because trunk not providing IP?

FreePBX Installation / Upgrade
, ,
1

Hi All,

Just upgraded our small business LAN network (and fixed a double NAT issue which the original Free PBX was setup for) so long story short, had a very (not) fun time trying to get FreePBX trying to talk to the trunk provider again… Anyway - Notwithstanding, I’m almost there!

Just dealing with inbound calls not being handled correctly, getting the old “The number you have dialled is not in service” - So did a bit of research on this forum and attempted to see if “Allow Anonymous Calls” would work, and it did work, however that’s not optimal so turned that back off… But at least now know that Asterisk/the trunk itself is not authenticating the inbound request correctly

So looked at the logs and found something interesting:
[2019-05-14 21:03:24] WARNING[8450][C-00000014]: Ext. s:6 @ from-sip-external: "Rejecting unknown SIP connection from "
… and no IP? So of course it’s not authenticating the incoming request because there’s no IP to authenticate the request from? I think?

For reference, a tcpdump during the call shows the following:
21:17:05.833321 IP 103.93.71.11.sip > raspbx.sip: SIP: INVITE sip:[email protected] SIP/2.0
21:17:05.835919 IP raspbx.sip > 103.93.71.11.sip: SIP: SIP/2.0 100 Trying
21:17:05.847619 IP raspbx.sip > 103.93.71.11.sip: SIP: SIP/2.0 200 OK
21:17:05.872719 IP 103.93.71.11.sip > raspbx.sip: SIP: ACK sip:XXX.my.ip.0:5060 SIP/2.0
21:17:05.872867 IP 103.93.71.11.sip > raspbx.sip: SIP: ACK sip:XXX.my.ip.0:5060 SIP/2.0
21:17:10.571939 IP 103.93.71.11.sip > raspbx.sip: SIP: BYE sip:XXX.my.ip.0:5060 SIP/2.0
21:17:10.573304 IP raspbx.sip > 103.93.71.11.sip: SIP: SIP/2.0 200 OK

And also the below trunk settings, note that the host name resolves to the IP listed in the above tcpdump:

Outgoing Peer Details:
host=sip3.siptalk.com.au
username=10XXXXX
secret=supersecretpassword
type=peer
allow=ulaw&alaw
pedantic=no
insecure=port,invite
fromuser=10XXXXX
qualify=yes

Incoming User Context: 10XXXXX (is this what should be here?)

Incoming User Details:
secret=supersecretpassword
type=peer
context=from-trunk
host=103.93.71.33

Register String: 10XXXXX:[email protected]/10XXXXX

*Note: A post on this forum suggested that domain names often have trouble resolving to a single domain, thus the IP as the host in the outgoing settings - Is this true?

I think I’m on the right path here, just figuring out a way to allow Asterisk/FreePBX to authenticate the incoming request from the trunk.

You guys are all absolute geniuses on this site, and appreciate all the help and support you generously give everyone! Much much much appreciated!!!

Best Regards,
Frank D

2

Couple choices to play with.

  1. Disable the SIP trunk and use PJSIP instead.
  2. Delete the incoming user context and details information, that is almost never used with a registration string.
3

The host in your incoming dial peer does not match the IP Address of the server making the call to you you may need additional incoming dial peers

4

Try the following:

In Outgoing Peer Details, add
context=from-trunk
and change to
type=friend

Incoming User Context should be blank.
Incoming User Details should be blank.
Register String is ok.

Create a temporary Incoming Route with DID Number and CallerID Number both blank, with Destination pointing to a working extension.

Test incoming call. If it takes the temporary ‘default’ path, check the CDR and use the value shown for DID in your production route.

If it still fails, post a new log.

5

Hi Guys,

TLDR; Success! Provider IPs used to contact me for inbound calls are different than the IP that resolves in the host for the original trunk - Adding additional IPs ass individual PJSIP trunks did the trick :slight_smile: - One small question at bottom of post!

–

Thanks for all the responses! With the help of everybody involved, I think I managed to have resolved this, first some summary for what did not work as I know first hand how frustrating it can be reading posts on this forum without a detailed understanding of the resolved issue, so here goes for those who may read in the future!

Removing all information within Inbound User Context/Details didn’t do the trick @sorvani and converting the trunk to PJSIP was also a no-go; Neither did adding the additional outgoing information @Stewart1

However, a big thank you to @Jas_williams thank you for your extra effort attempting a DNS resolution on the above domain, and pointing out the detail of a mismatch between the communicating IP for the INVITE request! This got me going in the right direction…

Logging the call in the Asterisk CLI (pjsip set logger on) I saw the detailed INVITE and subsequent TRYING requests coming in from the trunk and hitting FreePBX, and noticed that request’s IP was different to the host address I was using in the Trunk, so I knew at the very least that Asterisk wouldn’t recognise the incoming IP address and reject it (a good thing! Seeing as I get several hundred requests from unknown IPs a day coming from China, the Gaza Strip - You name it!) - Crucially, I also saw that these requests were coming in on port 5060, the PJSIP port as I have learnt from this forum…

Next was adding a PJSIP trunk, using the same authentication details, but with this new IP address coming in on the invite requests - And success! Logically so I might add, seeing as for my particular provider, I have to provide my front-facing IP and they contact that IP when a call is received on the DID number… So now I guess it’ll be acquiring all the potential IPs that the provider may use, and adding them individually as PJSIP trunks…

I guess my only remaining question is can you designate trunks as inbound only? These IPs are clearly different from the host I use to register outbound calls to, so is there a setting within the PJSIP trunk to turn outbound authentication off, for example? Now looking at the logs I get a lot of 503 responses back from the trunk IP, and eventually hit the max-retry limit… don’t want to come off as spammy myself!

Again, all the help of the whole community here is much appreciated - The knowledge you guys have is insane and have total respect for everyone!

Best Regards,
Frank D

6

I’m glad to hear that you got it working.

With pjsip, you should need only one trunk. Set up the outbound normally, then in the Match (Permit) field, list the IP addresses (or ranges of addresses) from which the provider can send calls.

Providers like that (virtually all ‘wholesale’ and many high end retail) generally don’t require registration. You could try setting Registration for the trunk to None – if that still works you’ll avoid the possibility of ‘lost registration’ causing calls to fail.

Also, most such providers also offer IP authentication, where you configure on their portal a list of your IP addresses from which you send calls. Then, you can disable (on their portal) password authentication, which provides some extra security (an attacker who somehow obtains your password won’t be able to make calls).

7

That should not be necessary, because a trunk will be used for outgoing, only when it is listed in an Outbound Route. When you edit the trunk, you should see:
WARNING: This trunk is not used by any routes!

If you are sending a call to a domain name or IP address other than where they ask you to send calls, your Outbound Routes are set up incorrectly.

However, note that most ‘wholesale’ providers and a few others will occasionally reject calls with 503 arbitrarily. This may be caused by upstream failures, capacity limitations, buy rate > sell rate and various other causes. Your contract with them requires you to have a failover route for all calls you send.

8

That was the way we did it back in the middle ages with chan_sip. With PJSIP, the preferred® way to do this is with a single PJSIP trunk, then populate the “Match (Permit)” field with all the IPs, FQDNs and subnets (separated by commas) that could send an INVITE to your PBX. This also prevents you sending calls out to an inbound only host.

9

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