In earlier versions of SERi, only a very limited amount of information related to the request being processed was available in the routing script. The amount of things that could be done in the script thus was rather limited. Many scenarios required the user to actually write a new module.

In SER 0.9 this situation changed somewhat with the introduction of AVPs. The original concept was to store some information for your users in a database table and load them on demand. The avpops module even allowed to manipulate the information albeit not in a very intuitional way.

For SER 2.0 the concept was spiced up a bit. AVPs are now called just attributes and are available in a more intuitive way. Even more, a new framework was introduced to allow access to all sorts of information from the request and SER's entrails. The developers decided to call it the select framework.

Ottendorf tests

Here are some Ottendorf performance tests. The page will be updated according to progress in testing.

Registrar with database tuning. (updated on 25th May 2007)

Memory allocation methods

Many people wonder, why there are non-standard memory allocation methods used within SERi. I run some tests which show significant difference between standard malloc/free and SER's allocation methods. (Memory management is one of most critical parts related to SIP performance.)

There are many ways to good performance for networking-based software.  SERi performs with a large number of subscribers on a single server, sufficient for most installations. And using various techniques building a SIP network architecture, you can make SER scale to an unlimited number of subscribers. However, we want SER's core and core modules to be based on sound design principles and architected with performance in mind. These components are used by everybody, from the simplest seri.cfg for proxying large number of call per second to the small "home-grown" setup with a huge ser.cfg executing all kinds of logic for every single message.

There is one major difference between select (@) and AVP($). The select is READ-ONLY "function", the AVP could be used as variable ('coz is read/write).

The select helps to get direct access to some parts of request within the script (like @to, @cseg.method, @msg.["P-anyheader-youwant"]), but generally could be seen as function returning a string with certainnumber of parameters.

Each module can extend the syntax the select framework understands registering it's own select table. Look on TLS module or db_ops as good samples.

The AVPs are sorted into classes and tracks:
GENERAL class (same for both FROM and TO track)
DOMAIN class
USER class
with one interesting feature, that the AVP accesse by the track prefix only is searched in the USER class, if not found in DOMAIN class and then in GLOBAL class, so you can define GLOBAL value, which is overrided by DOMAIN (if desired) and by USER AVPs.

This is the page where YOU add your most wanted SERi features or modules! Please feel free to edit this page.

See a more detailed list of wishlist items on the tracker (items on this wishlist will end up in the tracker when they are detailed enough to do actual coding).

New groups can also be added. This wishlist is used for evaluating what to focus on for future releases.

In order to know the general interest of a feature, you can also vote for features. Just add an * in parenthesis behind the feature, and please only add one...