This page collects the answers to the frequent questions related to this collaboration.

Q: Is this collaboration only for the two projects: SER and Kamailio (OpenSER)?

A: No. All projects related to SER eco-system were invited to join the initiative, some couldn’t decide yet or they were not willing to collaborate. Anyone is welcome here!

Q: Does this mean the development will stop for a while and no new features will be added?

A: Not at all. First, check the Benefits page to see how many new features each project will gain from the other. Probably independent development in each project to get those features will take couple of times more than working together to integrate. Moreover, the collaboration won’t end when the integration is done, common agenda includes features like asynchronous processing of SIP messages, configuration file reload and more. Additions to modules will go on as usual, up to each developer. We will continue to develop the best open source SIP server out there.

Q: Why hosting the source tree on sip-router.org?

A: Being an integration process at the beginning, we need full access to the server hosting the source tree to be able to import sources, preserve history and fix eventual issues. Backups will be done by each party involved in collaboration. Later the source tree might be moved to a source code hosting dedicated portal.

Q: Why GIT was chosen to manage the source tree?

A: Apart of other technical details about flexibility and features that can end in religious discussions, GIT offers interface to CVS and SVN, the two systems currently used by the projects.

Q: Why BSD was chosen as license for new additions to core and TM?

A: So called common layer, the core and TM, is the one most exposed to conflicting risks. We try to avoid disputes and endless discussions about the relevance of contributions (which could add changes to copyright and licensing). Therefore, as BSD allows all the contributors to use others’ code as they wish, we decided to go for it. It provides the simplest and fair conditions for this situation.

Q: So then, entire core and TM are BSD now?

A: No. Core and TM will preserve the GPL license of their main contributor: FhG Fokus (iptelorg.com/Tekelec now). This cannot be changed. Under BSD will be only the new additions. Note that core and TM aim to become a framework and real functionalities to be implemented as modules, in order to ensure robustness and small footprint to these components. See Design page for further details.

Q: How new contributions will get in?

A: Using same model as was in both projects. New modules or libraries need an initial review of an existing developer. Contributions to existing components have to be submitted as patch and reviewed by the maintainer of that part of code. Again, in the perspective of having a lightweight and flexible core and TM, any extension to these parts have to discussed on the developers mailing list and should prove itself global usage. Otherwise, it is highly recommended to find a way to bring the contribution as a new module or library. The policies look to ensure that common layer does not get fat and heavy.

Q: Why some code is going to be moved out of core?

A: Lot of code now does not fit the purpose of the core. There are functionalities that belong to modules or code that is shared by some modules only. Just as an example, Kamailio (OpenSER) pseudo-variable implementations will move to PV module (process was started anyhow in Kamailio), the core keeping just the engine for parsing name, setting/getting the value of pseudo-variable — there are use cases when no variable is required in config file, so having in the core the definition of about 100 variables makes no strong point.

Q: What will happen with next Kamailio (OpenSER) release?

A: It will happen as usual, following the 5-8 moths release scheduling, with release number 1.5. It may or may not include code from this project. Next after 1.5 we aim to be able to use the entire common layer for major releases. However, we will adapt the timing in order to release as soon as possible the merged version, thus bringing to you the all features from the two projects.

Q: What is the ETA for a functional common layer for both projects?

A: We aim to get at least 80% fully functional common core and TM in 2-3 months time frame. About 20% are expected to be hidden or not-really-used functionalities and are labeled with low priority. The focus on first stage is to get all Kamailio modules fully functional, preserving pseudo-variables framework, without losing configuration file compatibility with any of the projects.