Kamailio Advanced Training
Click here for more details!

Learn how to build RTC services with Kamailio!

Tuesday, November 25, 2008

About SIP-Router Project

I want to reveal some details from the process of getting to sip-router.org project. Next statements are from my personal point of view.

When all started, back in 2001/2002, it was research and SIP Express Router (SER). Over the time became more than that, the market demanded new features pushed beyond a SIP proxy/router definition, the place of this application was no longer in research, business side and telephony industry forced to take actions.

In that context I co-founded OpenSER in 2005, leaving SER to continue its way.

Now after several years, the situation evolved as well, SIP is clear the today’s technology for telecommunication, every Telco out there is deploying/replacing its infrastructure with SIP. However, SIP was designed for more than this, other companies develop innovative services and products using this protocol. I could identify couple of directions within our project:
- old-style-fashion switch – mapped on SIP Router/Proxy, where speed and reliability is the main concern
- call/dialog stateful proxy (back-to-back user agent) – for a larger set of security and service features
- pbx-like features using SIP signaling only – call pickup, shared line appearance, etc…
- new fashion functionalities – IM&Presence, gaming, integrated and convergent communication, application servers…

To be able to sustain and keep high level quality, it is clear that we need more companies in, entities that are interested on different directions of the development, so they contribute there. I am interested in the first and last direction with higher priority, but I don’t want to leave out the other two.

Moveover, kamailio/openser is used now in many deployments, some serving millions of users and billions of minutes per month. We need to provide a reliable environment so more companies are confident the development and maintenance continue. The project shall prove the maturity that is not dependent on gringo-like actions, one company influence, forking out of nowhere, domain hijacking, etc… this is the first goal for myself, something I want to ensure before anything else.

sip-router.org was not one minute/meeting decision (after a beer, dinner or one email, …). Discussions started between different persons, coordinated or privately, several months ago, long before the latest fork. It was clear that SER and OpenSER made their points over the time, one satisfying better the need for stability, performance, the other better for innovation and flexibility. At a point in future, sooner or later, each project would have been switched some of its resources to the other direction.

At the time of announcement, the sip-router.org site had comprehensive content about how this will work. It was the result of face-to-face meetings, phone and email conversations that took place a lot in the last months before the news. It was no decision until everyone deeply involved in each project acknowledged that there are mutual benefits for everybody (developers, users and businesses behind both projects) backed up by willingness to do it in a fair manner.

I cannot talk about other projects in the x-SER eco-system, but with Kamailio/OpenSER never was the case/proposal of merging back to SER, all the time was about collaboration and joint effort. It will never happen to drop our goals for innovation and flexibility. Therefore we discussed and agreed the development mechanisms to ensure the need of each project: a stable layer (core + tm) and innovation by modules or libraries.

Nothing was left out, every aspect, from licensing, contribution, … to releasing and management, was approached. The meeting in Karsruhe came just to conclude that. All our community members were happy about announcement, and, as a matter of fact, there were no political-like discussions conducted between our members since sip-router.org announcement, the focus moved on the technical side and good progress was reached so far:
http://lists.kamailio.org/pipermail/users/2008-November/020694.html

Personally, I consulted people in open source and communication world, that are not particularly technical or in relation with x-SER projects. Getting to sip-router.org took more than half year since I realized a common layer between the x-SER projects should be beneficial for everybody.

There are more things to say, but maybe not that relevant. I let them for the time we meet at SIP Router events. Now I hope several points are more clear:
- it is not a merge back in SER, it is a joint project (this just because some tried to suggest it)
- the entire collaboration process was carefully discussed and planned
- it was conducted by the need of reliable, non-confusing environment — that ensures sustainable development, innovation and rock-solid stability, it protects the interests of developers, users and businesses investing resources in the project.

At the end, I want to thank to Kamailio and SER management team members, to the developers and many other people involved in both projects that helped with this process – they dedicated lot of time and resources.

Monday, November 24, 2008

OpenSER v1.3.4 Released

OpenSER v1.3.4 is out - a minor release of the branch 1.3, including fixes since v1.3.3 - configuration file and database compatibility is preserved...

