FreePBX used as a trunk gateway proxy only

Hello Community

After a thorough evaluation I decided to go for freepbx!! And we are very excited about this decision.

However, I have some questions:

If the freepbx installation is used purely to deliver trunk connections and inbound routes, can I safely remove any components that I do not need?

For example - On a particular freepbx installation I will only use TRUNKS and INBOUND RULES. Absolutely nothing else.

Q1: Should I disable, Uninstall or remove components I do not need?
Q2: Can I remove UCP and HTTP API?
Q3: How can I be sure that I do not remove something that is not used by the core modules?

Any help would be greatly appreciated.

Look at Kamaillo as an alternative. FreePBX and Asterisk are a Back to Back User Agent, and definitely not what you’re describing.

1 Like

As @cynjut correctly stated, you might prefer to use a SIP proxy server instead, Asterisk being a B2BUA is theoretically not designed to act as a proxy.

1 Like

Thank you guys
Yes You are correct. But then again My call rate is not going to be that high. This is not going to be a provider grade install.
We are looking at 2 calls per minute max.
Assume I had to keep my decision of using FreePBX how should I handle modules I do not need?
What is the recommended way to do this? There are some posts on the subject but all are vague.

I am going for the DISABLE option where the code / component remains present (like this any dependencies are not affected) but it will be disabled. Like this on updates it is not added.

How do you guys handle modules that you do not want?

Always remove everything you do not expect to use. The is simply a general best practice for any IT environment.

No. Delete them. Code present is code vulnerable.

fwconsole ma delete parking
... all the things ...
fwconsole reload

Deleting modules will be blocked if they are dependencies for modules you’re keeping. You should be fine, but stripped down systems like this are not actively tested in QA.

It should be because FreePBX is a module based system. This means you should always be able to have only the modules you want. If you don’t want it to be module based, that is fine, but you need to change things then.

if only trunks and inbound rules are in play, (the a leg) and bearing in mind that asterisk is a b2bua , where is the b leg supposed to connect ?

Thank you all for your feedback.

@cynjut Thank you for the Kamaillo option - I thought more about it. But this is going to have a deep learning curve. Default configuration looks pretty complex. It is hardcore provider grade class proxy and I thank you for your suggestion but should I go down this road for the miserable 3 calls per minute load?
@Igaetz Thank you for the dependency clarification

@sorvani I will investigate deeper the remove. I am reading that removed options will be reinstalled again on update and this will backfire on me. I dont want modules to be added back on updates.
@dicko Well this is a good question and made me research. Seems a sip server changes dynamics depending on who /what is UAC and UAS. It needs to act as a UAC and a UAS depending on what it is doing. Asterisk can definitely handle this because if I am talking trunks only, then in trunk mode, the pbx will become the “UAC” when it talks to the provider. These trunks that I will add are going to be connected to 3 providers and to other freepbx mini installs. So then the a and b legs will change mechanism depending on the communication I presume. This server will never transcode audio. Always proxy. Am I on the right track you think?

There was a recent framework change that addresses this Blog Post: Framework changes related to module auto update functionality

1 Like

I do this with freePBX deployments, like an SBC for SIP trunks. Modules in FreePBX dont really run like a service in the PBX. Uninstalling the “Conference bridge” module, for example, has no impact on the PBX performance. I have systems doing thousands of calls with this method for years using the standard FreePBX deployment without modifications, so your 1-2 call systems will see no benefit from that effort…

1 Like

Then a sip proxy is far more in line for what you are looking for.

https://dsiprouter.org/

is a simple turnkey appliance that is a front end for kamailio and fits your bill perfectly.

2 Likes

Hello - It’s clear. Thank you for explaining. I think I will take your advice and leave everything standard. Since there are no services which will be added or removed.
Maybe it is the wisest so I keep the footprint equal to that used and tested by the freepbx QA. Makes sense.

Thank you very much for your help. I will definitely check this out. I think it is what we need which removes the complex learing curve needed for raw kamailio. Thank you for sharing!

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.