Allow several IP addresses on SIP trunk

Hi,

FreePBX 15.0.16.76
Current Asterisk Version: 13.36.0

I use Gradwell UK as our sip trunk provider. We are set as chan_sip. And since they send traffic from several IP addresses they require “Allow Anonymous Inbound SIP Calls” to be set to YES. This is causing issues, since I am getting ghost calls and calls from extensions that don’t even exist.

This is how the trunk is currently configured for the incoming settings:
Incoming Sip Settings:
USER Context: Trunk Name
USER Details:
type=user
insecure=very
host=dynamic

I though of changing the trunk to chan_pjsip, but they do not authenticate with a username and password and this is required to configure the trunk as chan_pjsip.
I have been told by their support that I could duplicate the trunk for each IP they provided and modify the IP of the duplicated trunks so that we have one chan_sip trunk for each of the provider’s IPs.
This is the link to the IP list: https://my.gradwell.com/s/article/what-ip-addresses-may-gradwell-send-voip-traffic-from
It shows the Netblock and the IP ranges, but I am not sure how I would configure this in FreePBX.

Could anyone give me an idea?

You don’t need auth for pjsip, in the settings you set auth to none and in advance you set match IP to the IPs of the Gradwell servers.

I have this working with Simwood trunks here in the UK.

This is where the Firewall comes in REAL handy - Allow traffic from their servers (and your remote people) by IP or Friendly and block the rest and the problem will go away.

Not the right answer. That is only a band aid to hide the injury. A properly configured trunk will already whitelist the addresses it uses.

This. You are correct that pjsip is your answer, you just need to configure it correctly.

Here is an example from Skyetel.

Then go to the advanced tab and add all of the IP addresses/blocks in the match permit.
I do not have anything in there because Skyetel properly uses SRV records so it is all handled with the domain na.skyetel.com. They used to tell everyone to use term.skyetel.com and to populate the match/permit.

1 Like

Great @sorvani! This is what I was looking for. I will try and let you know how it goes.

I have now created the pjsip trunk and added the IP addresses on the match/permit field. I have created an outbound route to test outbound calls using this trunk and I was able to make calls successfully.
Now how do I make sure that inbound calls use this new trunk I created?
I want to make sure inbound calls work before deleting my previous chansip trunk.

Disable the chan_sip trunk.

But you need to make sure your provider is pointing to what ever port you are using for PJSIP. Most likely you have pjsip on something other than 5060 if you were using chan_sip for a long time.

Thanks Sorvani, this works, but I have now set the **Allow Anonymous Inbound SIP Calls" and “Allow Sip Guest” options to NO and when I do this I cannot make nor receive calls.
If I set it to YES then I can dial out and receive calls with the PJSIP trunk I created.
Is there any setting I am missing?

Yes, set Match (Permit) for the trunk to the list of IP addresses or netblocks from which the provider can send calls. If that is not working, paste the log for a failing incoming call at pastebin.freepbx.org and post the link here.

Allow guest and allow anon should have no effect on outbound calls.

You are correct, sorry for the confusion. I am able to dial out. I was just trying to dial one of our DDI’s and I am getting “All circuits are busy” message, meaning I am unable to get inbound calls when I set the Allow guest and Allow Anonymous Inbound Sip Calls to “NO”.If I set it to YES I receive calls.
I have already set Match (Permit) for the pjsip trunk to the netblocks from which the provider is sending traffic from. There are like 20 netblocks, is there a limit?

How do I get the log for the failing incoming call?

The raw logfile is in
/etc/asterisk/full
Or, from the GUI, Reports -> Asterisk logfiles. Once the complete log is shown, turn off Auto-Scroll and check if the beginning of the call is there. If not, increase Lines to e.g. 1000. (500 Lines should be plenty for a call rejected as anonymous.)

I am confused. The log posted shows a failing outgoing call, presumably to your freephone number, with no sign of the incoming leg. Normally, there would at least an error message from pjsip, if the call came into the PBX but did not match a trunk.

One thing that looks a little suspicious, but may not be a problem, is that the called number is in the format 44800xxxxxxx (E.164 without the +) but the caller ID is 0203xxxxxxx (national format). It’s common for providers to require the same format for both, e.g. caller ID 44203xxxxxxx. If you can call other freephone numbers, this is probably not a problem.

When you call your 44800 number from your mobile, does anything appear in the Asterisk log? If so, post that. If not, run sngrep and see whether the incoming INVITE shows there. If so, this is likely a FreePBX firewall issue; confirm that the source address is Trusted. If nothing shows in sngrep, either, it could be a registration issue or a problem with a hardware router/firewall in front of the PBX. If using registration, check Reports -> Asterisk Info -> Registries to confirm the trunk is registered. If using IP auth, confirm that your settings at the provider are directing the call to the proper IP address and port.

If no luck, describe your network path from ISP to PBX, including make/model of all hardware.

This seems strange; perhaps the logging isn’t working correctly. If the INVITE were blocked by FreePBX firewall, Call State would show CALL SETUP.

Let’s hope that a SIP trace will get logged and tell us what’s wrong. At the Asterisk command prompt, type
pjsip set logger on
sip set debug on

You should see
PJSIP Logging enabled
SIP Debugging enabled
Then call in from your mobile and paste the incoming INVITE and the reject response. Check both the console and /var/log/asterisk/full for any other related entries.

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