A new release in 1.3 series is out. OpenSER (new project name: Kamailio) 1.3.4 is based on the latest version of branch 1.3, including many fixes in code and documentation, therefore those running 1.3.x are advised to upgrade.

Source tarballs are available at:

http://www.kamailio.org/pub/kamailio/1.3.4/src/

Detailed changelog:

http://www.kamailio.org/pub/openser/1.3.4/ChangeLog

Download via SVN:

svn co https://openser.svn.sourceforge.net/svnroot/openser/branches/1.3 kamailio

Tag for this release can be browsed at:

http://openser.svn.sourceforge.net/viewvc/openser/tags/1.3.4/

Project site at SourceForge.net:

http://sourceforge.net/projects/openser/

Modules' documentation:

http://www.kamailio.org/docs/modules/1.3.x/

What is new in 1.3.x release series is summarized in the announcement of v1.3.0:

http://www.kamailio.org/mos/view/OpenSER-v1.3.x-Release-Notes/

Note: Kamailio is the new name of OpenSER project. First version under Kamailio name was 1.4.0. Older versions will continue to use OpenSER name.

Sunday, November 23, 2008

Kamailio Devel Team

November was very busy for myself, with lot of work and traveling for the sip-router.org, so apart of announcing few updates, I focused on getting things done rather than going in pointless discussions. I will send couple of other emails related to this subject.

However, there was one person writing untrue statements and offending the developers of Kamailio/OpenSER on mailing lists, web and IRC channels. If he would have searched a bit on the net, have talked with our developers, he would realise that people in our team are very rich in skills and experience, then probably he would refrain from statements like “no skills”, “no knowledge”.

Until someone else than himself, recognise him as the greatest, gets the Nobel prize, publishes world recognized books or standards, so I can take his opinion in consideration, the development of Kamailio/OpenSER Project is ensured by people such as:
- Juha Heinanen, doctor in computer science, former professor at Tampere University, author of many RFCs, and the list can continue … from the web:
http://occamnet.com/company/directors_and_advisors/jheinanen.cfm
http://www.arkko.com/tools/rfcstats/juhaheinanen.html
- Klaus Darilion, doctor in computer science at Technical University Vienna, involved in ENUM and security of VoIP/SIP, author/contributor to several open source applications and papers related to these domains:
http://www.ipcom.at/index.php?id=565
- Henning Westerholt, computer science engineer, in charge with the biggest VoIP deployment based on Kamailio/OpenSER I ever heard of: about 2 000 000 users, 5 000 000 phone numbers, 1 000 000 000 routed minutes per month. It is at least twice bigger than other deployments of openser/kamailio I am aware of.
http://www.1und1.de

I am stopping here, but all the other members of Kamailio/OpenSER devel team have broad knowledge in computer programming and VoIP technologies, authored or contributed to other open source applications — just google the names. As co-founder of this project I felt is my duty to show the true.

Therefore those statements are proofless and it is sad to see somebody can come up with such things. The development of Kamailio/OpenSER boosted since release 1.4, in summary:
http://www.kamailio.org/dokuwiki/doku.php/features:new-in-1.5.x
http://www.kamailio.org/dokuwiki/doku.php/roadmap:1.5.x

and we are not ready yet with the new features for 1.5. Meanwhile, effort is directed to sip-router.org project as well — I will post a status update soon.

Friday, November 21, 2008

First Kamailio (OpenSER) Module Ran On SIP-Router

Yesterday evening first Kamailio (OpenSER) module ran on the common layer core+tm provided by sip-router project. That was siputils (new module in Kamailio devel version).

Soon after:
- xlog module was ready too, with just an extra define in Makefile, marking the inclusion of pseudo-variable and transformation API in sip-router — one can do color printing via xlog. Note that all pseudo-variables and transformations will be moved in PV module as discussed some time ago on Kamailio devel mailing list.
- DB API of Kamailio and SER were included as library and other modules become compilable with sip-router

For reference:
http://lists.sip-router.org/pipermail/sr-dev/2008-November/000071.html
http://lists.sip-router.org/pipermail/sr-dev/2008-November/000077.html
http://lists.sip-router.org/pipermail/sr-dev/2008-November/000081.html
http://lists.sip-router.org/pipermail/sr-dev/2008-November/000082.html

