I have an issue where I can’t get inbound calls to work. out bound work just fine.
looks like part D is the issue. with no route it works. with ip:5060 the call route doesn’t work. I also have a static ip.
###UPDATE###
so with firewall on and set to internet (default firewall) 5060 was not working
I added the IP’s from flowroute and have inbound calls working now.
Problem Resolved - see Edit #2 below
Resurrecting this thread a year later . . .
I’m having massive problems trying to get a FreePBX pjSIP working with one of Flowroute’s new POP subdomains. Works perfectly with the legacy domain in Nevada, using a chan-SIP without requiring any port forwarding in my router, or allowing anonymous or guest SIP calls. I’m not using the FreePBX firewall (module isn’t installed). If I switch over to one of the new POP subdomains on Flowroute’s configuration page, and switch trunks to a pjSIP set up per Flowroute’s instructions, which parallel these for SIP registration, I can make outbound calls with no problem, but get near zero inbound. Perhaps one in 30 (or less) inbound calls works. I’ve been making a huge number of calls from a PSTN line and cell phone to troubleshoot this. Almost always gets nothing. Dead air. Times out after 30 seconds and quits with a hangup (calling end, not the PBX). A look at the logs shows an enormous number of “unsupported transport” errors. If I switch back to the SIP trunk and switch back to the legacy (Nevada) domain, everything magically works again and those errors disappear. Has anyone else encountered this? Anyone have a clue about what’s broken and how to fix it?
Edit:
Got the transport errors to go away - in the Asterisk SIP settings under the PJSIP tab - setting “Allow Transports to Reload” to “No”. Still no joy in Mudville. If I call out to my cell phone and then immediately call back in, it works, but only once. A second inbound and all subsequent inbound fail.
Edit #2:
It’s fixed - or appears to be. Incoming ring as they should. In the process I set up a Dynamic DNS for my Internet connection and set Flowroute to use routes with the Dynamic DNS URL with port number (5060 for pjSIP). Set parameters for that accordingly in the Asterisk SIP settings. I believe that improves reliability over using registration for inbound. Turned off FAX detection (but I don’t think this is what fixed it). Completely started over on the Chan_pjSIP trunk for one of the North America POPs and set the routes up in Flowroute to also use that same “edge strategy” in the inbound route using port 5060. When I enabled everything it started working properly. Something was wrong, perhaps with the trunk or some other setting, but if it’s not broken now I’m not going to continue trying to fix it. AFAIK, the method given for setting up the Chan_pjSIP trunk is good - as a review of my trunk and its setup - with the only deviation being using registration vs IP verification on outbound (also as outlined) doesn’t find any difference. Port forwarding across a router gateway of ports 5060 and 5160 to the internal (static) LAN IP address of the PBX is required when using the Flowroute routes sent to the WAN IP address for inbound (in my case using a Dynamic DNS URL) in lieu of SIP registration…
Thanks
John
You are incredible for doing this. Any way I can buy you a beer?
A problem I’ve run into that may help others:
In my Flowroute route config, when I set “Inbound edge strategy” to “Default edge strategy” inbound calls just absolutely will not work. Yes, I have set the default strategy in the registration tab; even deleted/recreated the route after setting the default strategy setting. If I set the Flowroute route to the same default I have in the registration tab it magically works.
Replicated on several Flowroute accounts and FPBX systems at this point, all with the same result. No idea why, but it works, and I can’t see any downside. Maybe add this to OP? Or not; I’m not your mother.
Using this guide, I setup a PJSIP Flowroute trunk and all was well. I did however (for some reason which I now forget) have the Direct Media option set to yes in the trunk. Everything was working perfectly for about a year. Then this weekend, I could get calls, but there was no audio either way. Looking at the logs and console during the live call, I noticed it said something similar to “direct media enabled.” So I went to the trunk, disabled Direct media, and then everything was well again.
So my question is: What is the proper setting for Direct media on a PJSIP trunk, when used with Flowroute? Also, can someone explain the reasoning/details behind the correct answer so I can understand it?
In the large, Direct Media should be disabled unless there’s a really good reason to enable it. With it enabled, the audio is not handled by the server and goes point-to-point from the endpoints. When disabled, this is the feature that allows things like call recordings to work. It also gets around a lot of “double-natted” audio problems, since both legs of the call come through the PBX instead of relying on open firewalls at both ends.
Thanks Dave. So Direct Media will have no impact on Flowroute and their Hyper Network, failover systems, etc? It might be a dumb question, but their hyper network/failover systems sometimes are a bit of a mystery to me in regards to how they work exactly.
I would expect not - in fact, it might make the whole thing work better, since each session is atomic to a specific ITSP server, so using the FreePBX server as your RTP aggregator is probably a good idea when it comes to your phones anyway.
THERE IS A MISTAKE IN THIS GUIDE …I may have missed this update in the existing comments as I only skimmed them.
Step 1B is incorrect. I called Flowroute when this guide didn’t work for me and they told me that the registration page PoP setting makes no difference unless you’re doing SIP registrations, for IP Authentication you need to set the PoP in the inbound route.
Go to Interconnection -> Inbound Routes, edit your inbound route, then select your preferred PoP in the ‘Inbound Edge Strategy’ dropdown.
The value ‘Default Edge Strategy’ does NOT mean the setting that you chose on the registration page (as I assumed), it means the Nevada PoP.
(From a bug report entered 4/17/20)
It is documented that trunks (and endpoints) which register in FreePBX are automatically whitelisted. This does not appear to be true on pjsip trunks when a CIDR is used in the Permit (Match) line of the trunk setup. Only the first registration whitelists. Subsequent invites on other IPs in the range are rejected. This specific example is Flowroute. If you want to Permit all of their new POPs, you enter the following on the Permit (Match) line in pjsip trunk setup (pjsip Trunk > pjsip Settings tab > Advanced tab):
34.210.91.112/28, 147.75.60.160/28, 34.226.36.32/28, 147.75.65.192/28, 3.8.37.20/30, 147.75.81.150/31, 18.228.70.48/30, 3.0.5.12/30, 147.75.42.200/31
However, as only the first registration whitelists all subsequent invites will reject making their global failover useless. To workaround, you need to explicitly whitelist the CIDRs in the firewall either by manually entering each of the above as Trusted under the Connectivity > Firewall > Networks tab in the GUI, or by cutting and pasting the following as root from the command line (I do individually to make errors easier to see):
fwconsole firewall add trusted 34.210.91.112/28
fwconsole firewall add trusted 147.75.60.160/28
fwconsole firewall add trusted 34.226.36.32/28
fwconsole firewall add trusted 147.75.65.192/28
fwconsole firewall add trusted 3.8.37.20/30
fwconsole firewall add trusted 147.75.81.150/31
fwconsole firewall add trusted 18.228.70.48/30
fwconsole firewall add trusted 3.0.5.12/30
fwconsole firewall add trusted 147.75.42.200/31
This solves the problem for Flowroute trunks. Other providers who use CIDR ranges for failover will require a similar solution.
It appears a fix is needed to get the firewall to pick up the explicit CIDRs listed in Permit (Match) instead of just grabbing the first IP to register on the trunk.
I see that it was you that identified the issue 16 months ago this week. Back then it might not have been as a big a deal but with chan_sip on death watch and even Sangoma’s own VoIP Innovations moving to CIDR-based failover solutions for pjsip it is critical that this either receive priority or that the workaround is better documented. Either would be satisfactory.
The “fraction” you mentioned in 2018 that will fail to complete on a /28 as Flowroute uses on each of their 4 POPs in the U.S. with true round robin load balancing and failover is 93% which is 1/14 (14 usable IPs out of 16). Stated another way, the chances of getting two back to back calls to complete successfully in this environment is 7%. This was my actual experience this week with over 200 test calls until I finally stumbled on the solution on my own. Going back to your December 2018 post, it is now a bit more than a feature request. It is at minimum an urgent documentation request since there is a very simple and viable workaround.
Thanks Lorne. Your posts have been very helpful since I started with VoIP back in 2016. I wish this one had turned up in my Google searches or community searches. It would have saved a lot of angst this week.
Workarounds for known bugs/issues would be a great chapter in the FreePBX wiki.
FreePBX has been running for 2 years straight without a problem but we needed to make a change with SIP provider and we chose Flowroute. Setup the PJSIP trunks with the instructions above and I can make incoming calls to all of our DIDs and hit our IVR and eventually internal extensions. However, when I dial an outside number I immediately get a “Your call cannot be completed as dialed, please check the number and try again”.
Ran asterisk -rvv and here is what I’m seeing -
[2020-06-12 19:31:43] WARNING[30902][C-00000024]: channel.c:5091 ast_prod: Prodding channel ‘SIP/223-0000002a’ failed
== Spawn extension (bad-number, 11, 7) exited non-zero on ‘SIP/223-0000002a’
Any help is greatly appreciated.
Cheers
You get this when the provider rejects the call with a 404 error or similar, or if the number dialed doesn’t match an Outbound Route.
Assuming that your routes haven’t changed, it’s likely the former. Note that Flowroute requires the destination number to start with the country code. For example 8004377950 is not valid, you must send 18004377950 or +18004377950. If you are dialing 10 digits (and not modified by the Outbound Route), or if you are dialing 11 digits and the Outbound route strips the initial 1, your Dialed Number Manipulation Rules for the Trunk should prepend a 1 on domestic calls. Be careful that 911 does not get modified.
If that’s not your issue, at the Asterisk command prompt, type
pjsip set logger on
and make a failing test call. Post the outgoing INVITE and the responses received from Flowroute. Note that if you are not using IP authentication, the first INVITE will be rejected with a 401 or 407; the second INVITE (with an Authorization header) and the resulting responses are what’s relevant.
Thanks for pointing me to the right direction. Problem resolved.
The first error message was due to not me allowing any of my extensions for routing under Outbound Routes>Extension Routing. Once I allowed my extensions, I was introduced with a new message - “All Circuits are busy, please try again” and I could see more info in the logs. The logs were reporting “Forbidden” response from Flowroute. The fix was a missing dial pattern in outbound routes and I can make calls out now.
Cheers!
Need help with set up anybody could help i’m willing to pay for the help or info asap please.
Here is their guide: FreePBX PJSIP Trunk Setup
Calls should start flowing to the new trunk almost immediately.
i also recall flowroute being a candidate for the context being set to from-pstn-e164-us
that no longer the case ?
From what I have seen, they send 1NXXNXXXXXX which that context does not do anything for.
Just wanted to add in here to help others.
In your section 2e, where you put in the IP addresses from flowroute.
I did that as they gave them. It was 34.210.91.112/28, 34.210.91.112-34.210.91.127. If you put that in, you get ZERO inbound calls. You will get a number disconnected or a ring then busy. It seems FreePbx chokes after the comma.
"2020-06-29 19:23:07] VERBOSE[23435] loader.c: Reloading module 'res_pjproject.so' (PJPROJECT Log and Utility Support)
[2020-06-29 19:23:07] ERROR[23435] res_sorcery_config.c: Unable to load config file 'pjproject.conf'
[2020-06-29 19:23:07] VERBOSE[23435] loader.c: Reloading module 'res_pjsip.so' (Basic SIP resource)
[2020-06-29 19:23:07] ERROR[13152] res_pjsip_config_wizard.c: Unable to load config file 'pjsip_wizard.conf'
[2020-06-29 19:23:07] ERROR[13152] res_pjsip_config_wizard.c: Unable to load config file 'pjsip_wizard.conf'
[2020-06-29 19:23:07] WARNING[13152] res_pjsip/config_transport.c: Transport '0.0.0.0-udp' is not reloadable, maintaining previous values
[2020-06-29 19:23:07] ERROR[13152] res_pjsip_config_wizard.c: Unable to load config file 'pjsip_wizard.conf'
[2020-06-29 19:23:07] ERROR[13152] netsock2.c: getaddrinfo("34.210.91.112-34.210.91.127", "(null)", ...): Name or service not known
[2020-06-29 19:23:07] ERROR[13152] res_pjsip_endpoint_identifier_ip.c: Identify 'FlowroutePJSIP' failed when adding resolution results of '34.210.91.112-34.210.91.127'
[2020-06-29 19:23:07] ERROR[13152] res_sorcery_config.c: Could not create an object of type 'identify' with id 'FlowroutePJSIP' from configuration file 'pjsip.conf'
[2020-06-29 19:23:07] ERROR[13152] res_pjsip_config_wizard.c: Unable to load config file 'pjsip_wizard.conf'"
Once I removed the IPs from the comma, BOOM. Incoming calls and no more errors. Yes, I had to read the IPs and not just cut/paste like Flowroute gave me a range 