This project deals with SIP network within IP anycast environment where in our case two SERi clusters are multihomed in Prague and Berlin. The aim of this project is to test these two clusters from Planet lab nodes where will be running SIPcraft as a measurement tool. Different locations of Planet Lab nodes will provide a test bed where we will be able to see which SER cluster and also RTPi proxy is selected for each SIPcraft installation. One of the crucial parts of selecting specific SER cluster/RTP proxy will depend on routing logic of the Internet. The result of using these SER clusters should provide a good latency and availablity of a SIP service especially selecting the appropriate RTP proxy and used for the purpose of iptel.org's SIP service in near future.
Eval module =========== Author: tomas.mandys at iptel dot org The module implements expression evaluation in route script, i.e. enables e.g. addition, concatanation, value items etc. There are two basic types: integer and string. Operation are processed using values on stack and polish notation. Besides the stack there are also register that may be accessed by quick manner in run time, via select or stack manipulation functions, because they are fixed during fixup phase. This depends on libuuid shared library. Module parameters: ----------------- declare_register: string; Declares one register, multiple declaration supported Example: modparam("eval", "declare_register", "ax"); modparam("eval", "declare_register", "bx"); modparam("eval", "declare_register", "cx"); modparam("eval", "declare_register", "dx"); xlbuf_size: int; Default: 4096 Size of buffer for xlib formating.
Release candidate 1 has been thoroughly tested and also used in several commercial production environments. It has thus proven stable.
You can either compile SER from the sources or install a binary package. Standard SER is fairly easy to compile, so compiling it from sources should be fine. You should have a SER 2.0 up and running in 15-30 minutes by following the procedures below!
SER CVS as off January 18, 2007
Generic LDAPi module that handles connection to the ldap server and exports a simple API to interact with the server. Also, a LDAP authentication module that uses the API exported from the generic LDAP module.
Save the patchfile to the directory with the file to patch, then (having that directory as current) use the command 'patch -p0 < patchfile.txt'
LDAPi module configuration:
modparam("ldap", "ldap_version", 3) <= optional, possible values are 1, 2 or 3
modparam("ldap", "ldap_url", "ldap://localhost:389") <== optional, defaults to "ldap://localhost", ldaps connections require ldap_version >= 2
Module for doing XCAP queries.
This module covers functions called internaly to access XCAP server. These functions were separated into standalone module to allow simple replacing XCAP queries with queries into database or local filesystem or whatever else. Next reason was to protect other modules from linking with libcurl (implements HTTP) or other such stuff.
URIi check using Radius server.
Resource lists server is a server which allows subscriptions to lists of users. Its behaviour is defined in [rls] and [sip rls]. As described there, it uses XCAP server for storing data about lists of users. These data can be manipulated in any way by user's client software.
This module implements a presence server, i.e. entity that receives SUBSCRIBE requests and sends NOTIFY when presence status of a user changes and allows user to use PUBLISH request for publishing presence status information.
The osp module enables SERi to support secure, multi-lateral peering using the OSP standard defined by European Telecommunications Standards Institute (ETSIi) (TS 101 321 V4.1.1). Open Settlement Protocol uses Public Key Infrastructure (PKI) services to enable, secure peering among anonymous peers. OSP is an ETSI standard and enables VOIP networks to exchange billing, Quality of Service (QoS), and routing information.
Least cost routing (LCR) module implements two related capabilities:
LCR may sequentially forward requests to one or more gateways using the load_gws and next_gw functions.
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.
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.
This module acts as back to back user agent for presence events. In the future it will do subscriptions to reg events and presence with resource lists too.
It is accessible only using internal Querry Status API (QSA). Everywhere (in C code) you need subscriptions to presentity status, you only create an internal subscription to it and the rest is done by this module. It processes internal subscription and creates a SIP subscription (SUBSCRIBE-NOTIFY dialogi) to requested presentity. Every NOTIFY request produces new QSA message with status information into destination message queue.
The module implements all the operations regarding MaX-Forward header field, like adding it (if not present) or decrementing and checking the value of the existent one.
Jabber module integrates XODE XML parser for parsing Jabber messages. That introduces a module dependency: expat library.
Expat is a common XML library and is the fastest available for Linux/Unix, the second over all, after msxml library. It is integrated in most of well known Linux distributions.
cpl-c modules implements a CPLi (Call Processing Language) interpreter. Support for uploading/downloading/removing scripts via SIP REGISTER method is implemented.
avp_radius module allows loading of user's attributes into AVPs from Radius. User's name and domain can be based on From URIi, Request URI, or authenticated credentials. The module assumes that Radius returns the AVPs as values of reply attribute SIP-AVP. Its value must be a string of form "name:value"
This module contains functions that are used to perform authentication using a Radius server. Basically the proxy will pass along the credentials to the radius server which will in turn send a reply containing result of the authentication. So basically the whole authentication is done in the Radius server. Before sending the request to the radius server we perform some sanity checks over the credentials to make sure that only well formed credentials will get to the server. We have implemented radius authentication according to draft-sterman-aaa-sip-00.
This module provides the possibility to print user formatted log or debug messages from SERi scripts, similar to printf function but now a specifier is replaced with a part of the SIP request. the section called "Implemented Specifiers" shows what can be printed out.
User location module. The module keeps a user location table and provides access to the table to other modules. The module exports no functions that could be used directly from scripts.
UACi (User Agent Client) module provides some basic UAC functionalities like FROM header manipulation (anonymization) or client authentication.
TM module enables statefuli processing of SIP transactionsi. The main use of stateful logic, which is costly in terms of memory and CPU, is some services inherently need state. For example, transactioni-based accounting (module acc) needs to process transaction state as opposed to individual messages, and any kinds of forkingi must be implemented statefully. Other use of stateful processing is it trading CPU caused by retransmissioni processing for memory. That makes however only sense if CPU consumption per request is huge. For example, if you want to avoid costly DNS resolution for every retransmission of a request to an unresolvable destination, use stateful mode. Then, only the initial message burdens server by DNS queries, subsequent retransmissionsi will be dropped and will not result in more processes blocked by DNS resolution. The price is more memory consumption and higher processing latency.
This module implements text based operation (search, replace, append a.s.o). Many functions support xl_lib formating using xlog module.
This module provides on-server speed dial facilities. An user can store records consisting of pairs short numbers (2 digits) and SIP addresses into a table of SERi. Then it can dial the two digits whenever he wants to call the SIP address associated with those digits.