On Mon, Jan 10, 2011 at 10:48 AM, Geoff Van Brunt <[email protected]> wrote: > I agree. An "install all and disable unneeded" is bad from a security > perspective as well. As we all know SIP products are in the crosshairs > of hackers everywhere with recent automated attacks. This is only going > to get worse. The more that is installed, the more attack surface there > is. > > I also would like to see "lightweight" integration as you mentioned in > your blog. In the case of openfire there are a lot of features/modules > we would love to use as a company, but it's too cumbersome to use > "hidden" features using the integrated version. If not using the > integrated version, then we lose too much. Essentially we can only use > what is available out of the box... > > My votes for vNext are: > > - VMail redundancy in HA config > - More Branch Support for features, esp. dial plans > - More modularized so there is less dependencys. Essentially move to an > install as needed model. Also allow direct control over integrated > products such as openfire. The modularized model should also make adding > lightweight integrations easier allowing sipx to work with more > products. It should also make it easier for "third parties" to write > integrations with the product. Is this going to be hard? Yes. Is there > going to be a lot of secure information going back and forth between > sipx and some third party products (openfire). Yes. I don't think either > reason is a showstopper though and the benefits are just too good to > overlook.
100% in agreement with all your points and suggestions. re:secure info this spec doesn't solve everything, but this could go a long way to remove as much of the security burden from each module if they rely on web services for integration http://wiki.sipfoundry.org/display/sipXecs/Web+Service+API+Unification re:The modularized model I am inspired by how the drupal project manages this. You submit your project name and within minutes, you get a CVS repos and after you upload your module is there for all to use at their discretion. It could be as simple shell script that shows diagnostics to full blown SIP server. The one thing i'd change (beside using git instead of CVS) is the technical difference between core v.s. non-core (but it's a minor point). re:vmail HA config ezuce's plan is to introduce mongodb both with it's distributed database capabilities and its gridfs support will take us there. we'll pay attention to making these distributed capabilities to all applications based on freeswitch. For example it might mean building mod_mongo as alternative to sqlite/postgres native transparent service distribution. ezuce team is well aware we need to fully understand and test things like asynchronous disk flushes and data loss v.s. performance. I went to mongodb conference and from what i understand, flexibility is alway in user's control. _______________________________________________ sipx-users mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-users/
