I am creating a postpaid billing system for FreePBX. This system will allow users to create extensions and set up inbound and outbound routes using the FreePBX API. However, I am facing an issue with the lack of API documentation for outbound routes, and I cannot find any documentation for allowing routes in extensions via the API.
I am open to doing some work via the CLI if it is possible, but my goal is to have users set up extensions and start making calls without any intervention from the admin. This project will be open source on GitHub, and anyone who needs access to the code can contact me via IM for now. Once we finish the first iteration, we will open the repository to anyone on GitHub.
Because the OP is viewing multi-tenant as a PBX config per client. This is sounding like individual accounts being sold. There is no reason for a post-paid billing system in a normal company PBX. This is for billing users for their usage. 99.9% certain of it.
Why do you need to mess with outbound routes at all? For example, to allow the end user to get a higher quality or more reliable trunk, by paying a higher rate? Otherwise, couldn’t all extensions use the same routes?
Thank you for your response. I strongly believe that creating custom software to suit specific use cases is a key benefit of open source software. While the native UI may not be applicable to my needs, I am confident that I can still achieve my goals within FreePBX’s terms of service by developing my own module.
Using the CLI to set up outbound routes from my customer application is a viable solution that will enable me to tailor the functionality to my exact needs while still utilizing FreePBX’s robust system. I am committed to ensuring that the resulting solution is secure, reliable, and fully compliant with FreePBX’s policies.
This isn’t a “terms of service” issue it is a design issue. You are trying to drive a screw with a hammer. Can it be done? Sure. Should it be done? No you should get a screwdriver. Essentially use the right tool for the job. If you are doing multi-tenant type stuff, FreePBX is not the right tool. If you don’t plan on using the FreePBX stuff it doesn’t make since to have the bloat. Simply use Asterisk or perhaps FreeSwitch or whichever tool does the job you need.
That’s the problem. Who decided it’s not the right tool? If you don’t have a solution to a question, you simply say you don’t have the solution. But don’t make my solution or question look stupid. FreePBX is a good product and can do a lot more. I looked at FreeSwitch and other solutions, but they are not as secure as the FreePBX core. Just like A2billing, I’m sure you guys would have provided similar feedback when that was in development. For me, A2billing was a very good solution. For my needs, I just needed to be able to bill some users with an extension connected to FreePBX. Their users are not within the company, so I will charge them for the DID and trunk usage through the PBX. I created a website and gave them the ability to see and manage their extensions without allowing access to the PBX. If that violates the TOS of FreePBX, then i guess i just create my own.
Literally not one person said you are violating any ToS. What you are describing here is a multi tenancy setup and what everyone here is telling you is that you may have an easier time getting a different system implemented that would support what you want to do. People are literally just telling you that FreePBX is not a good fit for what you are trying to accomplish. If you feel like you can make it work by all means go for it.
The original creator originally and the roadmap/path of the developers and maintainers since day 1.
Nobody is doing this. We are all simply trying to save you time and energy with our collective knowledge. Over the years people have done a lot of things. We know the pain points and are trying to keep you from slamming in to a wall.
It is a tool with a set of skills. There are tools with other skills. There is no need to try and turn a box in to a tire when tires exist.
This tool has nothing to do with FreePBX. I know the author and we have had plenty of conversations over the years. Not sure what the tie in here…
So expanding a2billing probably makes more sense here. This again does not relate to the multi-tenancy of FreePBX
You are again confusing license which literally allows you to do anything with the code as long as credits and other small conditions are maintained with design choices.
This all feels like talking to a wall but the tl;dr is use the right tool for the job. This will save you time and energy. This is not a question of license.
At the end of the day do whatever you want legal, illegal, by design whatever I am not your real dad. I am just one of the guys who wrote a good chunk of the code in FreePBX so I know a thing or two and try to save people from heartbreak
Have you considered FusionPBX (PHP GUI for FreeSWITCH)? I know you said what you are doing is not strictly “mulit-tenant” (at least from your perspective) but I think if you put FusionPBX into multi-tenant mode it would work pretty well for your use case. FreeSWITCH also has “nibblebill” which I am aware of but haven’t actually implemented… however, maybe this will give you some ideas. mod_nibblebill | FreeSWITCH Documentation
Whatttt? FreeSWITCH is not secure?
The provider you connect to likely uses FreeSWITCH. Sangoma SBCs are FreeSWITCH. Twilio, Telnyx, Five9, Zoom and many more are using FreeSWITCH. What exactly have you found to be less secure?
@jfinstrom Thank you for your reply, and thank you for your hard work with FreePBX. I will not touch the FreePBX code or change any core settings. Trust me; I gave this project lots of thought, and using FreePBX was the best option. I will personally send you a username and password when it goes online for you to see for yourself.
I wanted to clarify that this project is not intended for a hospital or hotel. Rather, it is designed for a small subset of users who want to maintain a virtual phone number from a specific location on their mobile device using an app or access number. Currently, we have to manually change settings and set up access for these users, but we want to move away from that and create a very simple user interface that they can use to interact with their virtual number.
The goal of this project is to streamline the process for maintaining virtual phone numbers and make it more user-friendly for non-technical users. Maybe when it gets bigger, we will integrate directly with a PBX core.
For this application, I would not use the regular inbound and outbound routes at all. Set up a database with virtual numbers and extensions. For incoming, use a Custom Destination to look up the DID and route to the correct extension. Possibly, Dynamic Routes Module - PBX GUI - Documentation will do what you need and you won’t have to write any dialplan code.
For outgoing, I’d use a dialout hook to rewrite the caller ID:
Hi @Stewart1, Your idea sounds great! I’m currently working on a C# application that allows users to register for a extension using GQL API mutations. My PBX will have multiple trunk destinations. My goal is to have users check a box labeled “Allow outgoing calls” and then select a number from a drop-down list of DIDs. After clicking “Save,” the API should create the extension and set up an outbound route for that extension, which then restricts outgoing calls to the selected number. I am currently doing this manually, and I want to do this automatically from the user registration system.