FreePBX & Bandwidth

FreePBX Providers
1

Hello everyone, I need some help and recommendations.
A quick note, I already googled the above subject and went through older threads dating from 2013 and newer and trying out different settings and recommendations.

It’s been a rough year for voip with all the DDOS attacks and our business lost a lot of reputation.
Initially we were with Voip.ms which for years haven’t been flawless (I don’t know if anyone can be) but their support has been exceptional. Up until they got destroyed by DDOS attacks. Which showed their infra was weak. They were down for a bit over 2 weeks.
In that first week we managed to quickly port out to Telnyx… who has had unreliable audio quality and mediocre service.

I now signed up with Bandwidth and our testing phase has been rough.

So our setup is the following.
On Premise FreePBX boxes for our clients, who would connect via sip trunk to the DID providers.

On Bandwidth, I create my subaccounts, locations with the internet static ip of the on premise PBX location.
On the router I port forward the requested ports from all.
(Which I would secure by strictly allowing the Bandwidth IP’s after I get it up and running)
I got the bandwidth guys change from e164 to US 10 digits.

I have tried a variety of different trunk settings.

Such as
(Outgoing)
host=216.82.227.122&216.82.237.134
port=5060
type=peer
allow=ulaw
dtmfmode=rfc2833
nat=yes
fromuser=+1**********
qualify=yes

(Incoming)
host=216.82.227.122&216.82.237.134
port=5060
type=peer
allow=ulaw
dtmfmode=rfc2833
reinvite=no
canreinvite=no
context=from-pstn
nat=yes
qualify=yes

Tried with and without fromuser=…
Tried with and without incoming
(No register string obviously as bandwidth doesn’t work this way)

Minor issue:
The only way I could get incoming to work, I have to enable Allow Anonymous Inbound SIP calls, which I don’t like. I was hoping I can have that to No with the inclusion of the Host IP addresses.

Major Issue:
On my office PBX, I can call out perfectly. I can take calls perfectly from their DID. (I haven’t ported main DID’s yet)

But I can’t call myself with their DID… it picks up but remains silent.

On 2 other PBX’s that I setup the exact same way, they can take in calls from their temp DID’s with bandwidth, but outgoing calls are stuck at all circuits are busy.

And if I call them from my office using bandwidth outgoing, it gives the same issue, no audio the same as if I called myself.

Tickets have been opened but I have been on this for days now and haven’t seen great progress.

I extracted some details from /var/log/asterisk/full

Note that below is from a different PBX Trunk. (not the one above but setup the same way)

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] pbx.c: Executing [s@func-apply-sipheaders:10] ExecIf(“SIP/EndoTMRBandwidth-00006504”, "0?Set(siphe$

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] pbx.c: Executing [s@func-apply-sipheaders:11] ExecIf(“SIP/EndoTMRBandwidth-00006504”, "0?SIPAddHea$

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] pbx.c: Executing [s@func-apply-sipheaders:12] ExecIf(“SIP/EndoTMRBandwidth-00006504”, "0?Set(PJSIP$

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] pbx.c: Executing [s@func-apply-sipheaders:13] EndWhile(“SIP/EndoTMRBandwidth-00006504”, “”) in new$

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] pbx.c: Executing [s@func-apply-sipheaders:5] While(“SIP/EndoTMRBandwidth-00006504”, “0”) in new st$

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] pbx.c: Executing [s@func-apply-sipheaders:14] Return(“SIP/EndoTMRBandwidth-00006504”, “”) in new s$

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] app_stack.c: Spawn extension (from-trunk-sip-EndoTMRBandwidth, 514*******, 1) exited non-zero on '$

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] app_stack.c: SIP/EndoTMRBandwidth-00006504 Internal Gosub(func-apply-sipheaders,s,1(1)) complete G$

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] app_dial.c: Called SIP/EndoTMRBandwidth/5141231234

