Hello from LA
- Thread starter pbxgeek
- Start date
@pbxgeek I watched your video, I like what you have done technically and it also looks very smart.
The use of Laravel to handle tasks like database migrations is a real step towards better maintainability, it appears to work in a very similar way that the Django framework works for us.
I assume in the fullness of time you will be able to remove the dependency on Fusion and have a neat fully Laravel managed application.
Four years ago, when we embarked on DjangoPBX, the intention was to build a simple GUI replacement, but keep the database structure. Because the Django ORM enforced good database design practices, I soon realised that a different database design was required, with constraints implemented at the database level. The advantage being that now the whole database could be managed through the Django migrations system.
One thing I wanted to introduce at the core, was strong support for clustering and scaling. Sure, we need a simple install for a single stand alone system, but I also wanted the ability to have one instance of the PBX configure multiple FreeSWITCHes and have the option of keeping recordings in a separate file store, and have FfreeSWITCH be able to dump call recordings directly to that file store, but also correctly update the PBX call recordings table. I also wanted to build in the flexibility for options to have many combinations in between.
Introducing the option to have a RabbitMQ server to provide a layer of isolation between DjangoPBX and the Switch farm has also been a great step forward for receiving FreeSWITCH events and sending commands to one or more FreeSWITCHes. Having that AMQP buffer means that events don't get lost even if we shut the PBX software down for a few minutes.
If you wish to incorporate any of these ideas into FS PBX, now or in the future, I am very happy to collaborate and share. I would love to make the DjangoPBX interface look as nice as yours, the problem is that I am not a web designer. You are probably aware that the Django framework employs a templating system, so changing the look and feel should not be difficult, but it's not my area of expertise.
Take care,
I love your project.
Adrian.
The use of Laravel to handle tasks like database migrations is a real step towards better maintainability, it appears to work in a very similar way that the Django framework works for us.
I assume in the fullness of time you will be able to remove the dependency on Fusion and have a neat fully Laravel managed application.
Four years ago, when we embarked on DjangoPBX, the intention was to build a simple GUI replacement, but keep the database structure. Because the Django ORM enforced good database design practices, I soon realised that a different database design was required, with constraints implemented at the database level. The advantage being that now the whole database could be managed through the Django migrations system.
One thing I wanted to introduce at the core, was strong support for clustering and scaling. Sure, we need a simple install for a single stand alone system, but I also wanted the ability to have one instance of the PBX configure multiple FreeSWITCHes and have the option of keeping recordings in a separate file store, and have FfreeSWITCH be able to dump call recordings directly to that file store, but also correctly update the PBX call recordings table. I also wanted to build in the flexibility for options to have many combinations in between.
Introducing the option to have a RabbitMQ server to provide a layer of isolation between DjangoPBX and the Switch farm has also been a great step forward for receiving FreeSWITCH events and sending commands to one or more FreeSWITCHes. Having that AMQP buffer means that events don't get lost even if we shut the PBX software down for a few minutes.
If you wish to incorporate any of these ideas into FS PBX, now or in the future, I am very happy to collaborate and share. I would love to make the DjangoPBX interface look as nice as yours, the problem is that I am not a web designer. You are probably aware that the Django framework employs a templating system, so changing the look and feel should not be difficult, but it's not my area of expertise.
Take care,
I love your project.
Adrian.
Hi @Adrian Fretwell ,
Thank you for reaching out and sharing your thoughts. Transitioning fully away from FusionPBX is indeed the ultimate goal. However, given the complexity and scale of the system, this is a gradual process. FusionPBX currently serves as a bridge, facilitating easier adoption and covering some gaps as I work on redesigning each page.
In addition to the front-end overhaul, I’ve been focusing extensively on upgrading and improving various backend processes. For example, I’ve fully integrated my system with the Ringrotel API and developed an SMS backend to deliver messages directly to Ringrotel apps. There are still many other ongoing improvements, including upcoming features like Polycom ZTP and Yealink RPS integration, which will allow for centralized management from a single portal.
I appreciate your suggestion about collaborating. How about an idea of potentially combining our systems?. From what I’m hearing, DjangoPBX has robust backend features that support scalability, and I’m sure there’s a lot I could learn from your experience with larger VoIP networks. Let’s explore this further and see how we might work together to create a more powerful, unified system.
If you’d like, we can take this conversation into a private chat to discuss the details further.
Looking forward to hearing your thoughts.
Thank you for reaching out and sharing your thoughts. Transitioning fully away from FusionPBX is indeed the ultimate goal. However, given the complexity and scale of the system, this is a gradual process. FusionPBX currently serves as a bridge, facilitating easier adoption and covering some gaps as I work on redesigning each page.
In addition to the front-end overhaul, I’ve been focusing extensively on upgrading and improving various backend processes. For example, I’ve fully integrated my system with the Ringrotel API and developed an SMS backend to deliver messages directly to Ringrotel apps. There are still many other ongoing improvements, including upcoming features like Polycom ZTP and Yealink RPS integration, which will allow for centralized management from a single portal.
I appreciate your suggestion about collaborating. How about an idea of potentially combining our systems?. From what I’m hearing, DjangoPBX has robust backend features that support scalability, and I’m sure there’s a lot I could learn from your experience with larger VoIP networks. Let’s explore this further and see how we might work together to create a more powerful, unified system.
If you’d like, we can take this conversation into a private chat to discuss the details further.
Looking forward to hearing your thoughts.
Hi @pbxgeek,
Any collaboration is a good thing. I feel that we should combine ides rather than systems. I think the VoIP community as a whole will benefit from having more systems to choose from, especially if they are open and well supported. No two projects are exactly the same, each one will have it's both it's strengths and weaknesses, but each will also have a key focus, be it end-user appeal for retail or API/Backend integration appeal for wholesale, for example. The VoIP community needs them all!
Because the Django framework is Python based it forced my to learn the language. Having used PHP for years, I initially found it difficult, but coming from a C/C++ programming background, I soon got to grips with it, and I am now gradually moving all of my historic PHP applications over to Python.
The Laravel framework is very good, and it is a perfect fit where VoIP people like us, want to concentrate on the VoIP not re-inventing the web content delivery wheel. However because Laravel is PHP based, not Python, I prefer to work with the Django web framework. I don't think one is better than the other, its just a case of using what we feel comfortable with.
You have my contact details and I am always willing help and share, or just be a sounding board for bouncing ideas. I needed a different system to the one that I was using at the time, but because I could not find a viable alternative, I had to build one, now you have presented another alternative - I think that really is a step towards diversity in software and provides greater choice for our VoIP community.
Cheers,
Adrian.
Any collaboration is a good thing. I feel that we should combine ides rather than systems. I think the VoIP community as a whole will benefit from having more systems to choose from, especially if they are open and well supported. No two projects are exactly the same, each one will have it's both it's strengths and weaknesses, but each will also have a key focus, be it end-user appeal for retail or API/Backend integration appeal for wholesale, for example. The VoIP community needs them all!
Because the Django framework is Python based it forced my to learn the language. Having used PHP for years, I initially found it difficult, but coming from a C/C++ programming background, I soon got to grips with it, and I am now gradually moving all of my historic PHP applications over to Python.
The Laravel framework is very good, and it is a perfect fit where VoIP people like us, want to concentrate on the VoIP not re-inventing the web content delivery wheel. However because Laravel is PHP based, not Python, I prefer to work with the Django web framework. I don't think one is better than the other, its just a case of using what we feel comfortable with.
You have my contact details and I am always willing help and share, or just be a sounding board for bouncing ideas. I needed a different system to the one that I was using at the time, but because I could not find a viable alternative, I had to build one, now you have presented another alternative - I think that really is a step towards diversity in software and provides greater choice for our VoIP community.
Cheers,
Adrian.
Last edited:
Than you very much for this. It very well could be a big leap forward for this product. Whenever we expose the gui to clients we kind of have to apologize for how it looks even though it's very powerful.
Well said, Adrian. I'll contact you to ask how you achieved some of the stuff you built. I do have some pain points that I'd like to overcome.
I completely understand where you’re coming from—I’ve been in that situation more than once myself. That’s exactly why I built this system. My clients love it, and the self-service capabilities it offers have positioned me competitively against larger providers.
@vuthy09 How did it go at the end? Were you able to complete the installation?
Refer to this page to see all the pages for which you need to update links.
github.com
Refer to this page to see all the pages for which you need to update links.
Release v0.9.1 · nemerald-voip/fspbx
What's Changed Phone Numbers page New installation script List of all redesigned pages Dashboard - /dashboard Extensions - /extensions Voicemails - /Voicemails Users - /users Call History - /call...
github.com
I got another problem here@vuthy09 How did it go at the end? Were you able to complete the installation?
Refer to this page to see all the pages for which you need to update links.
Release v0.9.1 · nemerald-voip/fspbx
What's Changed Phone Numbers page New installation script List of all redesigned pages Dashboard - /dashboard Extensions - /extensions Voicemails - /Voicemails Users - /users Call History - /call...
Did you run the other two commands after the installation script and adjust settings in the .env file to match your domain if needed?
