SIP Express Router Configuration Buildsystem

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.

Why a build system?

SIP Express Router was built to be very flexible and powerful through ser.cfg, close to a full programming language in itself. This is needed to support complex deployments and a myriad of installation scenarios with multi-server setups, peering, and all sorts of special applications. Unfortunately this has (at least) two consequences: 

• Getting started using SERi can be complex because even minor adaptions of an example configuration can cause problems if the person changing it does not fully understand why things were done the way they were done
• A production ser.cfg configuration file can easily be 2-3,000 lines of code and can be quite complex to maintain, especially if several people work together

The SER - Getting Started document and configuration files is a good starting point for beginners and have become established best practice for SER configuration files. This build system includes the Getting Started features, so that you can use those features and easily add your own.

This build system will do the following for you:

• Get you started using SER in no way by interactively allowing you to specify your local settings in clear language and then producing a functioning ser.cfg
• Allow you to use the basic features that are included in the build system while still adding your local adaptations and functionality
• Allow you to split up your configuration in smaller files, which you then can maintain fairly independently
• Simplify management of multiple servers by allowing you to maintain common code in one place, but still have variations across servers
• Reduce the work needed when migrating from one version to another because you just replace the templates and your local modifications according to the release notes