Book
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
# # $Id: ser i.cfg,v 1.42 2007/05/30 12:28:17 tirpi Exp $ # # First start SER i sample config script with: # database, accounting, authentication, multi-domain support # PSTN i 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.
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.
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.)
Quick StartChange 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/ser i/), or copy the resulting ./ser_default.cfg to where SER i 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).
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.
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.
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).
This is an overview about the design of SEMS i.
NAT i traversal with RTP i 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.
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")).
There is a new module called TLS in the cvs repositoryi. The module attempts to merge the TLS code from experimental cvs module (maintained by Cesc) and Andrei's implementation, to get the best of both. Furthermore the module contains some new functions for script based certificate verification. The TLS module is much more stable than the original implementation. The original (experimental) code works only when there are no simultaneous TLS connections/attempts. The original code would either crash or block SERi in seconds under heavy load so it is not really suitable for production use.
In the etc directory of SERi Ottendorf, you will find seri-basic.cfg and ser.cfg as two examples. Please note the following changes: routes can now have names: route["test"] routes can return a value drop and exit are synonyms flags now have names setflag("cool") The use of selects @something has changed how read-only data can be accessed avpairs can now be directly accessed using $avpairname Fifo support was removed from core and "fifo=something" in the config file will produce an error.
There is one major difference between select (@) and AVP($). The select is READ-ONLY "function", the AVP could be used as variable ('coz is read/write). The select helps to get direct access to some parts of request within the script (like @to, @cseg.method, @msg.["P-anyheader-youwant"]), but generally could be seen as function returning a string with certainnumber of parameters. Each module can extend the syntax the select framework understands registering it's own select table. Look on TLS module or db_ops as good samples. The AVPs are sorted into classes and tracks:
GENERAL class (same for both FROM and TO track)
DOMAIN class
USER class
with one interesting feature, that the AVP accesse by the track prefix only is searched in the USER class, if not found in DOMAIN class and then in GLOBAL class, so you can define GLOBAL value, which is overrided by DOMAIN (if desired) and by USER AVPs.
This book is a collection of documents intended to document changes from 0.9.x to 2.0, as well as new features in 2.0. Feel free to add book pages or edit existing ones if you have some experiences! (or you can add a comment). The presence functionality of SERi 2.0 (Ottendorf) is documented in the presence handbook. NOTE!!! The initial text and info has just been pasted in from various sources and has not been edited to form standalone, not-too-technical information!
|
