iptel.org - Book

SIP Express Bundle - Project Page

Fri, 14 Dec 2007 09:50:32 +0100

This is the main entry page for documentation and coordination of the SIP Express Bundle project.

SIP Express Bundle

Create a way for people to quickly get a running server with all iptel.org software pre-installed and configured to work with each other
Through a wizard or script (OS or web-based) guide the user through local configurations all the way to a functioning system where calls can be made to/from one or more domain names (dependent on DNS configuration)
Document precisely how the installation is done once a basic OS has been installed, so that people

Standard ser.cfg

Wed, 17 Oct 2007 08:44:53 +0200

#
# $Id: seri.cfg,v 1.42 2007/05/30 12:28:17 tirpi Exp $
#

# First start SERi sample config script with:
#   database, accounting, authentication, multi-domain support
#   PSTNi GW section, named flags, named routes, global-,
#   domain- and user-preferences with AVPs
# Several of these features are only here for demonstration purpose
# what can be achieved with the SER config script language.
#
# If you look for a simpler version with a lot less dependencies
# please refer to the ser-basic.cfg file in your SER distribution.

SER 2.0 Migration Guide

Tue, 22 May 2007 09:57:24 +0200

Test

The SER Getting Started Log System

Tue, 24 Apr 2007 18:13:12 +0200

The Getting Started Log System

Experience has shown that finding errors in a SERi configuration file can be tricky. Based on experience on supporting SER users on all levels on serusers and serdev, this log system has been developed to be of benefit to both beginners and experts (called 'Getting Started Log System' because it was in that effort it was created). The main idea is to create a coherent and simple way of logging in seri.cfg. For example, the Getting Started feature package uses this standardized logging so that people with problems can submit logs that can easily be read by anyone familiar with how Getting Started uses logging.

Advanced Control When You Add Own Code

Tue, 24 Apr 2007 18:10:44 +0200

Advanced Control When You Add Own Code

You keep common code for all your servers in the common/ directory. In addition, you can add specific code for a given server in the servername/ (or default/) directory. If you need even more detailed control, for example you want to keep code for a specific feature in the common/ directory, but have small server-variations, the config.m4 defines two macros you can use to selectively include code based on which server you are generating seri.cfg for: CFG_NAME and CFG_servername.

CFG_NAME is set to the name of the server, i.e. default or servername, while the macro CFG_default is defined when you generate the default configuration, CFG_rocky4 is defined when you generate the configuration for the rocky4 server, and so on.

Getting Control On Feature Level

Tue, 24 Apr 2007 18:07:29 +0200

Getting Control on Feature Level

Default you use the make command and it will control which feature package and feature sets that are included based on your config.m4. For example, you specified you wanted to use the NATi handling configuration SERi - Getting Started file, and the rest is automatic.

In order to gain control on the feature level and decide specifically which features to include, you need to change your config.m4. In order to include a feature, you need to define the macro that controls it inclusion. Each feature package has a two-letter prefix. This is GS_ for Getting Started. When new features or feature packages are added to the buildsystem, the configure script will be updated to make sure that the config.m4 file that is generated documents all the available features. The configure file is thus the best documentation of all the features available.

How To Add Your Own ser.cfg Code

Tue, 24 Apr 2007 17:58:46 +0200

How To Add Your Own seri.cfg Code

The build system includes many features (and is extendable, so more will be added). It also includes a logging system that is useful for debugging and posting problems to the iptel.org mailing lists.

However, not before long you will want to add your own functionality and thus want to add code to your SERi configuration files. There are two basic ways you can do this: scriptlets and hooks.

A scriptlet is basically some lines of code that are fairly independent of other code (like loading a module or setting a parameter). In your local/common directory you will find several files called loadmodules.m4, directives.m4 etc. These are scriptlets where you can add your code. Each scriptlet file has info about its functionality. Scriptlets are found in the common directory for doing things for all your servers, as well as in default/myserver directories. The scriptlets are copied into the local/ directories when you run configure.

