I use Flowroute for my SIP provider. I use IP authentication with them. In the FreePBX trunk settings, I have their main address sip.flowroute.com, and I do not specify this anywhere else in FreePBX, or the firewall. Everything works perfect.
They just released new POPs. They say to take advantage of the new available POPs, you need to whitelist the new IP ranges below.
I just changed my router to forward the IPs as well and lo and behold no incoming calls come through.
I had to allow anonymous SIP connections, yes only Flowroute is allowed through so it might be ok, but I would prefer to not have to do that.
I opened a ticket with Flowroute and they told me to change to PJ SIP instead od CHAN SIP but that did nothing. So I would like to know how to set this up too, I’d hate to think I have to create an incoming route for each IP/DNS entry for those.
The reason they said this is they have /28’s for their POPs. That’s at least 13 IPs a single POP could deliver calls over. So for Chan_SIP, you would need a Chan_SIP trunk for each of the 13 IPs since Chan_SIP only supports a single “host”.
PJSIP will support multiple hosts and even ranges. So if you set Match (Permit): 147.75.60.160/28,34.210.91.112/28,147.75.65.192/28,34.226.36.32/28 You now have a single PJSIP trunk that will accept calls from any of the Flowroute POPs.
So how did you set this up and how did it “do nothing”?
Interesting enough, I went back and realized I had picked Oregon as my Edge Strategy. I went back and changed it to use Default Edge Strategy and turned off anonymous and it all worked.
But where are you making that setting to permit? In a config file or in the user interface?
Interesting. I had some troubles setting this up initially. And I followed the advice from this thread: Intermittent call failure for inbound calling, as well as implementing ip auth and routing, and prefixing the tech prefix, and disabling registration.
I guess I’ve been relying on asterisk to get the match ips from the domain. But it looks like that wasn’t actually getting the full range, even though it seemed to be working (except for 1 caveat I will explain momentarily).
These are the matches I got when I didn’t define an ip ranges in Match (Permit) setting:
Obviously, defining it like you did gives the whole, larger, range. I’m just curious about why the other way didn’t match all those too, and why it was working as consistently as it did. That being said, I did have a problem a few days ago that had me pulling my hair out. Asterisk wouldn’t match those IPs properly. It had been working for a long time, and then one of my servers went kaput. After much weeping and gnashing of teeth, I discovered it was a DNS problem. I’m still not exactly sure what part of the DNS was broken, but I’m pretty sure it had to do with Vultr’s DNS server. Once I switched to OpenDNS, things started working again. But what made this take longer to diagnose than it should have, is that I was still able to ping the Flowroute PoP domain. Asterisk just couldn’t create the match for some reason.
Also, @jestep, I don’t believe that by selecting Default Edge Strategy you are taking advantage of their failover capabilities. Setting it up to use the PoPs is the best and most reliable way.
I think this is an issue because my Trunk is not PJSIP it is CHANSIP which has NO advanced tab.
Thanks for posting, that helped me figure out where the advanced tab is lol
I will try this tonight and see if that fixes the issue. Flowroute support was useless in this issue. So then what do you think Default Edge Strategy does?? No failover?
From what I hear from Flowroute, you need to use the new PoPs to get failover, and you should also be using a PJSIP trunk. Here is an excerpt from an email I received when I opened a ticket about a problem I was experiencing.
There were some issues with our legacy POP today. We are still investigating the root cause.
Migration to the new POPs with failover would have prevented this issue.
If you are using an Asterisk based system please also migrate your SIP driver to chan_pjsip as chan_sip does not fully support SRV look ups which are required with the new POPs.
Woot, I got the PJSIP Trunk working today. Yea, I said I would do it later but decided to VPN into my home and try because I have to figure it out for my work.
So a bit of a pain, but now all is working! Thanks for the help in your posts! ANd I did go ahead and go back to the Oregon PoP with the match (Permit) set to 147.75.60.160/28,34.210.91.112/28,147.75.65.192/28,34.226.36.32/28
Correct me if I am wrong, but it seems all I needed was the General info filled out and that was about it?
I’m thinking about creating a start to finish how-to, because this is way too confusing than it should be.
I’m not exactly sure what you mean when you say “general info,” but I think there may be some more stuff that you need to do other than that.
I would take a look at the link I sent and go through that. Make sure the from domains are set (I’m honestly not exactly sure why this is necessary, but I think it’s best practice). I would also implement IP authentication (assuming that you have a static IP). To implement that, you need to do a few things. Change authentication and registration in the trunk to none. Prefix your dial string in your trunk. Disable credentials in Flowroute. And add your public IP to outbound IPs within Flowroute.
It is 100% required. The from domain is used as part of the authing process for their system. The domain isn’t a domain they “host” then you are not getting by.
As for their outbound pops you want us-west-wa.sip.flowroute.com (example) vs the IP(s) because they are using NAPTR/SRV to handle their failover. That means us-west-wa.sip.flowroute.com has multiple IPs that get used for that FQDN and NAPTR/SRV check that during DNS requests.
The issue with Chan_SIP, it took the first listed destination in the record. If it was down, it didn’t attempt to look at the others. So your trunk would be down. PJSIP actually handles NAPTR/SRV records properly and will continue to load the list until a working entry is found.
Because Inbound and Outbound are two different things. The Match setting is telling the PJSIP endpoint what IPs it will accept calls from. The contact_uri is telling PJSIP where to send calls to.
With PJSIP you could setup one trunk that can accept calls from various IPs, from multiple sources. That’s inbound. You could set multiple contact_uri’s for this trunk and when you route a call out it, it will send the call to all the contact_uri’s. Those contact_uri’s could in no way be related to the incoming match IPs.
When you set your contact_uri to sip:us-west-wa.sip.flowroute.com:5060 it is looking at the SRV record with each request. There is nothing else to populate for outbound calls for the SRV to work.
In contrast, it does not do an SRV lookup on inbound requests so you must Match the IPs that are sourcing the calls.