Once MI and statistics APIs will become libraries as well, then many other Kamailio (OpenSER) modules shall work more or less out of the box (some statistics done in core and 1-2 mi commands will miss in the first phase). Then it comes the second big step, after module integration, config language update — after that point we are kind of 70% ready.

All these happened in just few days since source code repository (GIT) was up … it looks like we will get most of the features from Kamailio (OpenSER) and SIP Express Router (SER) together sooner than expected … let’s see …

Karlsruhe Meeting Photos

Photos taken during the SIP Router Project meeting day in Karlsruhe, Germany, Nov 10, 2008, are available at:

http://sip-router.org/pub/photos/album-sip-router-karlsruhe/

... with folks from Kamailio (OpenSER) and SIP Express Router (SER) projects..

Karlsruhe Meeting Minutes

SIP Router Project - Kick Start Meeting minutes:

* development side: move forward, sip-router.org source repository should be up next week
* end of January we should have a runable core+tm with support for the most used features from both Kamailio (OpenSER) and SIP Express Router (SER) (100% support might be a little delayed as some features may become obsolete)
* Kamailo next-next release (probably after spring next year) will be based on sip-router core+tm
* next or next-next SER release will be based on sip-router (SER might make another 2.1 release from the current CVS, since the code is ready - to be discussed)
* future releases will most likely be common and will unify all or most of the modules (depending on everything up to that point working ok)
* copyright: patches that are not accompanied by (c) claims will not add to the (c). We should put this on a web page and when in doubt we can ask the patch author for confirmation. While it’s likely this has no or very limited legalvalue (especially in Europe), it will server at least as a gentleman agreement. We need this because:

1. we need the agreement of all (c) holders for the GPL code to add licensing exemptions (e.g. we need to add an openssl linking exemption) and it’s easy if we have a known “small” set of (c) holders
2. people might not like having multiple (c) notices on files they created, just because someone did send a trivial or not so significant patch (note: “trivial” and “significant” are very relative). On problems, probably the board will decide, if nobody gives up the claim we’ll fork the module (worst case, to be avoided as hard as possible).

* forking modules: highly discouraged, but allowed
* unmaintained and rarely used modules: removed after a grace period
* board: for now we continue to have 2 boards, SER and Kamailo at least until we have something runable. In the meantime we should think/discuss how the common board will look like: how it will be elected and for how long, “composition” (how many devels, how many from the user community, testers a.s.o)
* testing: very important, Jerome proposed having beta-tester groups and stressed out the importance of dynamic tested. Everybody seems to agree, but there are doubts about finding beta-testers volunteers.
* release management: we need a release manager for each release
* documentation: Kamailio uses a wiki for core, and docbook .xml for modules, SER use NEWS (txt file) for core and docbook for modules, but it’s in the process of migrating to a more man page friendly format (still .xml). More discussion is needed, between the main doc writers from both sided.

sip-router.org:

* GIT repository should be up next week
* sr-dev mailing list should be used for technical dicussions related to merging the cores
* new features mails should be cc’ed to sr-dev too (very important especially when core or tm is involved).
* todo: find easy to remember short name

Related projects:

* some modules may be on separate repositories for a while (e.g., openimscore), maintained by their devs for using them out of the box with sip-router
* stand-alone application servers (Voztelecom/WeSIP, Iptego/SASI) may merge the communication interface specs in the future.
* it is a need for a place where to collect basic info about related projects

Further steps:

* new meeting, to be organized somewhere end of winter/beginning of spring 2009 (topics: celebrate first integrated working version, discuss further development of sip-router)
* setup of adjacent tools that help developing code and documentation (e.g., wiki, tracker)

General opinions:

* there are x-ser platforms running milions of users, sip-router must provide a rock-solid SIP server, esure trust and project reliability
* while having a strong focus on above item, innovation shall not be stopped, new features to be added as module to avoid effects to core and main modules
* very important modules (e.g., usrloc, registrar, …) should be protected as much as possible, patches and new features to be carefully reviewed not to affect stability and interoperability
* improvements to most important parts to be discussed on sr-dev mailing list

Thursday, November 20, 2008

