I’ve had PBIAF / Asterisk running since 2010, no issues. I gave up trying to update to a version which supports PJSIP and instead installed the latest, fresh version of FreePBX. I went through the How-To Guide for Flowroute below and running into some issues:
The trunk registers, the routes for my DID’s work. However, if the phone is offline, instead of going to voicemail it either gives dead silence or a message that I’ve dialed an unworking number. Surely this is not the way it’s supposed to work. What have I done wrong?
I cannot get my CISCO SPA112 2FXS to register. I’ve tried both versions of SIP on both ports – 5060, 5160 and it just won’t work. It was working fine days ago on my old system.
Because of #2, my remote IP to the system keeps getting banned in IP Tables, even though I’ve added it as a trusted host in the FreePbx firewall.
It would be quite prudent to speak to FlowRoute Support about #1, as well. We have several hundred customers who use FR and the transition to their new PoPs has been nightmarish, to say the least. FlowRoute Support has changed up their “preferred” configuration no less than 3 times in as many weeks in an attempt to get everyone on the new PoPs. We’ve even seen FR Support setup completely different trunk configs on different FreePBX systems ON THE SAME FR ACCOUNT…which means they have been doing a lot of custom individual setups on THEIR end to work around their botched deployment of these new PoPs. It didn’t help that they decided it would be great for customer satisfaction to give folks 2 weeks notice that they were killing the original termination URI…without even ensuring that their paying customers were transitioned over. I guess they didn’t take into account that some of their customers have DOZENS of systems to migrate and that some of them operate 24/7/365 and have to very carefully schedule their maintenance/downtime (and, well, Pandemic, staff shortages, economic downturn, etc might get in the way of a speedy transition)…or they just don’t care. Based on the attitude most people seem to be getting from FR Support, it seems to be the latter. That said, contacting them is the only sure-fire way to ensure that what you are configuring is matching theirlatest attempts and [possibly undocumented] changes.
Enabling Force Answer may help #1, but we saw this same symptom on a few others and they did have Force Answer already enabled. It took a call to FR support to sort out the root cause.
In other words, the documentation you used to setup the new PoPs could be wildly different from the current reality on their end, even if they last updated the docs a just couple days ago. Talk to FlowRoute Support. In just about every instance that a customer has reached out, FR has gotten them sorted out…one way or a-dozen.
[I was about to go on a rant about how PJSIP has done as much to improve the world of VoIP as it has to over-complicate it, but it’s all been said before. ]
I came home tonight & magically the Cisco FXS works as well as another one of my DID’s.
What I am wondering – Is there a time delay (sort of like browser caching or whatever analogy one wants to use) when you set a route in the Flowroute dashboard for a DID? If so, how long?
Edit: Too excited, too soon. I still have the dead air problem if the phone is offline or on DND when it should go to voicemail.
Agreed on all of these points. I am of the opinion that all of this stuff should just “work” easily and uniformly. Since this is a FreePBX board with FR customers, I can’t possibly see how all of us have different configurations for the same basic thing – DID & FreePBX. It should just work. If it can’t be resolved rather quickly, I’ll simply port my numbers over to another provider (of course after testing things work there).
I’m starting to think the dead air issue has to do with FreePBX / asterisk, possible a codec or firewall. Not sure, but when I dial an extension in the system which is offline (which of course does not go through the flowroute trunk) I get dead air.
The default selected codecs in FreePBX are ulaw and alaw (gsm is also enabled on some versions at launch, but it’s placed 3rd in the priority list), which are pretty much universally supported by everything out there…so it probably isn’t a codec issue.
You’ll want to consider your network/firewall and how you are sending your audio with PJSIP. Extension settings like RTP Symmetric and Direct Media could come into play here, depending on how your PBX is positioned relative to your endpoints (within the network, NAT’d from the outside, etc).
I ran into a problem setting up a “converted” PJ-SIP connection where the system reported a problem with the 0.0.0.0.udp transport. I had to go into the trunk settings and specifically select it and then reboot the server to pick up the change. I’ve seen a couple of reports of similar problems on these FR updates.
I hate to admit this, but most of the issues came down to a stupid mistake – I had “WAN ADDRESS” on my firewall for ports 10000-20000 placed in both the source address and destination address instead of just destination address. That cleared up most of the remaining issues.
I am still wondering if there is a “time delay” / cache period involved when changing settings on the Flowroute site, since it took over a day for the telco disconnect messages to go away and I still get it on other routes.
Will need to do more testing to make sure the big issues are properly resolved and it’s not randomly working.
Just some color commentary from the peanut gallery, as if anyone wants to hear it Flowroute was definitely once considered top-notch in terms of innovation, support, and quality. Whatever is going on there now seems to be the effect of them changing hands – is it twice? I can’t tell whether the West/Intrado thing was one move, or two. Given that they are a more expensive player in the field and value has gone down, some folks might be better off jumping ship and changing to something better.
For now, major issues resolved. Still some minor quirks.
FYI: Dear Flowroute,
It is a REALLY BAD idea to mess with anything having to do with communications while Mercury is Retrograde (June 18 - July 12). Next time, please check and have your deadlines / major planned work done at a more conducive time.
After acquiring Flowroute, West also bought Intrado and changed their name to Intrado, similar to SBC’s purchase of AT&T and renaming themselves AT&T.
I agree that they are expensive and there are lower cost reliable choices. However, IMO it’s only support that has degraded; calls still get reliably terminated and originated. I hope that after merger issues have settled down, support will return to its previously stellar level.
Most of the recent complaints seem to be related to registration, which I’m guessing is used by only a few percent of customers. A business too small or on too tight a budget to have a static IP address is likely to choose a ‘value’ provider over Flowroute.
“I agree that they are expensive and there are lower cost reliable choices. However, IMO it’s only support that has degraded; calls still get reliably terminated and originated. I hope that after merger issues have settled down, support will return to its previously stellar level.”
That said, I’d like to keep them for my incoming DID’s and outgoing office calls. Everything has worked nearly flawlessly for years. However, I am looking for a different trunk provider to handle blasting, primariliy due to cost and separation from my main business lines. Any recommendations which work well with the call center add on / Xact Dialer commercial package would be appreciated.
Oh yeah, without a doubt. They used to be at the top of our list of recommendations along with Twillio and a few other big friendly international players.
When Twillio made the switch to AWS and PJSIP PoPs, they were agile and informed about it. They intentionally kept their old termination URIs up (to this day, mind you) because they know that there are just some cases where it will be needed. They communicated clearly to customers during the transition and left NO ONE behind.
FlowRoute, on the other hand, has been a slow, yet steady descent into shite in recent years. How they handled their AWS/PJSIP transition is just the latest huge example of how they don’t give a damn about their customers for even a second…and it’s a company-wide culture at this point, all the way down to the L1 Support. We really do try to remain agnostic in making trunking suggestions, but now we’re firmly in a position to say to our customers, “port to someone else if you value quality of service and support moving forward.” We just can’t trust FR to do right by their/our customers anymore.
Even when you are a large company with hundreds/thousands of endpoints and possibly dozens of systems for multiple locations…good support is vital and quality of that support is a key factor in determining the direction a company is headed. If you can’t do well supporting your own product, what am I supposed to do when it does eventually fail in some way? Nothing is 100% uptime…absolutely nothing.
In fact, I’d argue good quality support from a vendor is even more important for larger corporations. If a small business has a problem and can’t get calls, they lose a few CPH until it is resolved and can be far more agile in dealing with such a small-scale outage. If a large call center…or twelve…go down, that’s countless thousands of CPH and potentially hundreds of thousands of dollars in revenue gone for every hour it’s down. That’s not even counting the bad PR and customer opinion storm that almost always follows a major outage at a big company. You need not look any further than the recent cries for Federal investigation of T-Mobile after their recent outage for an example of that ire. Outages happen, but having shite support when it does amplifies the effects of it a thousand-fold for everyone involved.
I just got off the phone with FlowRoute support. With the new POPs my outbound calls worked fine, but DIDs failed (after retirement of the Nevada POP) with a 401 back to FW. After much fiddling and some friendly but not too knowledgeable support people at FW we found the problem. Their documentation for setting up the new POPs assumes you have no other need for CHAN_SIP. CHAN_SIP and CHAN_PJSIP can not share the same port (5060). SO…if you still have CHAN_SIP enabled inbound you need to configure an alternate port for CHAN_PJSIP. You’d need to change the listen port in the trunk setting, you’d have to open up the AWS Security Group setting to allow the alternate port (e.g. 5160), AND you have to alter the Route FW sends the calls to by appending the port (e.g. sip.myserver.com:5160). Assuming you have everything else right in your configuration you should start getting calls from FW again.
This is just a reminder the FreePBX will give an outside caller a very official sounding “The number you have dialed is not in service” message, if there is no good Inbound Route or inability to reach the assigned extension. Only a SIP packet trace on the FreePBX machine (ala SNGREP or similar) will tell you for sure if this issue is the SIP Trunk provider or yours. Having your PBX’s SIP capture to compare with Flowroute support for troubleshooting also makes the finger pointing and their ability to help you better.
PJSIP has the ability to provide the failover list of SIP POP’s in the setup, that SIP did not. This plays strongly into the hand of the Flowroute preferred POP and backup POP strategy. Be sure to get this setup at Flowroute via your management portal, also in your FreePBX firewall and network firewall.
We switched away from using Flowroute SIP Trunk registrations and strictly use IP authentication. This has worked great from day one.
The transition to the new POPs has had its bumps. I fought for a day and a half with getting it to work and finally had to get the magic missing sauce (don’t use default edge strategy) from support. That took a ticket and finally a call to support to find out what was wrong. It probably would have saved them a lot of work to put a big banner up that said “DON’T USE DEFAULT EDGE STRATEGY WITH THE NEW POPS!” Except for that, the transition wasn’t too bad once I accepted the fact it was a good time for a fresh FreePBX install to replace a server I provisioned over 10 years ago.
It didn’t help that they decided it would be great for customer satisfaction to give folks 2 weeks notice that they were killing the original termination URI…without even ensuring that their paying customers were transitioned over
I’m not where this claim comes from. I’ve been getting emails about the retirement of the Nevada POP for six months. Yeah, the transition was rough and their support was overwhelmed, but claiming they did this on short notice is completely untrue.
They gave 6 months notice of their intentions…but didn’t bother to lay out proper documents and support for the switch over until nearly 2 weeks before pulling the plug (sorry for not being more clear on that bit); it was at this point that we and the mutual customers we support scrambled to seek resolution for issues that had been being reported to FR about the new PoPs for MONTHS. They then changed the documentation on their site repeatedly but weren’t updating the timestamps/metadata for the pages, so it was very hard to tell what documentation was the most recent. Not even their own support seemed to know which was the most current recommended doc to follow, internally or otherwise…so the communication breakdown happened inside and out.
Until they finally got their support team all on the same page, we counted no less than 7 different resolution paths for our AWS Customers, and nearly all of them required FR Support intervention to make changes on their end before the customer was fixed up. Even now, some of these “early adopters” are using “beta” configs that may or may not work in the future. It was a poor roll-out and they could have handled it much better than they did. As one of the top global trunking providers, we expect a higher level of competency in these situations from a company like FlowRoute. Can they be redeemed? Sure…but they upset a LOT of customers in this case, and I doubt those customers will ever return and you better bet they will tell their colleagues of their experience.
]
Flowroute was definitely once considered top-notch in terms of innovation, support, and quality. Whatever is going on there now seems to be the effect of them changing hands – is it twice? I can’t tell whether the West/Intrado thing was one move, or two. Given that they are a more expensive player in the field and value has gone down, some folks might be better off jumping ship and changing to something better.