Tailoring The Configurations

Tue, 24 Apr 2007 17:55:02 +0200

How To Tailor The Configurations

Now that you have tried the buildsystem, you need to know how to make changes that will modify your seri.cfgs to do what you want. Obviously, you can run configure again, either using ./configure default new (to explicitly say that you want to overwrite your previous configuration) or by creating a new server configuration using ./configure newconfig. Each time you run configure with a parameter, a new directory under local/ will be created for your configuration. And when you run make to generate a new configuration file, you use the name of the configuration you want to build, ex. make newconfig. The buildsystem will then use the configurations found in local/common and local/newconfig to create a new SERi configuration file called ser_newconfig.cfg (and if you don't specify a config, you now know that default will be used and ser_default.cfg will be created.)

QuickStart

Tue, 24 Apr 2007 17:47:19 +0200

Quick Start

Change directory to the buildsystem main dir sip_router/etc/buildsystem
Type ./configure
Answer the questions (or simply except the defaults by pressing ENTER)
Type: make (to create the default configuration file)
Type: make install (to install to the default config dir (/usr/local/etc/seri/), or copy the resulting ./ser_default.cfg to where SERi expects to find ser.cfg)
make install will copy ser_default.cfg to your config dir. Create a symbolic link to it for ser.cfg (ln -s ser_default.cfg ser.cfg).

SIP Express Router Configuration Buildsystem

Tue, 24 Apr 2007 17:43:19 +0200

Introduction

This is an overview of the rationale behind the build system for SIP Express Router configuration files, seri.cfg. It also is an introduction to how to use the build system.

The buildsystem has been commited to CVSi, the rel_2_0_0 tagi, and will be a part of the final 2.0 release. It was not part of Release Candidate 1, so if you want to download the buildsystem separately, you can download it from ftp://siprouter.teigre.com/pub/buildsystem. The latest is ftp://siprouter.teigre.com/pub/buildsystem/ser.buildsystem.latest.tar.gz. The requirements are linux shell and m4 (installed on most systems). The changelog tells you what has been updated lately.

Introduction to Selects and Attributes

Tue, 12 Dec 2006 21:12:56 +0100

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.

How the new timer framework works

Tue, 17 Oct 2006 09:46:10 +0200

THANKS to Andrei for giving the actual info on the new timer implementation!!

The timers of the tm module can be confusing and normally you don¨t have to (or should) tweak timers except the fr_inv_timer (controlling "how long to ring"). The below table is an overview of the timers that can be changed from seri.cfg, how they correspond to the timer names in RFC3261 and how/why you would want to change it.

The timers for SERi 0.9.x are documented in the FAQ.

In 0.10.x the timer implementation has been completely rewritten. The timers are now controlled in milliseconds and (not in seconds as in 0.9.x), e.g. modparam("tm", "fr_timer", 30000) => default value of 30s. The timer have a resolution of 1/TIMER_TICKS_HZ. This is default 62.5 ms. Thus, the timer can fire every 62.5 ms. Note that this also is the error interval (they can fire anywhere in a 62.5 ms interval from their "theoretical" expire point).

SEMS design overview

Thu, 12 Oct 2006 15:21:56 +0200

This is an overview about the design of SEMSi.

Optimizing the use of RTP proxy

Mon, 18 Sep 2006 09:51:38 +0200

NATi traversal with RTPi proxy deals with all kinds of NAT but should be used when is really needed. This document describes how to optimize the use of RTP proxy. The full configuration file is available in attachments.

named routes

Fri, 15 Sep 2006 17:36:02 +0200

seri supports named routes: names can be used instead of numbers in all the route commands or route declarations.
Example:

route{

route("test");
...
}

route["test"]{
...
}

The old route(number) is equivalent with route("number") (e.g. route(2) is equivalent with route("2")).