PBX Alternatives

Interesting post listing PBX alternatives:

http://blog.voipsupply.com/uncategorized/need-an-ip-pbx-101-alternatives-to-cisco-and-avaya

... with Kamailio (OpenSER) included ...

Carrierroute Extensions In Kamailio 1.5

Courtesy of Henning Westerholt and 1&1, carrierroute module got a bunch of new features that makes the module more flexible than ever and also fixed a few annoyances in the module usage:

1. Improved routing data loading

The module supports now the partioned loading of routing data during startup and reloads. In the past when one want to load big route set it was necessary to increase the private memory pool size, as the data was stored temporarily there. Now this is not necessary anymore, its possible to load route sets with e.g. 400.000 rules in the standard (private memory) configuration.

2. Efficient matching of domains and carriers

In the old implementation a simple linear list was used, this was replaced with a fast binary search function. The module can now look up carrier and domains in most cases with O(log n), which makes it more scalable when a big number of carriers and/ or domains are involved. Only when a dynamic string is used in the config script a full list search is needed.

3. Support for non-numerical prefix matching

Carrierroute now supports also the prefix matching with non-numerical characters. Its possible to use the entire standard ascii charset for route matching. This is configurable with a module parameter, the default implementation is still the know digit matching method. Please keep in mind that memory demands will increase somewhat when the extended matching is used. This additonal flexibility will probably bring a small overhead with it, as some additional logic is involved during the routing deciscion. But this will not be noticable on today standard servers.

4. Extensive refactoring and cleanups

Restructured and refactored the code in most areas, to make the module implementation and structure more understandable, maintainable and extensible. Replaced the usage of custom datatypes and fixup functions with the standard core implementation, switched to the autogenerated DB interface and use now standard glibc functions e.g. for the list search. Changed certain structures to not store the full name of carriers and domains in memory to save space and got finally rid of this mismatch between internal and external carrier ID.

More details about the new implementation can be found in the documentation at:

http://www.kamailio.org/docs/modules/devel/carrierroute.html


Porting hints, e.g. for the new database structure are provided at:

http://www.kamailio.org/dokuwiki/doku.php/install:1.4.x-to-1.5.0

Track the new features introduced in Kamailio devel at:
http://www.kamailio.org/dokuwiki/doku.php/features:new-in-1.5.x

Tuesday, November 18, 2008

SIP Router Project - GIT Repository Online

The GIT repository for sip-router is now online. GIT URLs:

- git://git.sip-router.org/sip-router (read only)
- http://git.sip-router.org/sip-router (read only, slower, git://… recomended)
- ssh://git.sip-router.org/sip-router (read write but account on git.sip-router.org needed)

Web interface:

- http://git.sip-router.org/cgi-bin/gitweb.cgi

For more info about GIT try:
http://git.or.cz/gitwiki/GitDocumentation

and if you want to know how it works:
http://eagain.net/articles/git-for-computer-scientists/


Special thanks go to Jan Janak, who not only did setup git.sip-router.org (including automatic cvs sync for some of the repos), but he’s also hosting it on one of his private machines.

More details here…

Photos from Karlsruhe

Photo album that includes pictures from last week's Karlsruhe meeting of SIP Router project is available at:

http://sip-router.org/pub/photos/album-sip-router-karlsruhe/

Wednesday, November 12, 2008

SIP Router Project - The Meeting In Karlsruhe

Because of taking several days off, a complete report might show up a bit later, now a (short) summary...

First, many thanks to 1&1 for hosting the event and everyone that participated in such short notice. There were representatives from 10 companies:
- 1&1
- FhG Fokus
- Telio
- Asipto
- iptelorg/Tekelec
- Voztelecom
- Iptego
- Itsyscom
- Longphone
- Basis AudioNet
Some pictures should be published in the near future.

After going in short introduction and presentation of the goals from the point of view of each project (SIP Express Router (SER) and Kamailio (OpenSER)), we focused on:
- identification of potential points of conflicts and how to get to a resolution in such case
- code integration for common layer of the first phase
- future development and proposals of new features
- management of the larger eco-system that includes related projects and business entities

