How To Add Your Own ser.cfg Code

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.

A hook is a piece of code that modifies some feature available through the build system. All hook files have the prefix h_.  Let's say you have included NATi traversal using rtpproxy and you have a bit special setup. The NAT traversal feature specifies that a flag called for example $caller_nated can be set by the hook.  Hence, you can add your special code for detecting whether a caller is behind a NAT device.  The h_*.m4 files document what you can do with that hook.

Once you have done any changes to files in the local directory, you must run make to create the new configuration file. You run 'make default' or 'make yourserver' (a directory below local/) to build the configuration file you want.

With these two simple mechanisms you will have available both the best practice found in the build systems features, you can modify the features, as well as add your own functionality.

Default you get a lot of seperator lines in your ser.cfg that tell you where different code has been included from. You can turn this off by commenting out with dnl the INCLUDE_SEPARATORS macro in config.m4. Explanation of macro: The buildsystem uses M4, which is a system used to define values and substituting those values across many files automatically. dnl is used instead of # or // to identify a comment that should not be included. A macro is just a name for something that has been defined in M4 and that will be substituted.