Merry Christmas and Happy New Year 2009!

Day by day, we ended another year. 2008 was full of events, starting with one major release and six minor releases, participation to workshops and conferences wordlwide, adoption in new production environments and acknowledgement of running platforms with millions of users and billions of routed minutes/month using Kamailio (OpenSER), check the News archive at:

http://www.kamailio.org

There were sad events as well, including the hijacking of the old domain name after the rename in Kamailio, still the SourceForge project goes on, with same name, proving the genuine openser project:

https://sourceforge.net/projects/openser/

We maintained release 1.3.x series, last being 1.3.4, which still keeps the old name and is available at:

http://www.openser-project.org/mos/view/News/NewsItem/OpenSER-v1.3.4-Released/

Life is going on, from the the latest major release, version 1.4.0, the project boosted in new features, a summary of what is new since then is available here:

http://www.kamailio.org/dokuwiki/doku.php/features:new-in-1.5.x

An important share of effort was directed to clean the code and improve the stability and performance, a proof of maturity and the need to make the maintenance of the project easier and open for new comers. Lot of documentation was added in doxygen format inside the source code, Devel Guide was published, new developers can start new easier to enhance the application.

Reference moment for the future was the launch of SIP Router project in November - a concentration of many people with great SIP and VoIP expertise, backed up by huge programming experience in this field. This came to strengthen the development workforce, to ensure the reliability, to remove the doubts of what projects is better now or is going to develop better in the future.

http://sip-router.org

So, 2009 is an year that announces already great achievements to be done in its first half:

• 1st Quarter - release of Kamailio (OpenSER) 1.5.0
• minor releases for 1.4x and 1.5.x
  
• 2nd Quarter - release of SIP Router project as stable version
• dedicated meeting to celebrate the first operational SIP Router and draw future directions

With the release of SIP Router project, everyone gets access to the features provided by Kamailio (OpenSER), SIP Express Router and OpenIMSCore projects:

http://sip-router.org/benefits/

Looking forward to a fruitful 2009!

Kamailio v1.4.3 Released

A new release in 1.4 series is out. Kamailio 1.4.3 is based on the latest version of branch 1.4, including many fixes in code and documentation, therefore those running 1.4.0, 1.4.1 or 1.4.2 are advised to upgrade.

Source tarballs are available at:

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

Detailed changelog:

http://www.kamailio.org/pub/kamailio/1.4.3/ChangeLog

Download via SVN:

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

Tag for this release can be browsed at:

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

Project site at SourceForge.net (still using old name):

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

Modules' documentation:

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

What is new in 1.4.x release series is summarized in the announcement of v1.4.0:

http://www.kamailio.org/mos/view/KAMAILIO-v1.4.0-Released

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.

Truphone - Call With Your iPod Touch

On 4th of December, 2008, Truphone increased its target market, making available their smart VoIP client available for iPod Touch:
http://truphone.blogspot.com/2008/12/turn-your-ipod-touch-into-phone-with.html

... charming and handy to use. Still loyal to my Nokia phone, but the latest developments from Truphone for iPhone and i'Touch are really tempting ...

Request/Reply Attributes Access From TM

Latest developments provide access to the attributes of reply while processing the request and vice-versa.

The TM module introduces two new features:

• access to SIP request attributes while processing a reply belonging to same transaction
• access to SIP reply attributes while processing a request belonging to same transaction

Functionalities come as pseudo-variables, $T_req(pv) and $T_rpl(pv) - where pv can be any pseudo-variable, check documents at:

http://www.kamailio.org/dokuwiki/doku.php/pseudovariables:devel#tm_module_pseudo-variables

The new pseudo-variables can be used:

• in failure_route to get the attributes of the reply causing the failure route. You can take decisions what to do with the request based on reply details
• in onreply_route to get the attributes of the request. you can take decision what to do with the reply based on request attributes.
• in acc to store data from reply
• in C code (modules)

Note that couple of PV are disabled for these cases (PV will return null) - these are the PV that alter/depend on the context of the processed message, like $Ts, $Tf (but you can use $TS and $TF), $time, destination set attributes. The $avp(...) will be current avps, as they are stored in a global list. Also, in case there is a timeout or other reply generated by kamailio itself, $T_rpl(pv) will return null as there is no real reply structure behind.

Example, print the source ip of the reply in failure route:

failure_route[1] {

    xlog("reply received from: $T_rpl($si)\n");

}

SQLOPS Module

sqlops module focuses to offer fast and easy access to SQL backends directly from the configuration file. Among its features:

