Anybody using this in production
- Thread starter gflow
- Start date
- Status
Hi @gflow I wanted to give others time to respond before jumping in, but as no one has...
The DjangoPBX software is still at the Alpha stage of testing, so I imagine it would only be a few brave individuals that will have deployed into production.
I have a couple of instances in production, serving my own office and we have a couple of customers who have been willing to be guinea pigs. These are both what I would call monolithic installs, i.e. everything running on the one box. This is the default mode for the installer, and thus far, they have performed flawlessly.
There are a number of organisations that have taken DjangoPBX to use it purely for it's API, so they are sitting it behind their own customer PBX portals.
I am aware of a few others in the US, Canada, Germany and the UK who are using it at a relatively small scale.
The main area that has consumed development time recently is in scaling and clustering. We have had a very valuable amount of input from organisations running huge numbers of endpoints, with ideas of how they would like to see DjangoPBX scale out to multiple data centres and geographically separate failover.
I am in the process of deploying a simple cluster containing 1 x DjangoPBX, 2 x FreeSWITCH, 1 x AMQP broker, and 1 x file store. Once this is fully tested, the intention is to promote the software status from Alpha to Beta.
One problem that many PBX deployments face is what to do with files that are generated by FreeSWITCH, like call recordings for example. This can be especially tricky in clustered or failover scenarios. There have been many different approaches, iNotify, SyncThing, etc. Our approach has been to get each FreeSWITCH to push the files directly to a filestore in a non-blocking cache and forward manner, thus avoiding many of the pitfalls with network mounted filing systems.
Once I am happy with the cluster, I will publish a detailed diagram of how it all works. There is still a lot of work to do in producing good documentation, but we are gradually chipping away at that.
Many have said that they like the fact that we are using the very well respected Django web framework for it's reliability and ease of upgrading. The main thing to take away is that this is a completely open project, there are no barriers and everyone's help/input/ideas are welcome.
The DjangoPBX software is still at the Alpha stage of testing, so I imagine it would only be a few brave individuals that will have deployed into production.
I have a couple of instances in production, serving my own office and we have a couple of customers who have been willing to be guinea pigs. These are both what I would call monolithic installs, i.e. everything running on the one box. This is the default mode for the installer, and thus far, they have performed flawlessly.
There are a number of organisations that have taken DjangoPBX to use it purely for it's API, so they are sitting it behind their own customer PBX portals.
I am aware of a few others in the US, Canada, Germany and the UK who are using it at a relatively small scale.
The main area that has consumed development time recently is in scaling and clustering. We have had a very valuable amount of input from organisations running huge numbers of endpoints, with ideas of how they would like to see DjangoPBX scale out to multiple data centres and geographically separate failover.
I am in the process of deploying a simple cluster containing 1 x DjangoPBX, 2 x FreeSWITCH, 1 x AMQP broker, and 1 x file store. Once this is fully tested, the intention is to promote the software status from Alpha to Beta.
One problem that many PBX deployments face is what to do with files that are generated by FreeSWITCH, like call recordings for example. This can be especially tricky in clustered or failover scenarios. There have been many different approaches, iNotify, SyncThing, etc. Our approach has been to get each FreeSWITCH to push the files directly to a filestore in a non-blocking cache and forward manner, thus avoiding many of the pitfalls with network mounted filing systems.
Once I am happy with the cluster, I will publish a detailed diagram of how it all works. There is still a lot of work to do in producing good documentation, but we are gradually chipping away at that.
Many have said that they like the fact that we are using the very well respected Django web framework for it's reliability and ease of upgrading. The main thing to take away is that this is a completely open project, there are no barriers and everyone's help/input/ideas are welcome.
Thanks for the reply @Adrian Fretwell it seems like this project really has some direction and of course using a solid framework like Django will help this this project make some faster progress. If you havent used the Asterisk based project MirtaPBX send me a PM and i'll give you access to a demo account, they really have some great features I think you could take inspiration from.
Thank you for the information, I have not seen MirtaPBX and I will drop you a PM.
I haven't used Asterisk for a long time, I have compiled it from source many times in the distant past and also played with distributions like Trixbox.
When we ran just purely a SIP trunking platform I used Asterisk as our media servers, speaking clock, voicemails etc.
The key thing for me now, is that software we use must be Open Source, we had a very bad experience some years ago when a closed source product we bought into just pulled the plug and left me and my customers in a real mess. Maintaining a fully Open Source platform was one of the key drivers behind creating DjangoPBX.
I haven't used Asterisk for a long time, I have compiled it from source many times in the distant past and also played with distributions like Trixbox.
When we ran just purely a SIP trunking platform I used Asterisk as our media servers, speaking clock, voicemails etc.
The key thing for me now, is that software we use must be Open Source, we had a very bad experience some years ago when a closed source product we bought into just pulled the plug and left me and my customers in a real mess. Maintaining a fully Open Source platform was one of the key drivers behind creating DjangoPBX.
- Status