NEW The Taming of FusionPBX + Tutorial

[hecatae]

Job for freeswitch.service failed because the control process exited with error code.
See "systemctl status freeswitch.service" and "journalctl -xeu freeswitch.servic e" for details.

I guess 1GB RAM and SWAP is insufficient for the install

 

[wardmundy]

I guess 1GB RAM and SWAP is insufficient for the install

That kinda depends. It's what we're using at HostMedia, and we actually did the install without a swapfile which we manually added after the install finished. We've had mixed results with same sizing elsewhere. RackNerds worked and included a 1GB swap file. ColoCrossing with the same setup failed multiple times. Minimum 2GB RAM is what Debian recommends for Debian 12.

 

[hecatae]

@wardmundy thanks for the warning on colocrossing, it was fasthosts that fusionpbx failed to install on.
Now to try on Oneprovider.

 

[kenn10]

It works on CrownCloud and RackNerds. At least it installs. As to FusionPBX working, that is another whole issue that is unrelated to the VM you run it on. The learning curve is very steep and painful.

 

[wardmundy]

It works on CrownCloud and RackNerds. At least it installs. As to FusionPBX working, that is another whole issue that is unrelated to the VM you run it on. The learning curve is very steep and painful.

Agreed. If frustration causes your blood pressure to spike, this is NOT the platform for you!

 

[kenn10]

Agreed. If frustration causes your blood pressure to spike, this is NOT the platform for you!

I recommend Valium or a good stiff adult beverage before undertaking it.

 

[pbxnerd]

@wardmundy Glad to hear about your success and see that it appears my original post here sparked something that turned into a full tutorial on your blog! I’m glad it ended up working out for you. FusionPBX is absolutely the best kept secret in voip. It does indeed have a learning curve. But like most achievements in life, the easiest things to learn may not be the most rewarding and the hardest things to learn often pay the most richly in eventual dividends! @markjcrane is my hero.

 

[wardmundy]

Finally got BulkVS working. Here are the screenshots on the FusionPBX side that you'll need to copy:







NOTE: Destination in the last screenshot and From User in first screenshot both are your 10-digit BulkVS DID. Must be 10 digits or outbound calls to Verizon will fail. Very weird that Verizon won't accept incoming calls with a 1 prefix, but it will ring busy all day long. T-Mobile works just fine. Didn't try AT&T.

 

[kenn10]

The Bulkvs gateway is one of the few things I got to work almost immediately. You need to be sure to set SIP CID type in the advanced section of the gateway or it just sends "FreeSwitch" as the CID Number.

 

[wardmundy]

So that gets the FusionPBX side squared away to support BulkVS. On the BulkVS side, here are the steps:

1. Build new SIP Registration Trunk Group with new acct name & pw & 11 digits
2. Purchase a new DID in Inbound -> DIDs - Purchase
3. In Inbound -> DIDs - Manage select * as wildcard and Search
4. Find your new DID and click View
5. For the CNAM, enter the 11 digit DID. For Trunk Group choose new one from step #1 & SAVE

 

[wardmundy]

If you followed the Nerd Vittles tutorial first, you now have all the pieces to add a second trunk for BulkVS. Build the Gateway for BulkVS first using the sample image above.

Now, for the new Outbound Route, the trick now is to use a dialing prefix in the Outbound Route of one of the two trunks so that you can make calls from either one. Note that a prefix in FusionPBX is just the opposite of what it means in FreePBX so don't add a Prefix when you build the BulkVS Outbound Route in the way shown in the image above. After saving the new Outbound Route, edit the Outbound Route Dialplan for BulkVS and do two things:

1. Change the route's Order from 100 to 99 so that it gets processed BEFORE the VoIP.ms Outbound Route
2. Edit the condition line so that it looks like this: ^9(?:\+1|1)?([2-9]\d{2}[2-9]\d{2}\d{4})$

That tells FusionPBX to throw away the 9 when somebody dials an 11-digit number starting with a 9.

Then the Outbound Call will go out the BulkVS DID instead of 10-digit Outbound Route for the VoIP.ms trunk.

Finally, create the Destination (a.k.a. Inbound Route) using the sample image above and you're good to go.

 

[wardmundy]

A treasure trove for the VoIP Blacklist... At least compromised Windows machines are good for something.



UPDATE: Attacks totally stopped after 2 days.

 

[kenn10]

