SER - SIP Express Router: Inofficial Configs and Patches

This page offers a collection of information, modules and configuration snippets for SER, the probably most popular Open Source SIP Proxy/Registrar.

All source code linked by this page is, unless otherwise noted, Copyright (c) 2004-2005 Inode Telekommunikationsdienstleistungs GmbH and is licensed under the GNU General Public License (GPL).

All information provided here targets the rel_0_9_0 branch of SER.

• Cacheless user location module
• HA PSTN termination with LCR-Module
• Inofficial UAC-Module backport

Status: PROVEN STABLE

The usrloc module which ships with SER has an internal caching mechanism for performance reasons. On each startup of SER, all domain tables (location and aliases for example) are loaded into shared memory, where the contacts can be looked up very fast by the registrar module.
New registrations can be synchronized into a backend database for persistency.

Although this approach is very efficient regarding performance, it has some major drawbacks:

• Startup delay: Since all entries of the domain tables have to be loaded from the backend on startup and copied into shared memory, it takes some time for SER to be able to serve requests.
• Cache synchronization: The usrloc is only able to write it's cache into the backend, but can't load new contacts from there. This means that every new contact saved on one of the SER servers in a cluster has to be replicated via SIP to all other SER servers, which have to save it into their cache. Unfortunately there is no satisfying solution for this: t_replicate(...) only scales up to 1+1, forward_udp(...) lacks reliable replication and forward_tcp(...) locks all SER processes until the TCP timeout hits if one of the SERs completely crashes.

Using the cacheless approach, one is able to split up proxy- and registrar-functionality on different servers using a stateless outbound proxy, and let the backend database perform data replication.

The outbound proxy distributes register requests to the registrars and all other requests to a proxy cluster and acts as a SIP load balancer. It also does the NAT pinging for keeping NAT bindings to the UACs opened.

Registrars are responsible for adding, updating and deleting user contacts in a backend database (for now only MySQL is supported). Contacts are then replicated to the proxies using MySQL replication.

The proxies lookup contacts from their local databases which are replicated from the registrars. Performance is lower compared to the original userloc module, but you have the advantage that you can add and remove proxies on the fly without needing to change any replication. You just have to propagate the proxy to the outbound proxy which does the load balancing.

Installation

Check out the SER-0.9.x branch from CVS using cvs -d:pserver:anonymous@cvs.berlios.de:/cvsroot/ser co -r rel_0_9_0 sip_router experimental and move experimental/usrloc-cl to sip_router/modules and check sip_router/modules/usrloc-cl/README for installation instructions.

Copyright

The usrloc-cl module is based on the usrloc module which is Copyright (c) 2003 FhG Fokus. All parts taken from this module are explicitely marked. All other parts are Copyright (c) 2005 Andreas Granig.

The LCR module (Copyright (c) 2005 Juha Heinanen) offers the capabilites to select gateways based on the RURI-user and the From-user. But there are some limitations:

• Priority handling is much too strict. Gateways with higher priority are always used first, lower priorities are only used for fallback if no gateway with higher priority is available.
• Many providers use prefix-based PSTN-routing, which is not covered by the LCR module. Inode, for example, uses prefixes to route via specific E1-trunks and to set the Q.931 bearer capability for a call.

The LCR-Capability patch solves these issues by introducing a new table gw_cap for defining capabilities and their corresponding prefix and by changing the gateway selection algorithm to use the lcr.priority column as weight for selecting a gateway. The capability value is treatened as bit-field, so use 1, 2, 4, 8 etc. to select a specific capability in load_gws(...), and combinations of these in the database to set the capabilities.

Example:

In this real world example we use the capability value 1 as phone capability and 2 as fax capability.
The gateways are sipgw1 to sipgw6, where sipgw2 and sipgw6 have phone (prefix "01") and fax (prefix "02") capabilities, the others have only phone capabilities (no prefix).
The phone trunk of sipgw6 has the highest priority (1), the phone trunks of sipgw1, sipgw3, sipgw4 and sipgw5 have the priority 2, sipgw2 has the lowest priority (3).
The fax trunks of sipgw6 and sipgw2 have both the priority 1.

The configuration snippet can be found here, the sample database entries here.

Status: Beta (used in production at Inode, but still lacks some feedback of others)

Update (2005-07-22): Phil D'Amore fixed a serious bug when using AVP also for other things