Archive for 2006

OpenSER in Debian Unstable distribution

August 7th, 2006

Thanks to work of Julien Blache and VoIP packagers group from Debian, OpenSER is available via Debian Unstable official distributing channels.

You can use their APT repositories to install OpenSER. For more see:

http://packages.debian.org/unstable/net/openser

http://openser-project.org/pipermail/users/2006-August/006089.html

OpenSERAdmin released

August 4th, 2006

OpenSER Administrator, a web interface for managing OpenSER written in Ruby on Rails, has been officially released.

The home page of the project is http://openseradmin.sourceforge.net. There you can find screenshots (http://sourceforge.net/project/screenshots.php?group_id=172510), documentation and download links.

Database fetch support

July 14th, 2006

Just few days after the last major release , new appealing feature was introduced in the development version.

Until now, when dealing with large number of subscribers, old OpenSER required tunings and recompilation to resize the private memory large enough so that all location records from database could be loaded. It was quite annoying because this private memory was used only once, at startup, afterwards most of it was not used at all by the SIP server, but it was allocated and no other application could use it.

The new features loads chunks of records, the size of the chunk being configurable and specific for the available private memory. The issue is now solved in OpenSER, allowing straightforward deployments for carrier grade platforms. This adds more value to the features introduced with the latest release that enabled geographic distribution/failover and load balancing.

For a better understanding of the old issue, below is technical description along with some test results …

OpenSER allocates for each process it starts a chunk of private memory. The default is 1MB. This size is enough for processing a SIP message and all other tasks during run time. To load the location table with hundreds of thousands records, the internals of  OpenSER had to be tunned, then the application recompiled and reinstalled. As example, for 120 000 location records, if you run the SIP server with 32 processes and because of location table size, you would have to increase the private memory to 32MB, a total of 1GB would have been allocated just for private memory. But only one process required 32MB, the one which loaded the location table, and only once during OpenSER runtime: at startup.

From the tests, after loading about 4300 user location records, the 1MB private memory was exhausted and the SIP server didn’t start. Using the new OpenSER feature, and the default OpenSER configuration (4 worker processes, each with 1MB of private memory, and 32MB share memory), more than 120 000 user location records were loaded with no hacking. The total system memory used was 39MB (7*1MB private + 32MB share; 7 = 1 main process + 1 FIFO process + 1 timer process + 4 worker processes). The old version required about 256MB (7*32MB private + 32MB share). The memory size would have increased dramatically if you enable TCP/TLS and used more worker processes.

At this moment, only MySQL driver in OpenSER has support for fetch capability. Soon, PostgreSQL and UnixODBC drivers will be updated.

OpenSER v1.1.0 Released

July 10th, 2006

After about eight months since the latest major release, the development branch is released as stable. Following the two months testing phase, today the source tree concluded in OpenSER v1.1.0.

First, we like to thank to all developers and contributors which have put a lot of effort to have v1.1.0 out. At this moment, we counted more than 60 contributors to OpenSER and 13 registered developers.

The release comes short after one year cellebration of OpenSER project and brings a bag full of new features:

- statistics support – monitoring OpenSER internals is straightforward and gives realtime feedback about your VoIP platform

- secure communication – TLS got more flexibility and maturity

- dialog support – new module to monitor active calls within your system

- OSP – new module for secure VoIP peering based on OSP

- geographic distribution – via the new ‘path’ module and cacheless user location you can distribute your SIP servers all over the world and serve same subscriber base

- geographic redundancy and failover – above item together with DNS records can be used to deploy full redundant VoIP platforms distributed geographically

- signaling monitoring – the new module ‘siptrace’ gives you the oportunity to monitor and trace the signaling level of the calls within your system as enforced by interception law

- more database backends – with the new ‘unixodbc’ module, the range of database types that can be used with openser grew exponentially. Basically, any database which has a ODBC/UNIXODBC driver can be used now.

Complete list with the new features in OpenSER v1.1.0 can be read here .

To get a feeling about the improvements in OpenSER v1.1.0, have a look at raw changelog on CVS.

OpenSER WebSite has a new look

July 10th, 2006

Thanks to Elena-Ramona Modroiu‘s efforts, OpenSER web site has a new look. We hope that will ease the user experience in finding quickly desired information.

The site uses the Mambo engine, and will allow community members to get involved in OpenSER site management.

We welcome graphic designers to submit new templates or logos to give more personalized look to web pages.

OpenSER one year old

June 6th, 2006

Today, June 14, 2006, OpenSER project celebrates one year

One year ago, Daniel-Constantin Mierla, Elena-Ramona Modroiu and Bogdan-Andrei Iancu, (co-founders, core and main developers of SIP Express Router (SER)) started the OpenSER Project.

The project started with release v0.9.4 and since then important milestones and success stories were achieved. Three new stable releases (v0.9.5 – July 01, 2005, v1.0.0 – October 28, 2005, and v1.0.1 – February 27, 2006), including a major one (v1.0.0). Another major release, v1.1.0 is just several days away, development being frozen for three weeks by now, testing and bug fixing being in advanced phase.

Maybe one of the biggest achievements is the OpenSER user community. After first year, over 800 users are subscribed to OpenSER mailing lists. Over 60 were submitting patches and improvements to source code or documentation (see contributions page). User experience exchange seems to be very good, over 8000 messages on the mailing list, the web forum gets better and better shape, the dokuwiki collected good tutorials, documentation repository includes updated module docs and many tutorials.

Several important features brought to OpenSER during this year: TLS support, pseudo-variables, NAPTR query support, serial forking in core, statistics in core, many new modules ( alias_db, dialog, lcr, osp, path, siptrace, speeddial, statistics, tlsops, uac, uac_redirect, unixodbc ), big enhancements to old modules ( acc, avpops, dispatcher, enum, nathelper, registrar, tm, usrloc ) – you can find more reading the news archive from OpenSER site.

The plans for future include: SIP/SIMPLE presence, TLS multidomain, script variables, unified management interface, full dialog support, other database connectors.

Project’s development is managed by OpenSER advisory board. We would like to thank to all developers and community members for their support, testing and contributions. We welcome new ideas and contributions, suggestions and improvements to existing components.

See OpenSER History for more about how the project evolved and its maturity.

If you want to send us a message, please use team (at) openser-project . org or users (at) openser-project . org

CVS frozen for v1.1.0 testing

May 25th, 2006

At midnight, Tuesday 00:00 GMT, the CVS will be frozen and the 1.1.0 branch will enter in a testing and fixing phase – no new stuff will be committed on the cvs, just bugs and conformity fixes.

We encourage the users to intensively run and test this version and to report any bugs or misbehavior. The target is to have the next release in about one month, when hopefully the cumulate fixes will provide a high level of the stability.

So, please test and report any problem you find – this will help us to accelerate the process.