I'm only getting a couple of attempts per day. Belgium, the Netherlands and Ramallah are the primary attackers now. They're hitting the IP address rather than the DNS name.

 

[wardmundy]

I'm only getting a couple of attempts per day. Belgium, the Netherlands and Ramallah are the primary attackers now. They're hitting the IP address rather than the DNS name.

This is actually our ColoCrossing device which came back to life on about the 8th reinstall. Kinda shows how vulnerable their platform is... from top to bottom.

 

[pbxnerd]

Although it's not the cheapest, also consider that Telnyx trunking has some unique security benefits:

1. Telnyx publishes fixed, documented IP ranges for both SIP signalling and RTP media. (Unlike most trunking providers where the RTP IPs are unpredictable). This means you can run an incredibly locked down PBX, where you have NO PORTS exposed to the public internet! You can lock the whole system down to the RTP IPs, SIP IPs, and static IP's of your phone locations. This is a highly secure way to run a PBX! If you need roaming capability for mobile phones, consider Ringotel, which acts as a proxy to the phone client. You can whitelist Ringotel's IPs on the PBX, and then they proxy to you anywhere your mobile phone is in the world. I've been using Ringotel for years and find their product works quite well.

2. Telnyx supports the Opus codec on their trunks, so you can run your entire PBX on the Opus codec only. Then you can turn on Telnyx's trunking call quality enhancement feature. I'm doing this and call quality is just absolutely stunning.

3. Telnyx supports secure SIP trunking that uses TLS 1.2 to encrypt all SIP signalling and SRTP to encrypt the RTP media stream, giving you protection both between your IP phone and PBX and on the trunk between the PBX and Telnyx’s SIP edge. Works beautifully with Fusion PBX.

Might want to give it a try!

 

[wardmundy]

AI Question of the Day

Q: Is there a way to make calls from extensions on one domain of FusionPBX to extensions on another domain hosted on the same server?


A: Yes, it is definitely possible to make calls between extensions on different domains hosted on the same FusionPBX server. FusionPBX is designed with multi-tenancy in mind, allowing you to manage multiple separate "domains" (tenants) on a single FreeSWITCH instance.

Here's a breakdown of how it generally works and the common methods to achieve inter-domain calling:

Understanding FusionPBX Domains and Contexts

In FusionPBX, each domain acts as a separate tenant with its own extensions, dialplans, and settings. FreeSWITCH uses "contexts" to separate these domains. By default, extensions within one domain are not directly aware of extensions in another domain. To enable communication between them, you need to configure specific dialplan rules.

Methods for Inter-Domain Calling:

1. Using a Prefix and Dialplan Rules (Most Common and Recommended):This is the most flexible and scalable approach. You define a specific prefix (e.g., *8, 999, etc.) that users will dial before the extension number of the other domain.
   • How it works:
     • An extension in domainA.com wants to call extension200 in domainB.com.
     • The user dials something like *8200.
     • You create an Outbound Route or Advanced Dialplan in domainA.com that matches this prefix pattern (e.g., *8(\d{3})).
     • In the dialplan, you use actions to:
       • Set the domain_name variable to the target domain (e.g., domainB.com).
       • Set the domain_uuid variable to the UUID of domainB.com (you can find this in Advanced > Domains).
       • Use the transfer application to send the call to the target extension within its correct context: transfer $1 XML ${domain_name} (where $1 captures the extension number after the prefix).
   • Benefits:
     • Clear and structured dialing.
     • Easy to manage and expand as you add more domains.
     • Allows you to control which domains can call which.
   • Configuration Steps (General):
     1. Get Domain UUIDs: Go to Advanced > Domains and note down the UUID for each domain you want to enable inter-domain calling for.
     2. Create an Outbound Route (or Advanced Dialplan):
        • Navigate to Dialplan > Outbound Routes (or Dialplan > Dialplan Manager for advanced rules).
          
          
          
          
        • Click "Add" or "Edit" an existing route.
        • Define a Dialplan Expression (e.g., ^*8(\d{3})$ for a prefix of *8 followed by 3 digits).
        • Add Actions:
          • set domain_name = your_target_domain.com
          • set domain_uuid = your_target_domain_uuid
          • transfer $1 XML ${domain_name} (replace $1 with the captured extension number)
     3. Repeat for each domain: You'll likely need similar rules in each domain that needs to initiate calls to other domains.
