Yitzchok Posted July 19, 2010 Report Share Posted July 19, 2010 What about adding a rescan message to the system that will scan for new changes in the xml files so that we can edit the configuration xml's on a live box then just tell pbxnsip rescan or reload it without the need to restart the PBX. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted July 20, 2010 Report Share Posted July 20, 2010 What about adding a rescan message to the system that will scan for new changes in the xml files so that we can edit the configuration xml's on a live box then just tell pbxnsip rescan or reload it without the need to restart the PBX. You mean like SIGHUP? I am not a big fan of that... And if you can send a SOAP message then you can also set the table entries with a SOAP message... Plus the format of the file in the file system may change during updates... What is the use case here? Do you want to change the settings of an account? Quote Link to comment Share on other sites More sharing options...
Yitzchok Posted July 21, 2010 Author Report Share Posted July 21, 2010 You mean like SIGHUP? I am not a big fan of that... And if you can send a SOAP message then you can also set the table entries with a SOAP message... Plus the format of the file in the file system may change during updates... What is the use case here? Do you want to change the settings of an account? I was thinking of storing the database files (the folders containing the xml files) on the network and point pbxnsip to that directory and changes from the outside by an external system will then submit a change signal to the pbx about changes. Or maybe using one PBX for managing all the servers settings while phone registrations are done to a specific server. I was thinking maybe using something like FUSE to give each PBX there own files while giving the main pbx all the files (I have no idea if this will work). (I would love to see some WSDL files for the SOAP messages) Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted July 21, 2010 Report Share Posted July 21, 2010 We have the idea on the table to organize the file system according to the domains, so that a backup of a domain would also be a backup of the directory. But so far the only resutlt is that it will not be "trivial". Of course, you can also just restart the PBX process if you want it to re-read everything. Brute force. The other idea that we had was using email to push content into the PBX. Again, just idea stage. This should be very simple for many applications. Quote Link to comment Share on other sites More sharing options...
Yitzchok Posted July 22, 2010 Author Report Share Posted July 22, 2010 We have the idea on the table to organize the file system according to the domains, so that a backup of a domain would also be a backup of the directory. But so far the only resutlt is that it will not be "trivial". Of course, you can also just restart the PBX process if you want it to re-read everything. Brute force. The other idea that we had was using email to push content into the PBX. Again, just idea stage. This should be very simple for many applications. To tell you the truth I hate the email as an API idea. Here are some things that can help some for development on the pbxnsip platform. Putting out a WSDL for the WebService will help. Designing a RESTfull service will be great. Also what about hosting the xml config files in a normal database (even without moving the tables to RDBMS) that can be shared across servers (for failover) and multi server support (domains get a server id and can be moved from one server to another from one web ui). Thanks Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted July 27, 2010 Report Share Posted July 27, 2010 To tell you the truth I hate the email as an API idea. No problem with that Here are some things that can help some for development on the pbxnsip platform. Putting out a WSDL for the WebService will help. Designing a RESTfull service will be great. WDSL, yea this will probably help. Something for the to-do list. You mean the RESTful services coming from Sun? Also what about hosting the xml config files in a normal database (even without moving the tables to RDBMS) that can be shared across servers (for failover) and multi server support (domains get a server id and can be moved from one server to another from one web ui). That could also be a possiblity, though not trivial. The problem is that there is no real-time suitable library available for the PBX, if we are e.g. using libmysql we are poisoning the memory management (no garbage collector for C...) and then after a couple of days you have to reboot the system all the time. And the PBX will still have to cache everything, using the database every time will slow down the processing dramatically. Quote Link to comment Share on other sites More sharing options...
Yitzchok Posted July 27, 2010 Author Report Share Posted July 27, 2010 You mean the RESTful services coming from Sun? Representational_State_Transfer That could also be a possiblity, though not trivial. The problem is that there is no real-time suitable library available for the PBX, if we are e.g. using libmysql we are poisoning the memory management (no garbage collector for C...) and then after a couple of days you have to reboot the system all the time. And the PBX will still have to cache everything, using the database every time will slow down the processing dramatically. Your right that by just putting the xml files into a Database won't help with the need to restarts the pbx to reload the settings (I am not sure if a caching the data for a few minutes or something will work here but maybe this can be tested) but I think it will help for a failover scenario (the second box has access to the same database and just picks up from where the other left off) Are there any ORM's or database agnostic api for C (I am a .NET programmer so I don't know if they have this in the unmanaged programming world) that can abstract away the database so the person can choose what database to use? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted July 28, 2010 Report Share Posted July 28, 2010 I can tell you that I was totally against virtual machines for the PBX. I had a lot of concerns against jitter, performance, CPU resource reservations and so on. Until I saw a failover taking place. Suddenly it became clear to me what this can do. Especially because we have a relatively small system! Forget about all those complicated scenarions where you try to store the relevant state information all the time in case you have to failover. Much to complicated and you never get there! Just fail the whole process over and thats it. The best part: It works--today. No programming required, no adding compliated DB interfaces bla bla. It just works. You can failover keeping callers in the ACD and all calls stay up, and all registrations stay up as well, even if they are TCP/TLS-based. Try to do this with a database. VM are not rocket science any more and they are not expensive either. AFAIK you get them for free from Microsoft and maybe also from VMware (not sure what exactly you need for failover). Quote Link to comment Share on other sites More sharing options...
Yitzchok Posted July 29, 2010 Author Report Share Posted July 29, 2010 How do you share the data between the main instance and the failover one? I am not talking about sharing state. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted July 29, 2010 Report Share Posted July 29, 2010 How do you share the data between the main instance and the failover one? I am not talking about sharing state. Data? The VM includes the (local) file system, which also includes the data. Nevertheless, it would be possible to also have rsync move everything into a safe place from time to time. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.