ser.cfgOne 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 Getting Started Log SystemExperience 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 CodeYou 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 LevelDefault 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 ControlCreating 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 seri.cfg CodeThe 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. How To Tailor The ConfigurationsNow 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.) IntroductionThis 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. PLEASE wait until the data loads, then change the header fields to update the table's content.
» 24 comments | read more
seri supports named routes: names can be used instead of numbers in all the route commands or route declarations. route{ route("test"); route["test"]{ The old route(number) is equivalent with route("number") (e.g. route(2) is equivalent with route("2")). SERi's management interface has been rewritten. Former SER releases had a managment interface hardcoded in the core with support for FIFO and UDP. The new release introduces a management RPC (Remote Procedure Call) API provided by the SER core, but where independent transport protocol implementations are found in a module (i.e. how you call the management functions, ex. XMLRPC). In the etc directory of SERi Ottendorf, you will find seri-basic.cfg and ser.cfg as two examples. Please note the following changes:
|
Navigation |
||||||||||||
