iptel.org - ser.cfg

how to setup sems ( ivr + voice mail)

Mon, 05 May 2008 10:08:21 +0200

Suggestion for outline of new SER reference manual

Sun, 06 May 2007 09:46:48 +0200

Status:
Ongoing discussion

Finally making SER accessible to newcomers, while keeping the strength of its configuration language!

Tue, 24 Apr 2007 18:26:31 +0200

One big problem with SERi has been the complexity of the SER configuration language. Only apache (httpd) can (almost) compare in the flexibility and number of ways a piece of software can be configured. This has resulted in a pretty steep learning curve for beginners. SIP can be used for an increasing number of applications and each deployment has its own, specific needs. Thus, SER's configuration language must be powerful.

The professional SER user has other issues, like maintaining multiple configurations across server farms and setups, sharing some code, but still needing individual tailoring to each server. '

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.

Getting More Granular Control

Tue, 24 Apr 2007 18:00:42 +0200

Getting More Granular Control

Creating your configurations based on the Getting Started files may be fine for a while, but then you decide that you don't really want the included authentication code or something else. Then you need more granular control of which features get included. In your config.m4 you will find an example of how to do this, but first you need to understand how the build system is built up.

The core of the build system is built on a basic structure. This structure structures seri.cfg the way professionals would do it and based on fundamentals in how SIP works (see next chapter for more details). This basic structure is always enforced and can be found in the templates/*.m4 files.

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.)

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.

Documentation search

Wed, 18 Apr 2007 11:26:27 +0200

PLEASE wait until the data loads, then change the header fields to update the table's content.

F: R: P: S: ?

Insufficient documentation ?


{dsRecords::module}	{dsRecords::version}	{dsRecords::type_name}	{dsRecords::name}	Report

What Does "ERROR: error -478 while trying to fix configuration" Mean?

Wed, 08 Nov 2006 19:59:35 +0100

Should I Use Double Quotes With src_ip Checks Or Not?

Mon, 06 Nov 2006 14:14:44 +0100

What Is An Alias And How Do I Create One?

Mon, 06 Nov 2006 14:12:01 +0100

How Do I Use The textops Function subst() For String Substitution?

Mon, 06 Nov 2006 14:05:43 +0100