[2022-04-12 08:35:52] VERBOSE[2291][C-000033aa] chan_sip.c: Got SIP response 500 “Internal Server Error” back from 216.82.227.122:5060

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] app_dial.c: SIP/EndoTMRBandwidth-00006504 is circuit-busy

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] app_dial.c: Everyone is busy/congested at this time (1:0/1/0)

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] pbx.c: Executing [s@macro-dialout-trunk:35] NoOp(“SIP/598-00006503”, "Dial failed for some reason $

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] pbx.c: Executing [s@macro-dialout-trunk:36] GotoIf(“SIP/598-00006503”, "0?continue,1:s-CONGESTION,$

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] pbx_builtins.c: Goto (macro-dialout-trunk,s-CONGESTION,1)

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] pbx.c: Executing [s-CONGESTION@macro-dialout-trunk:1] Set(“SIP/598-00006503”, “RC=38”) in new stack

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] pbx.c: Executing [s-CONGESTION@macro-dialout-trunk:2] Goto(“SIP/598-00006503”, “38,1”) in new stack

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] pbx_builtins.c: Goto (macro-dialout-trunk,38,1)

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] pbx.c: Executing [38@macro-dialout-trunk:1] Goto(“SIP/598-00006503”, “continue,1”) in new stack

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] pbx_builtins.c: Goto (macro-dialout-trunk,continue,1)

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] pbx.c: Executing [continue@macro-dialout-trunk:1] NoOp(“SIP/598-00006503”, "TRUNK Dial failed due $

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] pbx.c: Executing [continue@macro-dialout-trunk:2] ExecIf(“SIP/598-00006503”, "1?Set(CALLERID(numbe$

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] pbx.c: Executing [5146386366@from-internal:13] Macro(“SIP/598-00006503”, “outisbusy,”) in new stack

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] pbx.c: Executing [s@macro-outisbusy:1] Progress(“SIP/598-00006503”, “”) in new stack

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] pbx.c: Executing [s@macro-outisbusy:2] GotoIf(“SIP/598-00006503”, “0?emergency,1”) in new stack

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] pbx.c: Executing [s@macro-outisbusy:3] GotoIf(“SIP/598-00006503”, “0?intracompany,1”) in new stack

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] pbx.c: Executing [s@macro-outisbusy:4] Playback(“SIP/598-00006503”, "all-circuits-busy-now&please-$

[2022-04-12 08:35:52] VERBOSE[20596][C-000033aa] file.c: <SIP/598-00006503> Playing ‘all-circuits-busy-now.ulaw’ (language ‘en’)

[2022-04-12 08:35:54] VERBOSE[20596][C-000033aa] file.c: <SIP/598-00006503> Playing ‘please-try-call-later.ulaw’ (language ‘en’)

[2022-04-12 08:35:55] VERBOSE[20596][C-000033aa] pbx.c: Executing [h@from-internal:1] Macro(“SIP/598-00006503”, “hangupcall”) in new stack

[2022-04-12 08:35:55] VERBOSE[20596][C-000033aa] pbx.c: Executing [s@macro-hangupcall:1] GotoIf(“SIP/598-00006503”, “1?theend”) in new stack

[2022-04-12 08:35:55] VERBOSE[20596][C-000033aa] pbx_builtins.c: Goto (macro-hangupcall,s,3)

[2022-04-12 08:35:55] VERBOSE[20596][C-000033aa] pbx.c: Executing [s@macro-hangupcall:3] ExecIf(“SIP/598-00006503”, “0?Set(CDR(recordingfile)=)”) i$

[2022-04-12 08:35:55] VERBOSE[20596][C-000033aa] pbx.c: Executing [s@macro-hangupcall:4] Hangup(“SIP/598-00006503”, “”) in new stack

[2022-04-12 08:35:55] VERBOSE[20596][C-000033aa] app_macro.c: Spawn extension (macro-hangupcall, s, 4) exited non-zero on ‘SIP/598-00006503’ in mac$

[2022-04-12 08:35:55] VERBOSE[20596][C-000033aa] pbx.c: Spawn extension (from-internal, h, 1) exited non-zero on ‘SIP/598-00006503’

2

OK, so the first thing I have to ask is what level of service did you setup with Bandwidth? Did you go through their retail division or did you signup as a SIP wholesale peering partner? Because those are two different beasts of services. This is an important thing to know.

Second thing, stop using Chan_SIP. It’s dead and no longer officially maintained or supported. It is being removed from Asterisk next year in version 21.

Third, you are setting up Chan_SIP completely wrong. You CANNOT have more than one host entry. This means host=216.82.227.122&216.82.237.134 is invalid. This is why you have to turn on anonymous calls so that it would just let anything in and not verify the host. You also have other wrong settings in Chan_SIP but I don’t support it anymore and I’m not going to have a back and forth on it. Move to Chan_PJSIP.

Finally, I use Bandwidth and if this isn’t the retail side and it’s the same side I use. Holy hell man, you are setting yourself up for a huge headache managing individual connections like this with PBX systems and NAT. This isn’t a setup that Bandwidth normally has on this side. Your individual NAT issues aren’t their problem. Also, this side of Bandwidth doesn’t do registrations and has the termination limited to allowed IPs you have to provide them. I can tell you right now they are not going to just start opening dozens of IPs for you from different locations for each of your PBXes. That’s now how this works and at some point when you start adding 10, 12 IPs they are going to question this.

1 Like
3

Hey, thanks for the reply.

Regarding retail or wholesale, the nice rep at Bandwidth didn’t inform me of any differences. I just told him my requirements and guided me through the entire process.

Thank you for your correction on the host, I was not aware. I never wrote 2 hosts like this in the past, I have been researching and trying new things.

I will test using PJSIP trunks right away.

Basically in the past 5-6 minutes, I was able to resolve the outgoing call issue with bandwidth.
on their portal, there are areas where we add the IP Address of the location. Only now did the Bandwidth tech tell me they have to manually whitelist any location IP that I Add. (I assumed it was automatic)

So, 1 part is resolved, the other part regarding no audio when calling DID’s under bandwidth may get resolved with a new PJSIP trunk.

Thanks again for the quick reply!!!

4

Yeah, so you signed up to be a voice partner. That comes with the expectation you know how to be a telecom provider. They are expecting the IPs you give them to be to your own switches not individual customers. While you can send calls to any IP they will not let you terminate calls from any IP. You have to request it.

They arent going to troubleshoot NAT issues because you shouldnt be behind NAT. The onboarding process they have you do with the call tests they want are for testing your network with them. Throwing up individual PBXes that are behind NAT makes it so each install needs to be tested the same way.

This is not a service like Twilio or Telnyx or Flowroute. That is what the retail side does. The setup fee and monthly commitments that you had to agree to with Bandwidth should have been the first indication.

5

Indeed, I was already aware that they are at the top of the food chain.
We easily surpassed their minimum requirements as have grown to a respectable amount of clients over the years.

We need stability, reason why I am happy to join Bandwidth in order to grow the business.

I have one last question.
Ill run some tests first and ask after if I can`t resolve.

6

That’s fine but just keep in mind, if you have 100 PBXes Bandwidth isn’t expecting you to submit a 100 IPs for termination. Sure you can make a 100 sub-account/locations and send calls to a 100 IPs but Bandwidth isn’t going to allow that for termination.

If you are going down this route you are going to need something like a proxy/softswitch in between your customers and Bandwidth. You have Calls Per Second to monitor, you have other things to deal with like routing. They are expecting you to manage the call flow that hits them.

You also need to file with the RoboCall Mitigation Database and have an actual mitigation plan, Bandwidth will be required to not allow your calls to terminate if you are not filed. Just keep in mind, you are now putting yourself at level where Bandwidth, the FCC, et al expect you to be aware of all the compliances you must meet and follow regulations. There is going to be a certain amount of low level support and information they will not just offer up because, again, the expectation is you know these things. Also, sales guys don’t mention all the technical stuff and leave that to the techs who assume even more that you know what you are doing.

1 Like
7

I agree 100%
For now we have about 10 PBX`s. Our clients have receptions who take calls all day. (mostly Dental and Medical fields.)
We already filed and are listed and have an actual Mitigation plan.

I know what I am doing and I admit I still have a lot to learn.
Well, in I.T. there is simply an infinity to learn.

Setting up a Proxy/softswitch between Customers to us to Bandwidth will be looked at.
If you have any links or recommendations, that would be greatly appreciated.

In the end, I am always transparent and Bandwidth were happy to take us in and offer as much help.
Today they have been very helpful and I must give credit to their team.

Thanks again for the help.

8

Just in case it helps anyone who googles pjsip settings for Bandwidth and falls here, the following worked for me.

General
Authentication: None
Registration: None
Sip Server: 216.82.. (this would be provided by Bandwidth)
Sip Server Port: 5060

Advanced Tab
DTMF Mode: Inband
Send Line in registration: Yes
Send Connected Line: No
Permanent Auth Rejection: No

(Defaults)

user = Phone: No

From Domain: Your Static IP Address here
From User: Your Static IP address here

Trust RPID/PAI: Yes
Send RPID/PAI: Both
Match Inbound Authentication: IP
Inband Progress: Yes

9

This is unlikely to be the preferred choice.

This will do nothing given you have Registration: none.

10

Absolutely not. Why would you put an IP there?

11

Also they dont use RPID, so that isn’t needed and you should be using RFC4733 for DTMF. This would have been provided and is in their support portal documents.

12

DTMF Mode, Only Inband works properly.
If I put it on a different setting, I can call in and out outside of bandwidth perfectly.
But any call to any DID`s within Bandwidth are instantly picked up with silence.

Send Line in Registration.
If this option is enabled, a “line” parameter is added to the outgoing “Contact” header during registration.
You are right.

13

I will run more tests soon this afternoon.

I tried RFC4733 and any calls to numbers under bandwidth would be instantly picked up with nothing on the other end.

I recall having all circuits are busy when I removed the RPID, but again, I will double check and test all those settings soon.

Thanks for the input.

14

Supported DTMF

Bandwidth supports both in-­band and out-­of-­band Dial-Tone Multi-Frequency (DTMF) outlined in RFC2833.

RFC4733 supersedes/replaces RFC2833. I have Asterisk systems sitting behind my softswitches which do not touch in call audio and using RFC4733 works just fine.

As for RPID it is still an option. I thought they dropped it since it’s a failed RFC.

I’ve got to ask a serious question, these PBX systems are at least in the cloud and on public routed IPs and not sitting behind NAT? Right?

15

Physical machines on Premise behind a NAT router.
In the past I never had to open any ports and when I do they are from specific sources.
VPNs are used for remote extensions.

I realized that locations without a static IP wouldn’t work with bandwidth.
Their team has been very helpful and the Rep I spoke to was absolutely amazing tho I did specify every detail about how I was setting things up and it was confirmed: “Sure, no problem”

Which is fine by me, I learn and I update.
I will be setting a PBX in a cloud tomorrow and run additional test.
Previously everything just always worked perfectly. Time to upgrade.

16

OK man, I’m going to be straight with you here. I’ve been with Bandwidth since the mid-00’s. Every place I’ve been at either already had a partnership with them or I made the partnership happen. They will bend over backwards for you, to a point. They are onboarding you right now, they are making sure that happens. At some point, however, their support and kindness can only go so far. Once they pass the ball back to you on an issue for any reason, including “It’s not our issue to fix”, what are you going to do?

Let’s clarify something right now. Your current business model of connecting 10 different PBXes straight to Bandwidth means you do not have your own network. By the virtue of that fact the one thing that means is your RoboCalling Mitigation Plan is worthless. The plan is around how you are going to mitigate robocalling in/out of your network. You don’t have one of those, so how are you going to mitigate robocalling when you have no real control over the network it is entering/leaving?

I’m also curious, did you sign up for their DLR services or just doing old school 911 with assigning a DID per location? If it is the former, you do realize that it requires a different IP to terminate calls from? Meaning you can’t use it at a customer location unless that customer has two IPs, PSTN calls go over one IP while 911 calls go over the other. You also need to attach a custom header to each 911 call.

If it is the later, then you can use the same IP as the PSTN termination but you need to get a DID per location that needs to be registered. With the new 911 laws that means your dental and medical offices that have numerous rooms/offices and possibly multiple points of ingress/egress means you have to have exact locations for each phone. That means if your dental office has phones in Room A, Room B and Room C as well as reception area you need a location registered for each room and the reception. 911 needs to see that the call came from Room A or B or C.

I’m just making sure you are thinking about this stuff. Because this isn’t sounding well thought out based on the conversation so far.

1 Like
17

I’m sticking with VoIP.ms

18

What does that have to do with anything involving this thread?

19

OK man, I’m going to be straight with you here. I’ve been with Bandwidth since the mid-00’s. Every place I’ve been at either already had a partnership with them or I made the partnership happen. They will bend over backwards for you, to a point. They are onboarding you right now, they are making sure that happens. At some point, however, their support and kindness can only go so far. Once they pass the ball back to you on an issue for any reason, including “It’s not our issue to fix”, what are you going to do?

Not a problem at all. As I said from the start, I am not looking for kindness. Only a reliable network.

Let’s clarify something right now. Your current business model of connecting 10 different PBXes straight to Bandwidth means you do not have your own network. By the virtue of that fact the one thing that means is your RoboCalling Mitigation Plan is worthless. The plan is around how you are going to mitigate robocalling in/out of your network . You don’t have one of those, so how are you going to mitigate robocalling when you have no real control over the network it is entering/leaving?

I have control over the network of all installed PBX’s. In fact I manage everything related to I.T. for all those locations. In a way, those are all my networks.

…

If I go with Bandwidth, I will certainly migrate over most of my PBX’s to a cloud.
Everything I do is secure and well documented.

Thank you for your help and advice.

20

That is not how this works. So you are going to install a mitigation solution on each PBX that is going to deal with robocalling coming into and out of their PBX?

See if a bad actor robocalls one of your customers, sure you can block them there but then you are required to block them completely. From all your network. So now you have to update each PBX because their all your network based on your logic.

And you still havent answer my 911 question. Because that is something as the PBX admin you need to do. If you dont have proper dispatchable locations and the PBX configured properly for it, you are violating federal law.