• many DB connections - the module can connect to many databases on different servers using different DB driver modules (mysql, postgres, ...) at the same time.
• many DB results - the module can store many results of different SQL queries in separate structures at the same time. Thus is possible to work in parallel with several DB results.
• access via pseudo-variables - the content of SQL query result is accessible via pseudo-variables.
• array indexes - fast access to result values via array possition: [row,column].
• persistence in process space - a result can be used many times in same worker process. Query once, use many times.

Here is an example of fetching and printing the content of a table:

...

modparam("sqlops","sqlcon","ca=>mysql://openser:abc@localhost/openser")

...

sql_query("ca", "select * from domain", "ra");

xlog("rows: $dbr(ra=>rows) cols: $dbr(ra=>cols)\n");

if($dbr(ra=>rows)>0)

{

    $var(i) = 0;

    while($var(i)<$dbr(ra=>cols))

    {

        xlog("--- SCRIPT: column[$var(i)] = $dbr(ra=>colname[$var(i)])\n");

        $var(i) = $var(i) + 1;

    }

    $var(i) = 0;

    while($var(i)<$dbr(ra=>rows))

    {

        $var(j) = 0;

        while($var(j)<$dbr(ra=>cols))

        {

            xlog("[$var(i),$var(j)] = $dbr(ra=>[$var(i),$var(j)])\n");

            $var(j) = $var(j) + 1;

        }

        $var(i) = $var(i) + 1;

    }

}

sql_result_free("ra");

...

Other advantages than the ones listed above against old avp_db_query() function:

- does not mess up fields position if the value in db is null

- use private memory, no locking

- does not iterate through linked (avp) list to get each field, direct

reference to each data structure in result array, thus much faster.

More info at:

http://kamailio.org/docs/modules/devel/sqlops.html

PV and Transformation API Updates

Pseudo-variables and transformations implemented in core for Kamailio (OpenSER) versions <= 1.4.x are now moved in pv module.

This is part of cleaning up the core, in order to keep it slimmer and less exposed to bugs. There are modules and use cases that need no PVs, therefore no need of keeping the implementation of about 100 pseudo-variables and over 30 transformations in core.

Now the core includes only an API that allows to:
- register pseudo-variables
- parse name, evaluate and set value of pseudo-variable
- register transformations
- parse name and evaluate transformations in config file

$shv(...) - shared variables, and $time(...) - broken down time, were moved from cfgutils module to pv module ($shv(...) depends on $var(...)).

To summarise, for devel version (upcoming v1.5.0 release), if you need $ru, $avp(...), $var(...), a.s.o. in your config file you have to load pv module.

Two new pseudo-variables were introduced with this occasion, $TS and $TF, see more:
- http://www.kamailio.org/dokuwiki/doku.php/pseudovariables:devel#string_formatted_time_-_current
- http://www.kamailio.org/dokuwiki/doku.php/pseudovariables:devel#unix_time_stamp_-_current

Code restructuring for Kamailio 1.5.0

The efforts to consolidate the core of Kamailio (OpenSER) and reduce duplicates of code are going on. Several modules with related functionalities were merged in others for a better and easier maintenance.
No functionality was removed, it can be now just found
in a different place.

1. gflags module
The functionality of this module was integrated into the cfgutils module. The internal functionality, function names and MI commands are the same, the parameter “initial” was renamed to “initial_gflags”.

2. options module
The functionality of this module was integrated into the siputils module. The function name was not changed, all parameters were prefixed with the "options_” string.

3. uri module
The functionality of this module was integrated into the siputils module. The function names were not changed, internal functionality is the same.

So starting from the release 1.5 you'll need to fix your "loadmodule" statements and some parameter prefixes in your config if you use one of the mentioned modules. Documentation for the functions can be found in the usual place:

[1] http://www.kamailio.org/docs/modules/devel/cfgutils.html
[2] http://www.kamailio.org/docs/modules/devel/siputils.html

25th Chaos Communication Congress

- Kamailio and 25th Chaos Communication Congress in Berlin...

Henning Westerholt, developer and board member of Kamailio (OpenSER) project, will be present this year at the 25th Chaos Communication Congress in Berlin [1], December 27th to 30th, 2008.

If you go there or you are around Berlin that time, contact Henning in case you want to meet for some hacking sessions and discussions around the Kamailio and SIP-Router projects.

For contact address, see his email posting with this announcement.

http://lists.kamailio.org/pipermail/users/2008-December/020842.html

[1] http://events.ccc.de/congress/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.

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

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

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…