2. Enabling the is_local Dialplan Rule:FusionPBX has a built-in is_local dialplan script (often a Lua script) that can be enabled. This rule attempts to determine if a dialed number exists as an extension in anydomain on the server and routes it internally if it does.
   • How it works: DOESN'T WORK!
     • If is_local is enabled, when a user dials an extension number, FreeSWITCH will check if that extension exists in the user's current domain's context.
     • If not found, it can then check other domain contexts for a matching extension.
     • If a match is found, the call is routed internally to that extension, even if it's in a different domain.
   • Benefits:
     • Simpler dialing (no prefix needed).
     • Can be useful if all extensions across all domains should be callable directly by their number.
   • Considerations/Drawbacks:
     • Potential for conflicts: If you have the same extension number in multiple domains (e.g., 101 in domainA.com and 101 in domainB.com), is_local might route to an unexpected domain or require more complex logic to resolve.
     • Less granular control: You lose the ability to restrict calls between specific domains as easily as with prefixes.
     • Might require modifications to the is_local.lua script for specific behavior.
   • Configuration Steps:
     • Go to Dialplan > Dialplan Manager.
     • Look for a dialplan entry named is_local (it's often disabled by default).
     • Edit it and enable it. You might need to examine the is_local.lua script (usually in /usr/share/freeswitch/scripts/app/is_local.lua) to understand its exact behavior and if any modifications are needed for your specific scenario.

Important Considerations:

• Numbering Plan: It's highly recommended to have a clear numbering plan across your domains, especially if you plan to use is_local or want to avoid confusion with prefixes. For example, domainA uses 100-199, domainB uses 200-299, etc.
• Caller ID: Ensure your dialplan rules correctly handle caller ID presentation when calling between domains. You might want to prefix the caller ID name with the originating domain's name for clarity.
• Permissions: Make sure the user roles and permissions allow access to modify dialplans and other necessary settings.
• Testing: Thoroughly test all inter-domain calling scenarios after making changes to ensure calls are routing as expected.
• Documentation: Refer to the official FusionPBX documentation (docs.fusionpbx.com) for the most up-to-date and detailed instructions on advanced dialplan configurations.

In most multi-tenant FusionPBX deployments, using a prefix-based outbound route approach for inter-domain calling provides the best balance of control, clarity, and scalability.

 

[wardmundy]

Gotcha of the Day

Calling from some of our new BulkVS numbers to Verizon numbers are being blocked by Verizon as SPAM.

BulkVS Response:

Call Blocking & Whitelisting Links

WHAT'S HAPPENING?
CARRIERS HAVE BEGUN TO BLOCK AND ID OUTBOUND CALLS IF THEY APPEAR UNWANTED OR FRAUDULENT
In an effort to protect consumers against abusive robocalls, carriers are increasingly implementing call blocking programs and Spam Likely Call IDs.

Bulk Solutions has observed AT&T, Verizon and T-Mobile increasingly blocking calls and tagging calls as spam that they feel fit typical robocalling campaign characteristics such as high-volume, short-duration calls originating from a single number.

WHAT DO I NEED TO DO? PROACTIVELY REQUEST WHITELISTING OF LEGITIMATE OUTBOUND CALLING USE CASES
There are many, many legitimate use cases for high-volume, short-duration calls including school closing notifications, weather alerts, and patient reminders. These are entirely valid and legitimate use cases where recipients want to receive these calls and have opted-in to receive these calls; however, when viewed en-masse at the network level, they can look like illegal robocalling.

In order to ensure your outbound calls are not miscategorized as unwanted or fraudulent calls by the wireless carriers, we highly encourage you to proactively request whitelisting of legitimate outbound calling use cases from each of the major wireless carriers.

Below are websites where you can submit whitelisting requests:

• AT&T/Wireless/Call Protect/HIYA
• Verizon/Wireless/TNS
• T-Mobile / FirstOrion / PrivacyStar
• https://freecallerregistry.com/fcr/

 

[Samot]

Gotcha of the Day

Calling from some of our new BulkVS numbers to Verizon numbers are being blocked by Verizon as SPAM.

BulkVS Response:

You're sending proper CallerID in either RPID or PAI format since you're using registration?

 

[wardmundy]

@Samot: I think you just won the t-shirt...

 

[Samot]

@Samot: I think you just won the t-shirt...

View attachment 6014

Nice shirt. I would wear it. Still doesn't answer the question.