I will do several posts detailing what was discussed and proposed there for SIP Router project in few days. meanwhile, the outlines:
- it is hard to avoid conflicts just by some clear and strict rules, so the common sense should lead the collaboration and discussions
- GIT repository should be up in several days so the work can start, with a time line of 2-3 months from now to get core and tm in a very good shape of integration
- another meeting shall be set in about 3 months time, to allow enough time for people to be able to attend, adjust the development and look more deep at the future. While a lot of focus in the next months will be on integration, development of new features won't stop -- for example, steps to a partial asynchronous processing are undertaking, couple of new modules are planned for release, several other modules to bring new functionalities
- we should encourage and promote the development of related applications, like web interfaces, management tools, applications servers -- they add value for community and business

Tuesday, November 11, 2008

IRC Devel Meeting Summary - Nov 06, 2008

I am trying to summarize the outcome of the IRC devel meeting from last Thursday, Nov 06, 2008. The log is available here...

Regarding the 1.3.x series, we set the 20th of November as the date for 1.3.4 release. There are several fixes and this branch is still used in many production environments, so it worths investing time in it. There are some updates in 1.4.x to be ported and some issues to be investigated.

For a new 1.4.x release (the 1.4.3) we look for the beginning of December as the time frame for setting the date of the release.

The 1.5.x rises in the first phase the question of a shorter time release, as we have lot of new features already implemented, see:
http://www.kamailio.org/dokuwiki/doku.php/features:new-in-1.5.x
http://www.kamailio.org/dokuwiki/doku.php/roadmap:1.5.x

Unfortunately some of the new features are not completed yet (e.g., htable, carrierroute updates, PV migration) so we will stick to 6-8 months release cycle. The next major one that will use the common layer (core and tm) from sip-router could be done in a shorter time than
usual. So, beginning to mid of January should be the time to freeze the code for a release date somewhere in end of January or February.

An important aspect approached during the discussions was the release management and testing management. Perhaps we need to appoint a person to manage releasing process in order to have a better synchronization of the developers. As everyone agrees, testing is very important and we try to improve it. There is a testing suite included in the source tree right now, used for static testing.

The idea of a dynamic testing and testing community was introduced and hopefully we can attract people and build a group of beta testers. There is a proposal of how to implement and what to take care of, probably this one has to continue on devel and users mailing lists for a proper
organizational structure.

GIT became as a subject of migrating from SVN, because of its features for a distributed development environment. However, sourceforge.net does not have such offerings, so it is not possible now anyhow. However the sip-router.org will use it.

Regarding the sip-router.org project, we focused on short term goals, acknowledging that we have several modules offering same functionality but relying on different underlaying data structures, this have to co-exists for a longer time. For the first phase, core + tm the overlapping is rather small, the two projects insisting in the past to improve different aspects of them.

Unfortunately I forgot to bring up some punctual topics proposed, mainly related to tm failure route calling in case of sending error and reply handling/dropping in onreply_routes.

Wednesday, November 5, 2008

SIP Router Project Kick Start Meeting

The meeting happens in very short time. Sorry for that, but probably it is better sooner that later as will mark the moment of integration start. It is the place to discuss the technical aspects of the integration, milestones and future development.

Place: Karlsruhe, Germany
Date: Monday, November 10, 2008
Registration: free

More details at:
http://sip-router.org/index.php/meeting/

The results of the meeting will be posted to the site and mailing lists.

Tuesday, November 4, 2008

The SIP Router Project

The SIP Router Project started aiming to build a solid open source SIP routing platform, based on collaboration of the SIP Express Router (SER) and Kamailio (OpenSER) teams.

Developers of these two projects believe that an united and non-conflicting environment will bring many benefits, to them, community members and companies.

- bring together the developers and user communities of both projects
- reduce maintenance overhead
- avoid duplicated efforts in development
- develop a core framework that is flexible, extensible and scalable
- promote and build a solid open source SIP server project
- ensure business credibility
- make future forking undesirable, this harms everybody, affects credibility and business

You are welcome to join! Visit:

http://www.sip-router.org

Mailing list:

http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev

There will be a meeting for concluding the collaboration and kick start the integration. Everybody is welcome to join. See more details:

http://sip-router.org/index.php/meeting/