Massively changing "Kamailio" to &kamailio;

modules_k/acc/doc/acc_admin.xml

@@ -119,10 +119,10 @@
 		In particular, accounting secret must match that one configured in
 		server and proper dictionary is used (one is available at 
 		etc/sip_dictionary). Also note that Debian radiusclient-ng uses
-		/var/run/radius.seq as seqfile but Kamailio Debian init script expects
+		/var/run/radius.seq as seqfile but &kamailio; Debian init script expects
 		/var/run/kamailio/kamailio_radius.seq, so is needed to change it in
-		radiusclient-ng configuration or in Kamailio Debian init script (if not,
-		Kamailio can't create the seq file when not running as root). Uses along
+		radiusclient-ng configuration or in &kamailio; Debian init script (if not,
+		&kamailio; can't create the seq file when not running as root). Uses along
 		with FreeRadius (<ulink url='http://www.freeradius.org/'>
 		http://www.freeradius.org/</ulink>) and Radiator 
 		(<ulink url='http://www.open.com.au/radiator/'>

modules_k/benchmark/README

@@ -19,53 +19,53 @@ Bastian Friedrich
 
    Copyright © 2007 Voice System SRL
    Revision History
-   Revision $Revision: 1.1.1.1 $ $Date: 2007-04-11 14:40:39 +0200
-                                 (Mi, 11 Apr 2007) $
-     __________________________________________________________
+   Revision $Revision: 1.1.1.1 $ $Date: 2007-04-11 14:40:39 +0200 (Mi, 11
+   Apr 2007) $
+     __________________________________________________________________
 
    Table of Contents
 
    1. Admin Guide
 
-        1.1. Overview
-        1.2. Dependencies
+        1. Overview
+        2. Dependencies
 
-              1.2.1. Kamailio Modules
-              1.2.2. External Libraries or Applications
+              2.1. Kamailio Modules
+              2.2. External Libraries or Applications
 
-        1.3. Exported Parameters
+        3. Exported Parameters
 
-              1.3.1. enable (int)
-              1.3.2. granularity (int)
-              1.3.3. loglevel (int)
+              3.1. enable (int)
+              3.2. granularity (int)
+              3.3. loglevel (int)
 
-        1.4. Exported Functions
+        4. Exported Functions
 
-              1.4.1. bm_start_timer(name)
-              1.4.2. bm_log_timer(name)
+              4.1. bm_start_timer(name)
+              4.2. bm_log_timer(name)
 
-        1.5. Exported pseudo-variables
+        5. Exported pseudo-variables
 
-              1.5.1. $BM_time_diff
+              5.1. $BM_time_diff
 
-        1.6. Exported MI Functions
+        6. Exported MI Functions
 
-              1.6.1. bm_enable_global
-              1.6.2. bm_enable_timer
-              1.6.3. bm_granularity
-              1.6.4. bm_loglevel
+              6.1. bm_enable_global
+              6.2. bm_enable_timer
+              6.3. bm_granularity
+              6.4. bm_loglevel
 
-        1.7. Example of usage
+        7. Example of usage
 
    2. Developer Guide
 
-        2.1. Available Functions
+        1. Available Functions
 
-              2.1.1. bm_register(name, mode, id)
-              2.1.2. bm_start(id)
-              2.1.3. bm_log(id)
+              1.1. bm_register(name, mode, id)
+              1.2. bm_start(id)
+              1.3. bm_log(id)
 
-        2.2. Benchmark API Example
+        2. Benchmark API Example
 
    List of Examples
 
@@ -80,41 +80,78 @@ Bastian Friedrich
 
 Chapter 1. Admin Guide
 
-1.1. Overview
+   Table of Contents
+
+   1. Overview
+   2. Dependencies
+
+        2.1. Kamailio Modules
+        2.2. External Libraries or Applications
+
+   3. Exported Parameters
+
+        3.1. enable (int)
+        3.2. granularity (int)
+        3.3. loglevel (int)
+
+   4. Exported Functions
+
+        4.1. bm_start_timer(name)
+        4.2. bm_log_timer(name)
+
+   5. Exported pseudo-variables
+
+        5.1. $BM_time_diff
+
+   6. Exported MI Functions
+
+        6.1. bm_enable_global
+        6.2. bm_enable_timer
+        6.3. bm_granularity
+        6.4. bm_loglevel
+
+   7. Example of usage
 
-   This module helps developers to benchmark their module
-   functions. By adding this module's functions via the
-   configuration file or through its API, Kamailio can log
-   profiling information for every function.
+1. Overview
 
-   The duration between calls to start_timer and log_timer is
-   stored and logged via Kamailio's logging facility. Please note
-   that all durations are given as microseconds (don't confuse
-   with milliseconds!).
+   This module helps developers to benchmark their module functions. By
+   adding this module's functions via the configuration file or through
+   its API, Kamailio can log profiling information for every function.
 
-1.2. Dependencies
+   The duration between calls to start_timer and log_timer is stored and
+   logged via Kamailio's logging facility. Please note that all durations
+   are given as microseconds (don't confuse with milliseconds!).
 
-1.2.1. Kamailio Modules
+2. Dependencies
+
+   2.1. Kamailio Modules
+   2.2. External Libraries or Applications
+
+2.1. Kamailio Modules
 
    The following modules must be loaded before this module:
      * No dependencies on other Kamailio modules.
 
-1.2.2. External Libraries or Applications
+2.2. External Libraries or Applications
 
-   The following libraries or applications must be installed
-   before running Kamailio with this module loaded:
+   The following libraries or applications must be installed before
+   running Kamailio with this module loaded:
      * None.
 
-1.3. Exported Parameters
+3. Exported Parameters
+
+   3.1. enable (int)
+   3.2. granularity (int)
+   3.3. loglevel (int)
 
-1.3.1. enable (int)
+3.1. enable (int)
 
    Even when the module is loaded, benchmarking is not enabled per
    default. This variable may have three different values:
      * -1 - Globally disable benchmarking
-     * 0 - Enable per-timer enabling. Single timers are inactive
-       by default and can be activated through the MI interface as
-       soon as that feature is implemented.
+     * 0 - Enable per-timer enabling. Single timers are inactive by
+       default and can be activated through the MI interface as soon as
+       that feature is implemented.
      * 1 - Globally enable benchmarking
 
    Default value is "0".
@@ -124,11 +161,11 @@ Chapter 1. Admin Guide
 modparam("benchmark", "enable", 1)
 ...
 
-1.3.2. granularity (int)
+3.2. granularity (int)
 
-   Logging normally is not done for every reference to the
-   log_timer() function, but only every n'th call. n is defined
-   through this variable. A sensible granularity seems to be 100.
+   Logging normally is not done for every reference to the log_timer()
+   function, but only every n'th call. n is defined through this variable.
+   A sensible granularity seems to be 100.
 
    Default value is "1".
 
@@ -137,10 +174,9 @@ modparam("benchmark", "enable", 1)
 modparam("benchmark", "granularity", 500)
 ...
 
-1.3.3. loglevel (int)
+3.3. loglevel (int)
 
-   Set the log level for the benchmark logs. These levels should
-   be used:
+   Set the log level for the benchmark logs. These levels should be used:
      * -3 - L_ALERT
      * -2 - L_CRIT
      * -1 - L_ERR
@@ -158,35 +194,37 @@ modparam("benchmark", "loglevel", 4)
 
    This will set the logging level to L_DBG.
 
-1.4. Exported Functions
+4. Exported Functions
 
-1.4.1.  bm_start_timer(name)
+   4.1. bm_start_timer(name)
+   4.2. bm_log_timer(name)
 
-   Start timer "name". A later call to "bm_log_timer()" logs this
-   timer..
+4.1. bm_start_timer(name)
+
+   Start timer "name". A later call to "bm_log_timer()" logs this timer..
 
    Example 1.4. bm_start_timer usage
 ...
 bm_start_timer("test");
 ...
 
-1.4.2.  bm_log_timer(name)
+4.2. bm_log_timer(name)
 
-   This function logs the timer with the given ID. The following
-   data are logged:
-     * Last msgs is the number of calls in the last logging
-       interval. This equals the granularity variable.
+   This function logs the timer with the given ID. The following data are
+   logged:
+     * Last msgs is the number of calls in the last logging interval. This
+       equals the granularity variable.
 
      * Last sum is the accumulated duration in the current logging
        interval (i.e. for the last "granularity" calls).
 
-     * Last min is the minimum duration between start/log_timer
-       calls during the last interval.
+     * Last min is the minimum duration between start/log_timer calls
+       during the last interval.
 
      * Last max - maximum duration.
 
-     * Last average is the average duration between
-       bm_start_timer() and bm_log_timer() since the last logging.
+     * Last average is the average duration between bm_start_timer() and
+       bm_log_timer() since the last logging.
 
      * Global msgs number of calls to log_timer.
 
@@ -203,43 +241,49 @@ bm_start_timer("test");
 bm_log_timer("test");
 ...
 
-1.5. Exported pseudo-variables
+5. Exported pseudo-variables
+
+   5.1. $BM_time_diff
 
    Exported pseudo-variables are listed in the next sections.
 
-1.5.1. $BM_time_diff
+5.1. $BM_time_diff
 
    $BM_time_diff - the time difference elapsed between calls of
-   bm_start_timer(name) and bm_log_timer(name). The value is 0 if
-   no bm_log_timer() was called.
+   bm_start_timer(name) and bm_log_timer(name). The value is 0 if no
+   bm_log_timer() was called.
+
+6. Exported MI Functions
 
-1.6. Exported MI Functions
+   6.1. bm_enable_global
+   6.2. bm_enable_timer
+   6.3. bm_granularity
+   6.4. bm_loglevel
 
-1.6.1. bm_enable_global
+6.1. bm_enable_global
 
    Enables/disables the module. Parameter may be -1, 0 or 1. See
    discription of "enable" parameter.
 
-1.6.2. bm_enable_timer
+6.2. bm_enable_timer
 
-   Enable or disable a single timer. The following example enables
-   timer "test" (the second parameter must be 0 to disable):
+   Enable or disable a single timer. The following example enables timer
+   "test" (the second parameter must be 0 to disable):
 
    Example 1.6. Enabling a timer
 ...
 kamctl fifo bm_enable_timer test 1
 ...
 
-1.6.3. bm_granularity
+6.3. bm_granularity
 
-   Modifies the benchmarking granularity. See "granularity"
-   variable.
+   Modifies the benchmarking granularity. See "granularity" variable.
 
-1.6.4. bm_loglevel
+6.4. bm_loglevel
 
    Modifies the module log level. See "loglevel" variable.
 
-1.7. Example of usage
+7. Example of usage
 
    Measure the duration of user location lookup.
 
@@ -252,36 +296,48 @@ bm_log_timer("usrloc-lookup");
 
 Chapter 2. Developer Guide
 
-   The benchmark module provides an internal API to be used by
-   other Kamailio modules. The available functions are identical
-   to the user exported functions.
+   Table of Contents
+
+   1. Available Functions
+
+        1.1. bm_register(name, mode, id)
+        1.2. bm_start(id)
+        1.3. bm_log(id)
+
+   2. Benchmark API Example
+
+   The benchmark module provides an internal API to be used by other
+   Kamailio modules. The available functions are identical to the user
+   exported functions.
+
+   Please note that this module is intended mainly for developers. It
+   should be used with caution in production environments.
 
-   Please note that this module is intended mainly for developers.
-   It should be used with caution in production environments.
+1. Available Functions
 
-2.1. Available Functions
+   1.1. bm_register(name, mode, id)
+   1.2. bm_start(id)
+   1.3. bm_log(id)
 
-2.1.1.  bm_register(name, mode, id)
+1.1. bm_register(name, mode, id)
 
-   This function register a new timer and/or returns the internal
-   ID associated with the timer. mode controls the creation of new
-   timer if not found. id is to be used by start and log timer
-   functions.
+   This function register a new timer and/or returns the internal ID
+   associated with the timer. mode controls the creation of new timer if
+   not found. id is to be used by start and log timer functions.
 
-2.1.2.  bm_start(id)
+1.2. bm_start(id)
 
-   This function equals the user-exported function bm_start_timer.
-   The id is passed as an integer, though.
+   This function equals the user-exported function bm_start_timer. The id
+   is passed as an integer, though.
 
-2.1.3.  bm_log(id)
+1.3. bm_log(id)
 
-   This function equals the user-exported function bm_log_timer.
-   The id is passed as an integer, though.
+   This function equals the user-exported function bm_log_timer. The id is
+   passed as an integer, though.
 
-2.2. Benchmark API Example
+2. Benchmark API Example
 
-   Example 2.1. Using the benchmark module's API from another
-   module
+   Example 2.1. Using the benchmark module's API from another module
 ...
 #include "../benchmark/benchmark.h"
 ...

modules_k/benchmark/doc/benchmark_admin.xml

@@ -18,7 +18,7 @@
 	<title>Overview</title>
 	<para>
 		This module helps developers to benchmark their module functions. By adding
-		this module's functions via the configuration file or through its API, Kamailio
+		this module's functions via the configuration file or through its API, &kamailio;
 		can log profiling information for every function.
 	</para>
 	<para>

modules_k/cfgutils/README

@@ -24,58 +24,57 @@ Daniel-Constantin Mierla
 
    <[email protected]>
 
-   Copyright © 2007, 2008, 2004 1und1 Internet AG, BASIS AudioNet
-   GmbH, Elena-Ramona Modroiu, FhG FOKUS
+   Copyright © 2007, 2008, 2004 1und1 Internet AG, BASIS AudioNet GmbH,
+   Elena-Ramona Modroiu, FhG FOKUS
    Revision History
-   Revision $Revision: 4843 $ $Date: 2008-09-04 18:02:09 +0300
-                              (Thu, 04 Sep 2008) $
-     __________________________________________________________
+   Revision $Revision$ $Date$
+     __________________________________________________________________
 
    Table of Contents
 
    1. Admin Guide
 
-        1.1. Overview
-        1.2. Dependencies
-        1.3. Exported Parameters
-
-              1.3.1. initial_probability (string)
-              1.3.2. hash_file (string)
-              1.3.3. initial_gflags (integer)
-              1.3.4. lock_set_size (integer)
-
-        1.4. Exported Functions
-
-              1.4.1. rand_event()
-              1.4.2. rand_set_prob(probabiltiy)
-              1.4.3. rand_reset_prob()
-              1.4.4. rand_get_prob()
-              1.4.5. sleep(time)
-              1.4.6. usleep(time)
-              1.4.7. abort()
-              1.4.8. pkg_status()
-              1.4.9. shm_status()
-              1.4.10. set_gflag(flag)
-              1.4.11. reset_gflag(flag)
-              1.4.12. is_gflag(flag)
-              1.4.13. lock(key)
-              1.4.14. unlock(key)
-
-        1.5. MI Commands
-
-              1.5.1. rand_set_prop
-              1.5.2. rand_reset_prob
-              1.5.3. rand_get_prob
-              1.5.4. check_config_hash
-              1.5.5. get_config_hash
-              1.5.6. set_gflag
-              1.5.7. reset_gflag
-              1.5.8. is_gflag
-              1.5.9. get_gflags
-
-        1.6. Exported pseudo-variables
-
-              1.6.1. $RANDOM
+        1. Overview
+        2. Dependencies
+        3. Exported Parameters
+
+              3.1. initial_probability (string)
+              3.2. hash_file (string)
+              3.3. initial_gflags (integer)
+              3.4. lock_set_size (integer)
+
+        4. Exported Functions
+
+              4.1. rand_event()
+              4.2. rand_set_prob(probabiltiy)
+              4.3. rand_reset_prob()
+              4.4. rand_get_prob()
+              4.5. sleep(time)
+              4.6. usleep(time)
+              4.7. abort()
+              4.8. pkg_status()
+              4.9. shm_status()
+              4.10. set_gflag(flag)
+              4.11. reset_gflag(flag)
+              4.12. is_gflag(flag)
+              4.13. lock(key)
+              4.14. unlock(key)
+
+        5. MI Commands
+
+              5.1. rand_set_prop
+              5.2. rand_reset_prob
+              5.3. rand_get_prob
+              5.4. check_config_hash
+              5.5. get_config_hash
+              5.6. set_gflag
+              5.7. reset_gflag
+              5.8. is_gflag
+              5.9. get_gflags
+
+        6. Exported pseudo-variables
+
+              6.1. $RANDOM
 
    List of Examples
 
@@ -110,93 +109,135 @@ Daniel-Constantin Mierla
 
 Chapter 1. Admin Guide
 
-1.1. Overview
+   Table of Contents
+
+   1. Overview
+   2. Dependencies
+   3. Exported Parameters
+
+        3.1. initial_probability (string)
+        3.2. hash_file (string)
+        3.3. initial_gflags (integer)
+        3.4. lock_set_size (integer)
+
+   4. Exported Functions
+
+        4.1. rand_event()
+        4.2. rand_set_prob(probabiltiy)
+        4.3. rand_reset_prob()
+        4.4. rand_get_prob()
+        4.5. sleep(time)
+        4.6. usleep(time)
+        4.7. abort()
+        4.8. pkg_status()
+        4.9. shm_status()
+        4.10. set_gflag(flag)
+        4.11. reset_gflag(flag)
+        4.12. is_gflag(flag)
+        4.13. lock(key)
+        4.14. unlock(key)
+
+   5. MI Commands
+
+        5.1. rand_set_prop
+        5.2. rand_reset_prob
+        5.3. rand_get_prob
+        5.4. check_config_hash
+        5.5. get_config_hash
+        5.6. set_gflag
+        5.7. reset_gflag
+        5.8. is_gflag
+        5.9. get_gflags
+
+   6. Exported pseudo-variables
+
+        6.1. $RANDOM
+
+1. Overview
 
    Useful extensions for the server configuration.
 
    The cfgutils module can be used to introduce randomness to the
    behaviour of the server. It provides setup functions and the
-   "rand_event" function. This function return either true or
-   false, depending on a random value and a specified probability.
-   E.g. if you set via fifo or script a probability value of 5%,
-   then 5% of all calls to rand_event will return true. The
-   pseudovariable "$RANDOM" could be used to introduce random
-   values e.g. into a SIP reply.
-
-   The benefit of this module is the probability of the decision
-   can be manipulated by external applications such as web
-   interface or command line tools. The probability must be
-   specified as percent value, ranging from 0 to 100.
-
-   The module exports commands to FIFO server that can be used to
-   change the global settings via FIFO interface. The FIFO
-   commands are: "set_prob", "reset_prob" and "get_prob".
-
-   This module can be used for simple load-shedding, e.g. reply 5%
-   of the Invites with a 503 error and a adequate random
-   Retry-After value.
-
-   The module provides as well functions to delay the execution of
-   the server. The functions "sleep" and "usleep" could be used to
-   let the server wait a specific time interval.
-
-   It can also hash the config file used from the server with a
-   (weak) cryptographic hash function on startup. This value is
-   saved and can be later compared to the actual hash, to detect
-   modifications of this file after the server start. This
-   functions are available as the FIFO commands
-   "check_config_hash" and "get_config_hash".
-
-   The gflags functionality (global flags) keeps a bitmap of flags
-   in shared memory and may be used to change behaviour of server
-   based on value of the flags. Example:
+   "rand_event" function. This function return either true or false,
+   depending on a random value and a specified probability. E.g. if you
+   set via fifo or script a probability value of 5%, then 5% of all calls
+   to rand_event will return true. The pseudovariable "$RANDOM" could be
+   used to introduce random values e.g. into a SIP reply.
+
+   The benefit of this module is the probability of the decision can be
+   manipulated by external applications such as web interface or command
+   line tools. The probability must be specified as percent value, ranging
+   from 0 to 100.
+
+   The module exports commands to FIFO server that can be used to change
+   the global settings via FIFO interface. The FIFO commands are:
+   "set_prob", "reset_prob" and "get_prob".
+
+   This module can be used for simple load-shedding, e.g. reply 5% of the
+   Invites with a 503 error and a adequate random Retry-After value.
+
+   The module provides as well functions to delay the execution of the
+   server. The functions "sleep" and "usleep" could be used to let the
+   server wait a specific time interval.
+
+   It can also hash the config file used from the server with a (weak)
+   cryptographic hash function on startup. This value is saved and can be
+   later compared to the actual hash, to detect modifications of this file
+   after the server start. This functions are available as the FIFO
+   commands "check_config_hash" and "get_config_hash".
+
+   The gflags functionality (global flags) keeps a bitmap of flags in
+   shared memory and may be used to change behaviour of server based on
+   value of the flags. Example:
         if (is_gflag("1")) {
                 t_relay("udp:10.0.0.1:5060");
         } else {
                 t_relay("udp:10.0.0.2:5060");
         }
 
-   The benefit of this is the value of the switch flags can be
-   manipulated by external applications such as web interface or
-   command line tools. The size of bitmap is 32.
+   The benefit of this is the value of the switch flags can be manipulated
+   by external applications such as web interface or command line tools.
+   The size of bitmap is 32.
 
-   The module exports external commands that can be used to change
-   the global flags via Management Interface. The MI commands are:
+   The module exports external commands that can be used to change the
+   global flags via Management Interface. The MI commands are:
    "set_gflag", "reset_gflag" and "is_gflag".
 
-1.2. Dependencies
+2. Dependencies
 
-   The module depends on the following modules (in the other words
-   the listed modules must be loaded before this module):
+   The module depends on the following modules (in the other words the
+   listed modules must be loaded before this module):
      * none
 
-1.3. Exported Parameters
+3. Exported Parameters
+
+   3.1. initial_probability (string)
+   3.2. hash_file (string)
+   3.3. initial_gflags (integer)
+   3.4. lock_set_size (integer)
 
-1.3.1. initial_probability (string)
+3.1. initial_probability (string)
 
    The initial value of the probability.
 
    Default value is "10".
 
    Example 1.1. initial_probability parameter usage
-
 modparam("cfgutils", "initial_probability", 15)
 
+3.2. hash_file (string)
 
-1.3.2. hash_file (string)
-
-   The config file name for that a hash value should be calculated
-   on startup.
+   The config file name for that a hash value should be calculated on
+   startup.
 
    There is no default value, is no parameter is given the hash
    functionality is disabled.
 
    Example 1.2. hash_file parameter usage
-
 modparam("cfgutils", "hash_file", "/etc/kamailio/kamailio.cfg")
 
-
-1.3.3. initial_gflags (integer)
+3.3. initial_gflags (integer)
 
    The initial value of global flags bitmap.
 
@@ -205,22 +246,37 @@ modparam("cfgutils", "hash_file", "/etc/kamailio/kamailio.cfg")
    Example 1.3. initial parameter usage
 modparam("cfgutils", "initial_gflags", 15)
 
-1.3.4. lock_set_size (integer)
+3.4. lock_set_size (integer)
 
-   Size of lock set - the value is used as power of two to compute
-   the size of lock array.
+   Size of lock set - the value is used as power of two to compute the
+   size of lock array.
 
    Default value is "0" - no lock set created.
 
    Example 1.4. lock_set_size parameter usage
 modparam("cfgutils", "lock_set_size", 4)
 
-1.4. Exported Functions
+4. Exported Functions
+
+   4.1. rand_event()
+   4.2. rand_set_prob(probabiltiy)
+   4.3. rand_reset_prob()
+   4.4. rand_get_prob()
+   4.5. sleep(time)
+   4.6. usleep(time)
+   4.7. abort()
+   4.8. pkg_status()
+   4.9. shm_status()
+   4.10. set_gflag(flag)
+   4.11. reset_gflag(flag)
+   4.12. is_gflag(flag)
+   4.13. lock(key)
+   4.14. unlock(key)
 
-1.4.1. rand_event()
+4.1. rand_event()
 
-   Return true or false, depending on a random value and a
-   probability value.
+   Return true or false, depending on a random value and a probability
+   value.
 
    Example 1.5. rand_event() usage
 ...
@@ -232,7 +288,7 @@ if (rand_event()) {
 # normal message processing follows
 ...
 
-1.4.2. rand_set_prob(probabiltiy)
+4.2. rand_set_prob(probabiltiy)
 
    Set the "probability" of the decision.
 
@@ -243,7 +299,7 @@ if (rand_event()) {
 rand_set_prob("4");
 ...
 
-1.4.3. rand_reset_prob()
+4.3. rand_reset_prob()
 
    Reset the probability back to the inital value.
 
@@ -252,17 +308,15 @@ rand_set_prob("4");
 rand_reset_prob();
 ...
 
-1.4.4. rand_get_prob()
+4.4. rand_get_prob()
 
-   Return the current probability setting, e.g. for logging
-   purposes.
+   Return the current probability setting, e.g. for logging purposes.
 
    Example 1.8. rand_get_prob() usage
 ...
 rand_get_prob();
 
-
-1.4.5.  sleep(time)
+4.5. sleep(time)
 
    Waits "time" seconds.
 
@@ -277,7 +331,7 @@ rand_get_prob();
 sleep("1");
 ...
 
-1.4.6.  usleep(time)
+4.6. usleep(time)
 
    Waits "time" milli-seconds.
 
@@ -292,7 +346,7 @@ sleep("1");
 usleep("500");
 ...
 
-1.4.7.  abort()
+4.7. abort()
 
    Debugging function that aborts the server. Depending on the
    configuration of the server a core dump will be created.
@@ -305,13 +359,12 @@ usleep("500");
 abort();
 ...
 
-1.4.8.  pkg_status()
+4.8. pkg_status()
 
-   Debugging function that dumps the status for the private (PKG)
-   memory. This information is logged to the default log facility,
-   depending on the general log level and the memlog setting. You
-   need to compile the server with activated memory debugging to
-   get detailed informations.
+   Debugging function that dumps the status for the private (PKG) memory.
+   This information is logged to the default log facility, depending on
+   the general log level and the memlog setting. You need to compile the
+   server with activated memory debugging to get detailed informations.
 
    This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE,
    FAILURE_ROUTE, BRANCH_ROUTE.
@@ -321,13 +374,12 @@ abort();
 pkg_status();
 ...
 
-1.4.9.  shm_status()
+4.9. shm_status()
 
-   Debugging function that dumps the status for the shared (SHM)
-   memory. This information is logged to the default log facility,
-   depending on the general log level and the memlog setting. You
-   need to compile the server with activated memory debugging to
-   get detailed informations.
+   Debugging function that dumps the status for the shared (SHM) memory.
+   This information is logged to the default log facility, depending on
+   the general log level and the memlog setting. You need to compile the
+   server with activated memory debugging to get detailed informations.
 
    This function can be used from REQUEST_ROUTE, ONREPLY_ROUTE,
    FAILURE_ROUTE, BRANCH_ROUTE.
@@ -337,7 +389,7 @@ pkg_status();
 shm_status();
 ...
 
-1.4.10. set_gflag(flag)
+4.10. set_gflag(flag)
 
    Set the bit at the position "flag" in global flags.
 
@@ -351,7 +403,7 @@ shm_status();
 set_gflag("4");
 ...
 
-1.4.11. reset_gflag(flag)
+4.11. reset_gflag(flag)
 
    Reset the bit at the position "flag" in global flags.
 
@@ -365,7 +417,7 @@ set_gflag("4");
 reset_gflag("4");
 ...
 
-1.4.12. is_gflag(flag)
+4.12. is_gflag(flag)
 
    Check if bit at the position "flag" in global flags is set.
 
@@ -384,13 +436,13 @@ if(is_gflag("4"))
 };
 ...
 
-1.4.13. lock(key)
+4.13. lock(key)
 
-   Lock the key. Can be used to syncronize operations in config
-   file, a hash id is computed over the key and appropriate lock
-   is set in the lock array controlled by parameter
-   "lock_set_size". Do not use lock() after another lock() unless
-   you are sure the keys hit different array entries.
+   Lock the key. Can be used to syncronize operations in config file, a
+   hash id is computed over the key and appropriate lock is set in the
+   lock array controlled by parameter "lock_set_size". Do not use lock()
+   after another lock() unless you are sure the keys hit different array
+   entries.
 
    "key" can be static string or string with PVs.
 
@@ -402,7 +454,7 @@ if(is_gflag("4"))
 lock("$rU");
 ...
 
-1.4.14. unlock(key)
+4.14. unlock(key)
 
    Unlock the key.
 
@@ -416,18 +468,27 @@ lock("$rU");
 unlock("$rU");
 ...
 
-1.5. MI Commands
+5. MI Commands
 
-   Functions that check or change some global flags accepts one
-   parameter which is the flag bitmap/mask specifing the
-   corresponding flags. It is not possible to specify directly the
-   flag position that should be changed as in the functions
-   available in the routing script.
+   5.1. rand_set_prop
+   5.2. rand_reset_prob
+   5.3. rand_get_prob
+   5.4. check_config_hash
+   5.5. get_config_hash
+   5.6. set_gflag
+   5.7. reset_gflag
+   5.8. is_gflag
+   5.9. get_gflags
 
-1.5.1. rand_set_prop
+   Functions that check or change some global flags accepts one parameter
+   which is the flag bitmap/mask specifing the corresponding flags. It is
+   not possible to specify directly the flag position that should be
+   changed as in the functions available in the routing script.
 
-   Set the probability value to the given parameter. The parameter
-   should be a percent value.
+5.1. rand_set_prop
+
+   Set the probability value to the given parameter. The parameter should
+   be a percent value.
 
    The parameter value must be a number from 0 to 100.
 
@@ -436,18 +497,18 @@ unlock("$rU");
 $ kamctl fifo rand_set_prob 10
 ...
 
-1.5.2. rand_reset_prob
+5.2. rand_reset_prob
 
    Reset the probability value to the inital start value.
 
    This command don't need a parameter.
 
-   Example 1.20.  rand_reset_prob usage
+   Example 1.20. rand_reset_prob usage
 ...
 $ kamctl fifo rand_reset_prob
 ...
 
-1.5.3. rand_get_prob
+5.3. rand_get_prob
 
    Return the actual probability setting.
 
@@ -459,15 +520,13 @@ $ kamctl fifo get_prob
 The actual probability is 50 percent.
 ...
 
-1.5.4. check_config_hash
+5.4. check_config_hash
 
-   Check if the actual config file hash is identical to the stored
-   one.
+   Check if the actual config file hash is identical to the stored one.
 
-   The function returns 200 OK if the hash values are identical,
-   400 if there are not identical, 404 if no file for hashing has
-   been configured and 500 on errors. Additional a short text
-   message is printed.
+   The function returns 200 OK if the hash values are identical, 400 if
+   there are not identical, 404 if no file for hashing has been configured
+   and 500 on errors. Additional a short text message is printed.
 
    Example 1.22. check_config_hash usage
 ...
@@ -475,12 +534,12 @@ $ kamctl fifo check_config_hash
 The actual config file hash is identical to the stored one.
 ...
 
-1.5.5. get_config_hash
+5.5. get_config_hash
 
    Return the stored config file hash.
 
-   The function returns 200 OK and the hash value on success or
-   404 if no file for hashing has been configured.
+   The function returns 200 OK and the hash value on success or 404 if no
+   file for hashing has been configured.
 
    Example 1.23. get_config_hash usage
 ...
@@ -488,12 +547,12 @@ $ kamctl fifo get_config_hash
 1580a37104eb4de69ab9f31ce8d6e3e0
 ...
 
-1.5.6. set_gflag
+5.6. set_gflag
 
    Set the value of some flags (specified by bitmask) to 1.
 
-   The parameter value must be a bitmask in decimal or hexadecimal
-   format. The bitmask has a 32 bit size.
+   The parameter value must be a bitmask in decimal or hexadecimal format.
+   The bitmask has a 32 bit size.
 
    Example 1.24. set_gflag usage
 ...
@@ -501,28 +560,28 @@ $ kamctl fifo set_gflag 1
 $ kamctl fifo set_gflag 0x3
 ...
 
-1.5.7. reset_gflag
+5.7. reset_gflag
 
    Reset the value of some flags to 0.
 
-   The parameter value must be a bitmask in decimal or hexadecimal
-   format. The bitmask has a 32 bit size.
+   The parameter value must be a bitmask in decimal or hexadecimal format.
+   The bitmask has a 32 bit size.
 
-   Example 1.25.  reset_gflag usage
+   Example 1.25. reset_gflag usage
 ...
 $ kamctl fifo reset_gflag 1
 $ kamctl fifo reset_gflag 0x3
 ...
 
-1.5.8. is_gflag
+5.8. is_gflag
 
    Returns true if the all the flags from the bitmask are set.
 
-   The parameter value must be a bitmask in decimal or hexadecimal
-   format. The bitmask has a 32 bit size.
+   The parameter value must be a bitmask in decimal or hexadecimal format.
+   The bitmask has a 32 bit size.
 
-   The function returns TRUE if all the flags from the set are set
-   and FALSE if at least one is not set.
+   The function returns TRUE if all the flags from the set are set and
+   FALSE if at least one is not set.
 
    Example 1.26. is_gflag usage
 ...
@@ -542,22 +601,23 @@ $ kamctl fifo is_gflag 16
 TRUE
 ...
 
-1.5.9. get_gflags
+5.9. get_gflags
 
-   Return the bitmap with all flags. The function gets no
-   parameters and returns the bitmap in hexadecimal and decimal
-   format.
+   Return the bitmap with all flags. The function gets no parameters and
+   returns the bitmap in hexadecimal and decimal format.
 
-   Example 1.27.  get_gflags usage
+   Example 1.27. get_gflags usage
 ...
 $ kamctl fifo get_gflags
 0x3039
 12345
 ...
 
-1.6. Exported pseudo-variables
+6. Exported pseudo-variables
+
+   6.1. $RANDOM
 
-1.6.1. $RANDOM
+6.1. $RANDOM
 
    Returns a random value from the [0 - 2^31) range.
 

modules_k/db_oracle/doc/db_oracle_admin.xml

@@ -16,8 +16,8 @@
 	<section>
 	<title>Overview</title>
 	<para>
-		This is a module which provides Oracle connectivity for Kamailio.
-		It implements the DB API defined in Kamailio. If you want to use
+		This is a module which provides Oracle connectivity for &kamailio;.
+		It implements the DB API defined in &kamailio;. If you want to use
 		the nathelper module, or any other modules that calls the
 		get_all_ucontacts API export from usrloc, then you need to set
 		the <emphasis>DORACLE_USRLOC</emphasis> define in the Makefile.defs
@@ -152,7 +152,7 @@ modparam("db_oracle", "reconnect", 0.5)
 		described in the db scheme). This problem has been solved by inclusion the 
 		utility openser_orasel, which formats printing approximately in the same 
 		way as the 'mysql' client utility. In addition, this utility known about 
-		the "agreements and types" in DB that are used in Kamailio for the work 
+		the "agreements and types" in DB that are used in &kamailio; for the work 
 		with Oracle and formats printing taking these into account.
 		</para>
 	</section>

modules_k/h350/doc/h350_admin.xml

@@ -14,7 +14,7 @@
         <title>Overview</title>
 
         <para>
-			The Kamailio H350 module enables an Kamailio SIP proxy server to access SIP account data stored in an LDAP <xref linkend="RFC4510"/> directory containing H.350 <xref linkend="H350"/> <emphasis>commObjects</emphasis>. ITU-T Recommendation H.350 standardizes LDAP object classes to store Real-Time Communication (RTC) account data. In particular, <emphasis>H.350.4</emphasis> <xref linkend="H350-4"/> defines an object class called <emphasis>sipIdentity</emphasis> that includes attribute specifications for SIP account data like SIP URI, SIP digest username/password, or service level. This allows to store SIP account data in a vendor neutral way and lets different entities, like SIP proxies, provisioning, or billing applications, access the data in a standardized format.  
+			The &kamailio; H350 module enables an &kamailio; SIP proxy server to access SIP account data stored in an LDAP <xref linkend="RFC4510"/> directory containing H.350 <xref linkend="H350"/> <emphasis>commObjects</emphasis>. ITU-T Recommendation H.350 standardizes LDAP object classes to store Real-Time Communication (RTC) account data. In particular, <emphasis>H.350.4</emphasis> <xref linkend="H350-4"/> defines an object class called <emphasis>sipIdentity</emphasis> that includes attribute specifications for SIP account data like SIP URI, SIP digest username/password, or service level. This allows to store SIP account data in a vendor neutral way and lets different entities, like SIP proxies, provisioning, or billing applications, access the data in a standardized format.  
         </para>
         
         <para>
@@ -22,7 +22,7 @@
         </para>
         
         <para>
-            The H350 module uses the Kamailio LDAP module to import H.350 attribute values into the Kamailio routing script variable space. The module exports functions to parse and store the H.350 attribute values from the Kamailio routing script. It allows a script writer to implement H.350 based SIP digest authentication, call forwarding, SIP URI alias to AOR rewriting, and service level parsing. 
+            The H350 module uses the &kamailio; LDAP module to import H.350 attribute values into the &kamailio; routing script variable space. The module exports functions to parse and store the H.350 attribute values from the &kamailio; routing script. It allows a script writer to implement H.350 based SIP digest authentication, call forwarding, SIP URI alias to AOR rewriting, and service level parsing. 
         </para>
 
     <section>
@@ -90,7 +90,7 @@ objectClass                   top
       <title>Dependencies</title>
 
       <section>
-        <title>Kamailio Modules</title>
+        <title>&kamailio; Modules</title>
 
         <para>The module depends on the following modules (the listed modules
         must be loaded before this module):</para>
@@ -106,7 +106,7 @@ objectClass                   top
         <title>External Libraries or Applications</title>
 
         <para>The following libraries or applications must be installed before
-        running Kamailio with this module loaded:</para>
+        running &kamailio; with this module loaded:</para>
 
         <itemizedlist>
           <listitem>
@@ -188,7 +188,7 @@ modparam("h350", "search_scope", "sub");
         <title>h350_sipuri_lookup(sip_uri)</title>
         
         <para>
-            This function performs an LDAP search query for an H.350 commObject with a SIPIdentitySIPURI of <varname>sip_uri</varname>. The <varname>sip_uri</varname> parameter first gets escaped according the rules for LDAP filter strings. The result of the LDAP search is stored internally and can be accessed either by one of the <emphasis>h350_result*</emphasis> or one of the <emphasis>ldap_result*</emphasis> functions from the Kamailio LDAP module.
+            This function performs an LDAP search query for an H.350 commObject with a SIPIdentitySIPURI of <varname>sip_uri</varname>. The <varname>sip_uri</varname> parameter first gets escaped according the rules for LDAP filter strings. The result of the LDAP search is stored internally and can be accessed either by one of the <emphasis>h350_result*</emphasis> or one of the <emphasis>ldap_result*</emphasis> functions from the &kamailio; LDAP module.
         </para>
         
         <para>
@@ -207,7 +207,7 @@ modparam("h350", "search_scope", "sub");
 
                 <listitem>
                     <para>
-                        H.350 SIPIdentitySIPURI to search for in directory. Included Kamailio variables do get expanded.
+                        H.350 SIPIdentitySIPURI to search for in directory. Included &kamailio; variables do get expanded.
                     </para>
                 </listitem>
             </varlistentry>
@@ -314,7 +314,7 @@ if (!h350_sipuri_lookup("sip:$rU@$rd"))
 
                 <listitem>
                     <para>
-                        H.350 SIPIdentityUserName to search for in directory. Included Kamailio variables do get expanded.
+                        H.350 SIPIdentityUserName to search for in directory. Included &kamailio; variables do get expanded.
                     </para>
                 </listitem>
             </varlistentry>
@@ -558,7 +558,7 @@ AVP value = argument / 1000
         </para>
         
         <para>
-            These AVPs can then be used to implement the desired behavior in the Kamailio routing script.
+            These AVPs can then be used to implement the desired behavior in the &kamailio; routing script.
         </para>
         
         <para>
@@ -688,7 +688,7 @@ if (is_avp_set("$avp(s:callee_pref_u)"))
         <title>h350_result_service_level(avp_name_prefix)</title>
         
         <para>
-			<emphasis>Directory services architecture for SIP</emphasis> <xref linkend="H350-4"/> defines a multi-valued LDAP attribute named SIPIdentityServiceLevel, which can be used to store SIP account service level values in an LDAP directory. This function parses the SIPIdentityServiceLevel attribute and stores all service level values as AVPs for later retrieval in the Kamailio routing script. The function accesses the H.350 commObject fetched by a call to <emphasis>h350_*_lookup</emphasis> or <emphasis>ldap_search</emphasis>. 
+			<emphasis>Directory services architecture for SIP</emphasis> <xref linkend="H350-4"/> defines a multi-valued LDAP attribute named SIPIdentityServiceLevel, which can be used to store SIP account service level values in an LDAP directory. This function parses the SIPIdentityServiceLevel attribute and stores all service level values as AVPs for later retrieval in the &kamailio; routing script. The function accesses the H.350 commObject fetched by a call to <emphasis>h350_*_lookup</emphasis> or <emphasis>ldap_search</emphasis>. 
         </para>
         
         <para>

modules_k/imc/doc/imc_admin.xml

@@ -171,8 +171,8 @@ modparam("imc", "imc_cmd_start_char", "#")
 		<title><varname>outbound_proxy</varname> (str)</title>
 		<para>
 	   The SIP address used as next hop when sending the message. Very
-   useful when using Kamailio with a domain name not in DNS, or
-   when using a separate Kamailio instance for imc processing. If
+   useful when using &kamailio; with a domain name not in DNS, or
+   when using a separate &kamailio; instance for imc processing. If
    not set, the message will be sent to the address in destination
    URI.
 		</para>

modules_k/kex/README

@@ -252,7 +252,7 @@ km_append_branch("sip:[email protected]");
    4.5. version
    4.6. which
 
-4.1.  arg
+4.1. arg
 
    Print command line arguments.
 
@@ -264,7 +264,7 @@ km_append_branch("sip:[email protected]");
                 :arg:_reply_fifo_file_
                 _empty_line_
 
-4.2.  kill
+4.2. kill
 
    Kill the application.
 
@@ -276,7 +276,7 @@ km_append_branch("sip:[email protected]");
                 :kill:_reply_fifo_file_
                 _empty_line_
 
-4.3.  pwd
+4.3. pwd
 
    Print working directory.
 
@@ -288,7 +288,7 @@ km_append_branch("sip:[email protected]");
                 :pwd:_reply_fifo_file_
                 _empty_line_
 
-4.4.  uptime
+4.4. uptime
 
    Print uptime.
 
@@ -300,7 +300,7 @@ km_append_branch("sip:[email protected]");
                 :uptime:_reply_fifo_file_
                 _empty_line_
 
-4.5.  version
+4.5. version
 
    Print version information.
 
@@ -312,7 +312,7 @@ km_append_branch("sip:[email protected]");
                 :version:_reply_fifo_file_
                 _empty_line_
 
-4.6.  which
+4.6. which
 
    Print list of available MI commands.
 

modules_k/kex/doc/kex_admin.xml

@@ -16,10 +16,10 @@
 	<section>
 	<title>Overview</title>
 	<para>
-	This module collects extensions from Kamailio core.
+	This module collects extensions from &kamailio; core.
 	</para>
 	<para>
-	Kamailio Core CookBook is available at:
+	&kamailio; Core CookBook is available at:
 	<ulink url="http://kamailio.org/dokuwiki/">
 	http://kamailio.org/dokuwiki/</ulink>
 	</para>

modules_k/ldap/doc/ldap_admin.xml

@@ -13,7 +13,7 @@
     <section>
       <title>Overview</title>
 
-      <para>The LDAP module implements an LDAP search interface for Kamailio. It exports script functions to perform an LDAP search operation and to store the search results as Kamailio AVPs. This allows for using LDAP directory data in the Kamailio SIP message routing script.</para>
+      <para>The LDAP module implements an LDAP search interface for &kamailio;. It exports script functions to perform an LDAP search operation and to store the search results as &kamailio; AVPs. This allows for using LDAP directory data in the &kamailio; SIP message routing script.</para>
       
       <para>The following features are offered by the LDAP module:</para>
       <itemizedlist>
@@ -36,21 +36,21 @@
             <para>Configurable LDAP connection and bind timeouts</para>
         </listitem>
 		<listitem>
-            <para>Module API for LDAP search operations that can be used by other Kamailio modules</para>
+            <para>Module API for LDAP search operations that can be used by other &kamailio; modules</para>
         </listitem>
       </itemizedlist> 
       
-      <para>The module implementation makes use of the open source OpenLDAP library available on most UNIX/Linux platforms. Besides LDAP server failover and automatic reconnect, this module can handle multiple LDAP sessions concurrently allowing to access data stored on different LDAP servers. Each Kamailio worker process maintains one LDAP TCP connection per configured LDAP server. This enables parallel execution of LDAP requests and offloads LDAP concurrency control to the LDAP server(s).</para>
+      <para>The module implementation makes use of the open source OpenLDAP library available on most UNIX/Linux platforms. Besides LDAP server failover and automatic reconnect, this module can handle multiple LDAP sessions concurrently allowing to access data stored on different LDAP servers. Each &kamailio; worker process maintains one LDAP TCP connection per configured LDAP server. This enables parallel execution of LDAP requests and offloads LDAP concurrency control to the LDAP server(s).</para>
       
-      <para>An LDAP search module API is provided that can be used by other Kamailio modules. A module using this API does not have to implement LDAP connection management and configuration, while still having access to the full OpenLDAP API for searching and result handling.</para> 
+      <para>An LDAP search module API is provided that can be used by other &kamailio; modules. A module using this API does not have to implement LDAP connection management and configuration, while still having access to the full OpenLDAP API for searching and result handling.</para> 
       
-      <para>Since LDAP server implementations are optimized for fast read access they are a good choice to store SIP provisioning data. Performance tests have shown that this module achieves lower data access times and higher call rates than other database modules like e.g. the Kamailio MYSQL module.</para>
+      <para>Since LDAP server implementations are optimized for fast read access they are a good choice to store SIP provisioning data. Performance tests have shown that this module achieves lower data access times and higher call rates than other database modules like e.g. the &kamailio; MYSQL module.</para>
 
       <section>
         <title>Usage Basics</title>
 
         <para>
-			First so called LDAP sessions have to be specified in an external configuration file (as described in <xref linkend="ldap-config" xreflabel="LDAP Configuration File"/>). Each LDAP session includes LDAP server access parameters like server hostname or connection timeouts. Normally only a single LDAP session will be used unless there is a need to access more than one LDAP server. The LDAP session name will then be used in the Kamailio configuration script to refer to a specific LDAP session.
+			First so called LDAP sessions have to be specified in an external configuration file (as described in <xref linkend="ldap-config" xreflabel="LDAP Configuration File"/>). Each LDAP session includes LDAP server access parameters like server hostname or connection timeouts. Normally only a single LDAP session will be used unless there is a need to access more than one LDAP server. The LDAP session name will then be used in the &kamailio; configuration script to refer to a specific LDAP session.
         </para>
 
         <para>
@@ -62,7 +62,7 @@
         </para>
         
         <para>
-        All <varname>ldap_result*</varname> functions do always access the LDAP result set from the last <varname>ldap_search</varname> call. This should be kept in mind when calling <varname>ldap_search</varname> more than once in the Kamailio configuration script.
+        All <varname>ldap_result*</varname> functions do always access the LDAP result set from the last <varname>ldap_search</varname> call. This should be kept in mind when calling <varname>ldap_search</varname> more than once in the &kamailio; configuration script.
         </para>
       </section>
 
@@ -183,14 +183,14 @@
       <title>Dependencies</title>
 
       <section>
-        <title>Kamailio Modules</title>
+        <title>&kamailio; Modules</title>
 
         <para>The module depends on the following modules (the listed modules
         must be loaded before this module):</para>
 
         <itemizedlist>
           <listitem>
-            <para><emphasis>No dependencies on other Kamailio modules.</emphasis></para>
+            <para><emphasis>No dependencies on other &kamailio; modules.</emphasis></para>
           </listitem>
         </itemizedlist>
       </section>
@@ -199,7 +199,7 @@
         <title>External Libraries or Applications</title>
 
         <para>The following libraries or applications must be installed before
-        running Kamailio with this module loaded:</para>
+        running &kamailio; with this module loaded:</para>
 
         <itemizedlist>
           <listitem>
@@ -230,7 +230,7 @@
         are treated as comments.</para>
 
         <para>Each section describes one LDAP session that can be referred to
-        in the Kamailio configuration script. Using the section name as the
+        in the &kamailio; configuration script. Using the section name as the
         host part of an LDAP URL tells the module to use the LDAP session
         specified in the respective section. An example LDAP session
         specification looks like:
@@ -435,7 +435,7 @@ modparam("ldap", "config_file", "/etc/kamailio/ldap.ini")
         <para>Performs an LDAP search operation using given LDAP URL and stores result
         internally for later retrieval by <varname>ldap_result*</varname> functions. If one ore
         more LDAP entries are found the function returns the number of found
-        entries which evaluates to TRUE in the Kamailio configuration script.
+        entries which evaluates to TRUE in the &kamailio; configuration script.
         It returns <varname>-1</varname> (<varname>FALSE</varname>) in case no
         LDAP entry was found, and <varname>-2</varname>
         (<varname>FALSE</varname>) if an internal error like e.g. an LDAP
@@ -453,7 +453,7 @@ modparam("ldap", "config_file", "/etc/kamailio/ldap.ini")
               format). The hostport part must be one of the LDAP session names
               declared in the LDAP configuration script.</para>
 
-              <para>Kamailio pseudo variables and AVPs included in
+              <para>&kamailio; pseudo variables and AVPs included in
               <varname>ldap_url</varname> do get substituted with their
               value.</para>
 

modules_k/ldap/doc/ldap_devel.xml

@@ -14,7 +14,7 @@
 	<section>
 		<title>Overview</title>
 		<para>
-			The LDAP module API can be used by other Kamailio modules to implement LDAP search functionality. This frees the module implementer from having to care about LDAP connection management and configuration. 
+			The LDAP module API can be used by other &kamailio; modules to implement LDAP search functionality. This frees the module implementer from having to care about LDAP connection management and configuration. 
 		</para>
 		<para>
 			In order to use this API, a module has to load the API using the <varname>load_ldap_api</varname> function which returns a pointer to a <varname>ldap_api</varname> structure. This structure includes pointers to the API functions described below. The LDAP module source file <varname>api.h</varname> includes all declarations needed to load the API, it has to be included in the file that loads the API. Loading the API is typically done inside a module's <varname>mod_init</varname> call as the following example shows:			
@@ -440,7 +440,7 @@ typedef int (*ldap_rfc4515_escape_t)(str *sin, str *sout, int url_encode);
 		<section>
 			<title>get_ldap_handle</title>
 			<para>
-				Returns the OpenLDAP LDAP handle for a specific LDAP session. This allows a module implementor to use the OpenLDAP API functions directly, instead of using the API functions exported by the Kamailio LDAP module. The <varname>LDAP</varname> structure is defined in OpenLDAP's <varname>ldap.h</varname>, which has to be included.
+				Returns the OpenLDAP LDAP handle for a specific LDAP session. This allows a module implementor to use the OpenLDAP API functions directly, instead of using the API functions exported by the &kamailio; LDAP module. The <varname>LDAP</varname> structure is defined in OpenLDAP's <varname>ldap.h</varname>, which has to be included.
 			</para>
 			<programlisting><![CDATA[
 typedef int (*get_ldap_handle_t)(char* _lds_name, LDAP** _ldap_handle);

modules_k/mi_datagram/README

@@ -1,4 +1,3 @@
-
 mi_datagram Module
 
 Andreea-Ancuta Onofrei
@@ -11,37 +10,33 @@ Andreea-Ancuta Onofrei
 
    Copyright © 2007 voice-system.ro
    Revision History
-   Revision $Revision: 1133 $ $Date: 2007-05-04 14:31:13 +0300
-   (Thu, 05 Apr 2006) $
-     _________________________________________________________
+   Revision $Revision: 1133 $ $Date: 2007-05-04 14:31:13 +0300 (Thu, 05
+   Apr 2006) $
+     __________________________________________________________________
 
    Table of Contents
 
    1. Admin Guide
 
-        1.1. Overview
-        1.2. DATAGRAM command syntax
-        1.3. Dependencies
-
-              1.3.1. Kamailio Modules
-              1.3.2. External Libraries or Applications
+        1. Overview
+        2. DATAGRAM command syntax
+        3. Dependencies
 
-        1.4. Exported Parameters
+              3.1. Kamailio Modules
+              3.2. External Libraries or Applications
 
-              1.4.1. socket_name (string)
-              1.4.2. children_count (string)
-              1.4.3. unix_socket_mode (integer)
-              1.4.4. unix_socket_group (integer)
-                      unix_socket_group (string)
+        4. Exported Parameters
 
-              1.4.5. unix_socket_user (integer) unix_socket_group
-                      (string)
+              4.1. socket_name (string)
+              4.2. children_count (string)
+              4.3. unix_socket_mode (integer)
+              4.4. unix_socket_group (integer) unix_socket_group (string)
+              4.5. unix_socket_user (integer) unix_socket_group (string)
+              4.6. socket_timeout (integer)
+              4.7. reply_indent (string)
 
-              1.4.6. socket_timeout (integer)
-              1.4.7. reply_indent (string)
-
-        1.5. Exported Functions
-        1.6. Example
+        5. Exported Functions
+        6. Example
 
    2. Frequently Asked Questions
 
@@ -58,44 +53,77 @@ Andreea-Ancuta Onofrei
 
 Chapter 1. Admin Guide
 
-1.1. Overview
+   Table of Contents
+
+   1. Overview
+   2. DATAGRAM command syntax
+   3. Dependencies
+
+        3.1. Kamailio Modules
+        3.2. External Libraries or Applications
+
+   4. Exported Parameters
 
-   This is a module which provides a UNIX/UDP SOCKET transport
-   layer implementation for the Management Interface.
+        4.1. socket_name (string)
+        4.2. children_count (string)
+        4.3. unix_socket_mode (integer)
+        4.4. unix_socket_group (integer) unix_socket_group (string)
+        4.5. unix_socket_user (integer) unix_socket_group (string)
+        4.6. socket_timeout (integer)
+        4.7. reply_indent (string)
 
-1.2. DATAGRAM command syntax
+   5. Exported Functions
+   6. Example
 
-   The external commands issued via DATAGRAM interface must
-   follow the following syntax:
-     * request = first_line (argument '\n')* 
-     * first_line = ':'command_name':''\n' 
-     * argument = (arg_name '::' (arg_value)? ) | (arg_value) 
-     * arg_name = not-quoted_string 
-     * arg_value = not-quoted_string | '"' string '"' 
-     * not-quoted_string = string - {',",\n,\r} 
+1. Overview
 
-1.3. Dependencies
+   This is a module which provides a UNIX/UDP SOCKET transport layer
+   implementation for the Management Interface.
 
-1.3.1. Kamailio Modules
+2. DATAGRAM command syntax
+
+   The external commands issued via DATAGRAM interface must follow the
+   following syntax:
+     * request = first_line (argument '\n')*
+     * first_line = ':'command_name':''\n'
+     * argument = (arg_name '::' (arg_value)? ) | (arg_value)
+     * arg_name = not-quoted_string
+     * arg_value = not-quoted_string | '"' string '"'
+     * not-quoted_string = string - {',",\n,\r}
+
+3. Dependencies
+
+   3.1. Kamailio Modules
+   3.2. External Libraries or Applications
+
+3.1. Kamailio Modules
 
    The following modules must be loaded before this module:
      * No dependencies on other Kamailio modules.
 
-1.3.2. External Libraries or Applications
+3.2. External Libraries or Applications
 
-   The following libraries or applications must be installed
-   before running Kamailio with this module loaded:
+   The following libraries or applications must be installed before
+   running Kamailio with this module loaded:
      * none
 
-1.4. Exported Parameters
+4. Exported Parameters
 
-1.4.1. socket_name (string)
+   4.1. socket_name (string)
+   4.2. children_count (string)
+   4.3. unix_socket_mode (integer)
+   4.4. unix_socket_group (integer) unix_socket_group (string)
+   4.5. unix_socket_user (integer) unix_socket_group (string)
+   4.6. socket_timeout (integer)
+   4.7. reply_indent (string)
 
-   The name of a UNIX SOCKET or an IP address. The UNIX datagram
-   or UDP socket will be created using this parameter in order to
-   read the external commands. Both IPv4 and IPv6 are supported.
+4.1. socket_name (string)
 
-   Default value is NONE. 
+   The name of a UNIX SOCKET or an IP address. The UNIX datagram or UDP
+   socket will be created using this parameter in order to read the
+   external commands. Both IPv4 and IPv6 are supported.
+
+   Default value is NONE.
 
    Example 1.1. Set socket_name parameter
 ...
@@ -104,36 +132,35 @@ modparam("mi_datagram", "socket_name", "/tmp/kamailio.sock")
 modparam("mi_datagram", "socket_name", "udp:192.168.2.133:8080")
 ...
 
-1.4.2. children_count (string)
+4.2. children_count (string)
 
-   The number of child processes to be created. Each child
-   process will be a datagram server.
+   The number of child processes to be created. Each child process will be
+   a datagram server.
 
-   Default value is 1. 
+   Default value is 1.
 
    Example 1.2. Set children_count parameter
 ...
 modparam("mi_datagram", "children_count", 3)
 ...
 
-1.4.3. unix_socket_mode (integer)
+4.3. unix_socket_mode (integer)
 
-   Permission to be used for creating the listening UNIX datagram
-   socket. Not necessary for a UDP socket. It follows the UNIX
-   conventions.
+   Permission to be used for creating the listening UNIX datagram socket.
+   Not necessary for a UDP socket. It follows the UNIX conventions.
 
-   Default value is 0660 (rw-rw----). 
+   Default value is 0660 (rw-rw----).
 
    Example 1.3. Set unix_socket_mode parameter
 ...
 modparam("mi_datagram", "unix_socket_mode", 0600)
 ...
 
-1.4.4. unix_socket_group (integer) unix_socket_group (string)
+4.4. unix_socket_group (integer) unix_socket_group (string)
 
    Group to be used for creating the listening UNIX socket.
 
-   Default value is the inherited one. 
+   Default value is the inherited one.
 
    Example 1.4. Set unix_socket_group parameter
 ...
@@ -141,11 +168,11 @@ modparam("mi_datagram", "unix_socket_group", 0)
 modparam("mi_datagram", "unix_socket_group", "root")
 ...
 
-1.4.5. unix_socket_user (integer) unix_socket_group (string)
+4.5. unix_socket_user (integer) unix_socket_group (string)
 
    User to be used for creating the listening UNIX socket.
 
-   Default value is the inherited one. 
+   Default value is the inherited one.
 
    Example 1.5. Set unix_socket_user parameter
 ...
@@ -153,61 +180,63 @@ modparam("mi_datagram", "unix_socket_user", 0)
 modparam("mi_datagram", "unix_socket_user", "root")
 ...
 
-1.4.6. socket_timeout (integer)
+4.6. socket_timeout (integer)
 
-   The reply will expire after trying to sent it for
-   socket_timeout miliseconds.
+   The reply will expire after trying to sent it for socket_timeout
+   miliseconds.
 
-   Default value is 2000. 
+   Default value is 2000.
 
    Example 1.6. Set socket_timeout parameter
 ...
 modparam("mi_datagram", "socket_timeout", 2000)
 ...
 
-1.4.7. reply_indent (string)
+4.7. reply_indent (string)
 
-   Strings to be used for line indentation. As the MI data
-   structure is tree oriendeted, the depth level will printed as
-   identation.
+   Strings to be used for line indentation. As the MI data structure is
+   tree oriendeted, the depth level will printed as identation.
 
-   Default value is ""\t" (TAB)". 
+   Default value is ""\t" (TAB)".
 
    Example 1.7. Set reply_ident parameter
 ...
 modparam("mi_datagram", "reply_ident", "    ")
 ...
 
-1.5. Exported Functions
+5. Exported Functions
 
    No function exported to be used from configuration file.
 
-1.6. Example
+6. Example
 
-   This is an example showing the DATAGRAM format for the
-   "get_statistics dialog: tm:" MI commad: response.
+   This is an example showing the DATAGRAM format for the "get_statistics
+   dialog: tm:" MI commad: response.
 
    Example 1.8. DATAGRAM request
-
 :get_statistics:\n
 dialog:\n
 tm:\n
 
 Chapter 2. Frequently Asked Questions
 
+   2.1. Both UNIX and UDP type of socket can be created simultaneusly?
+   2.2. Is there a limit in the datagram request's size?
+   2.3. Where can I find more about Kamailio?
+   2.4. Where can I post a question about this module?
+   2.5. How can I report a bug?
+
    2.1.
 
    Both UNIX and UDP type of socket can be created simultaneusly?
 
-   This version supports only one kind of socket at a time. If
-   there are more than one value set for socket_name the last one
-   will take effect.
+   This version supports only one kind of socket at a time. If there are
+   more than one value set for socket_name the last one will take effect.
    2.2.
 
    Is there a limit in the datagram request's size?
 
-   The maximum length of a datagram request or reply is 65457
-   bytes.
+   The maximum length of a datagram request or reply is 65457 bytes.
    2.3.
 
    Where can I find more about Kamailio?
@@ -217,17 +246,16 @@ Chapter 2. Frequently Asked Questions
 
    Where can I post a question about this module?
 
-   First at all check if your question was already answered on
-   one of our mailing lists:
+   First at all check if your question was already answered on one of our
+   mailing lists:
      * User Mailing List -
        http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
      * Developer Mailing List -
        http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
 
-   E-mails regarding any stable Kamailio release should be sent
-   to <[email protected]> and e-mails regarding
-   development versions should be sent to
-   <[email protected]>.
+   E-mails regarding any stable Kamailio release should be sent to
+   <[email protected]> and e-mails regarding development versions
+   should be sent to <[email protected]>.
 
    If you want to keep the mail private, send it to
    <[email protected]>.

modules_k/mi_datagram/doc/mi_datagram_faq.xml

@@ -38,7 +38,7 @@
 	</qandaentry>
 	<qandaentry>
 		<question>
-		<para>Where can I find more about Kamailio?</para>
+		<para>Where can I find more about &kamailio;?</para>
 		</question>
 		<answer>
 		<para>

modules_k/msilo/doc/msilo_admin.xml

@@ -265,8 +265,8 @@ modparam("msilo", "reminder", "sip:[email protected]")
 		<title><varname>outbound_proxy</varname> (string)</title>
 		<para>
 		The &sip; address used as next hop when sending the message. Very
-		useful when using Kamailio with a domain name not in DNS, or when
-		using a separate Kamailio instance for msilo processing. If not set,
+		useful when using &kamailio; with a domain name not in DNS, or when
+		using a separate &kamailio; instance for msilo processing. If not set,
 		the message will be sent to the address in destination URI.
 		</para>
 		<para>

modules_k/nat_traversal/doc/nat_traversal_admin.xml

@@ -457,7 +457,7 @@ modparam("nat_traversal", "keepalive_from", "sip:[email protected]")
       <title>Setting the <varname>keepalive_extra_headers</varname> parameter</title>
         <programlisting format="linespecific">
 ...
-modparam("nat_traversal", "keepalive_extra_headers", "User-Agent: Kamailio\r\nX-MyHeader: some_value\r\n")
+modparam("nat_traversal", "keepalive_extra_headers", "User-Agent: &kamailio;\r\nX-MyHeader: some_value\r\n")
 ...
         </programlisting>
       </example>

modules_k/osp/doc/osp_admin.xml

@@ -14,7 +14,7 @@
   <title>&adminguide;</title>
   <section>
     <title>Overview</title>
-    <para>The OSP module enables Kamailio to support secure, multi-lateral peering using the OSP standard defined by ETSI (TS 101 321 V4.1.1). This module will enable your Kamailio to:</para>
+    <para>The OSP module enables &kamailio; to support secure, multi-lateral peering using the OSP standard defined by ETSI (TS 101 321 V4.1.1). This module will enable your &kamailio; to:</para>
     <itemizedlist>
       <listitem>
         <para>Send a peering authorization request to a peering server.</para>
@@ -47,7 +47,7 @@
         <para><emphasis>auth</emphasis> -- Remote-Party-ID operattion</para>
       </listitem>
       <listitem>
-        <para><emphasis>OSP Toolkit</emphasis> -- The OSP Toolkit, available from http://sourceforge.net/projects/osp-toolkit, must be built before building Kamailio with the OSP Module.  For instructions on building Kamailio with the OSP Toolkit, see http://www.transnexus.com/White%20Papers/Multi-Lateral_Peering_with_Kamailio_V1.4.pdf</para>
+        <para><emphasis>OSP Toolkit</emphasis> -- The OSP Toolkit, available from http://sourceforge.net/projects/osp-toolkit, must be built before building &kamailio; with the OSP Module.  For instructions on building &kamailio; with the OSP Toolkit, see http://www.transnexus.com/White%20Papers/Multi-Lateral_Peering_with_Kamailio_V1.4.pdf</para>
       </listitem>
     </itemizedlist>
   </section>
@@ -58,13 +58,13 @@
       <para>These sp_uri (string) parameters define peering servers to be used for requesting peering authorization and routing information. At least one peering server must be configured. Others are required only if there are more than one peering servers. Each peering server address takes the form of a standard URL, and consists of up to four components:</para>
       <itemizedlist>
         <listitem>
-          <para>An optional indication of the protocol to be used for communicating with the peering server. Both HTTP and HTTP secured with SSL/TLS are supported and are indicated by "http://" and "https://" respectively. If the protocol is not explicitly indicated, the Kamailio defaults to HTTP secured with SSL.</para>
+          <para>An optional indication of the protocol to be used for communicating with the peering server. Both HTTP and HTTP secured with SSL/TLS are supported and are indicated by "http://" and "https://" respectively. If the protocol is not explicitly indicated, the &kamailio; defaults to HTTP secured with SSL.</para>
         </listitem>
         <listitem>
           <para>The Internet domain name for the peering server. An IP address may also be used, provided it is enclosed in square brackets such as [172.16.1.1].</para>
         </listitem>
         <listitem>
-          <para>An optional TCP port number for communicating with the peering server. If the port number is omitted, the Kamailio defaults to port 1080 (for HTTP) or port 1443 (for HTTP secured with SSL).</para>
+          <para>An optional TCP port number for communicating with the peering server. If the port number is omitted, the &kamailio; defaults to port 1080 (for HTTP) or port 1443 (for HTTP secured with SSL).</para>
           <para>The uniform resource identifier for requests to the peering server. This component is not optional and must be included.</para>
         </listitem>
       </itemizedlist>
@@ -88,7 +88,7 @@ modparam("osp","sp1_weight",1000)
     </section>
     <section>
       <title><varname>device_ip</varname></title>
-      <para>The device_ip (string) is a recommended parameter that explicitly defines the IP address of Kamailio in a peering request message (as SourceAlternate type=transport).  The IP address must be in brackets as shown in the example below.</para>
+      <para>The device_ip (string) is a recommended parameter that explicitly defines the IP address of &kamailio; in a peering request message (as SourceAlternate type=transport).  The IP address must be in brackets as shown in the example below.</para>
       <example>
         <title>Setting the device IP address</title>
         <programlisting format="linespecific">
@@ -98,7 +98,7 @@ modparam("osp","device_ip","[1.1.1.1]")
     </section>
     <section>
       <title><varname>device_port</varname></title>
-      <para>The device_port (string) parameter is an optional field which includes the SIP port being used by Kamailio in the peering request (as SourceAlternate type=network) to the peering server. If is not configured, this information is not included in the peering request. This field is useful if multiple Kamailios are running on the same Linux computer since it enables the peering server to administer different peering policies based on different SIP proxies. This parameter has not been implemented yet.</para>
+      <para>The device_port (string) parameter is an optional field which includes the SIP port being used by &kamailio; in the peering request (as SourceAlternate type=network) to the peering server. If is not configured, this information is not included in the peering request. This field is useful if multiple &kamailio; are running on the same Linux computer since it enables the peering server to administer different peering policies based on different SIP proxies. This parameter has not been implemented yet.</para>
       <example>
         <title>Setting the device port</title>
         <programlisting format="linespecific">
@@ -108,7 +108,7 @@ modparam("osp","device_port","5060")
     </section>
     <section>
       <title><varname>token_format</varname></title>
-      <para>When Kamailio receives a SIP INVITE with a peering token, the OSP Module will validate the token to determine whether or not the call has been authorized by a peering server. Peering tokens may, or may not, be digitally signed. The token_format (integer) parameter defines if Kamailio will validate signed or unsigned tokens or both. The values for token format are defined below. The default value is 2.</para>
+      <para>When &kamailio; receives a SIP INVITE with a peering token, the OSP Module will validate the token to determine whether or not the call has been authorized by a peering server. Peering tokens may, or may not, be digitally signed. The token_format (integer) parameter defines if &kamailio; will validate signed or unsigned tokens or both. The values for token format are defined below. The default value is 2.</para>
       <para>0 - Validate only signed tokens. Calls with valid signed tokens are allowed.</para>
       <para>1 - Validate only unsigned tokens. Calls with valid unsigned tokens are allowed.</para>
       <para>2 - Validate both signed and unsigned tokens are allowed. Calls with valid tokens are allowed.</para>
@@ -121,7 +121,7 @@ modparam("osp","token_format",2)
     </section>
     <section>
       <title><varname>private_key</varname>, <varname>local_certificate</varname>, <varname>ca_certificates</varname></title>
-      <para>These parameters identify files are used for validating peering authorization tokens and establishing a secure channel between Kamailio and a peering server using SSL.  The files are generated using the 'Enroll' utility from the OSP Toolkit. By default, the proxy will look for pkey.pem, localcert.pem, and cacart_0.pem in the default configuration directory. The default config directory is set at compile time using CFG_DIR and defaults to /usr/local/etc/kamailio/. The files may be copied to the expected file location or the parameters below may be changed.</para>
+      <para>These parameters identify files are used for validating peering authorization tokens and establishing a secure channel between &kamailio; and a peering server using SSL.  The files are generated using the 'Enroll' utility from the OSP Toolkit. By default, the proxy will look for pkey.pem, localcert.pem, and cacart_0.pem in the default configuration directory. The default config directory is set at compile time using CFG_DIR and defaults to /usr/local/etc/kamailio/. The files may be copied to the expected file location or the parameters below may be changed.</para>
       <example>
         <title>Set authorization files</title>
         <para>If the default CFG_DIR value was used at compile time, the files will be loaded from:</para>
@@ -194,7 +194,7 @@ modparam("osp","timeout",10)
     </section>
     <section>
       <title><varname>max_destinations</varname></title>
-      <para>The max_destinations (integer) parameter defines the maximum number of destinations that Kamailio requests the peering server to return in a peering response. The default value is 5.</para>
+      <para>The max_destinations (integer) parameter defines the maximum number of destinations that &kamailio; requests the peering server to return in a peering response. The default value is 5.</para>
       <example>
         <title>Setting the number of destination</title>
         <programlisting format="linespecific">

modules_k/osp/doc/osp_devel.xml

@@ -12,6 +12,6 @@
 <chapter>
   
   <title>&develguide;</title>
-  <para>The functions of the OSP modules are not used by other Kamailio modules.</para>
+  <para>The functions of the OSP modules are not used by other &kamailio; modules.</para>
 </chapter>
 

modules_k/perl/doc/perl_admin.xml

@@ -16,12 +16,12 @@
 	<section>
 		<title>Overview</title>
 		<para>
-		The time needed when writing a new Kamailio module unfortunately is quite high, while the
+		The time needed when writing a new &kamailio; module unfortunately is quite high, while the
 		options provided by the configuration file are limited to the features implemented in the
 		modules.
 		</para>
 		<para>
-		With this Perl module, you can easily implement your own Kamailio extensions in Perl. This allows
+		With this Perl module, you can easily implement your own &kamailio; extensions in Perl. This allows
 		for simple access to the full world of CPAN modules. SIP URI rewriting could be implemented
 		based on regular expressions; accessing arbitrary data backends, e.g. LDAP or Berkeley DB files,
 		is now extremely simple.
@@ -58,9 +58,9 @@ TYPEMAP:    echo "`perl -MConfig -e 'print $Config{installprivlib}'`/ExtUtils/ty
 	<section>
 		<title>Using the module</title>
 		<para>
-		The Perl module has two interfaces: The perl side, and the Kamailio side. Once a Perl
+		The Perl module has two interfaces: The perl side, and the &kamailio; side. Once a Perl
 		function is defined and loaded via the module parameters (see below), it may be
-		called in Kamailio's configuration at an arbitary point. E.g., you could write
+		called in &kamailio;'s configuration at an arbitary point. E.g., you could write
 		a function "ldap_alias" in Perl, and then execute <programlisting format="linespecific">
 ...
 if (perl_exec("ldap_alias")) {
@@ -110,7 +110,7 @@ if (perl_exec("ldap_alias")) {
 			</para>
 			</listitem>
 		</itemizedlist>
-		Additionally, a number of perl modules should be installed. The Kamailio::LDAPUtils package
+		Additionally, a number of perl modules should be installed. The &kamailio;::LDAPUtils package
 		relies on Net::LDAP to be installed. One of the sample scripts needs IPC::Shareable
 		</para>
 		<para>

modules_k/permissions/README

@@ -593,7 +593,7 @@ modparam("permissions", "peer_tag_avp", "$avp(i:707)")
    4.9. allow_source_address_group()
    4.10. allow_trusted([src_ip_pvar, proto_pvar])
 
-4.1.  allow_routing()
+4.1. allow_routing()
 
    Returns true if all pairs constructed as described in Section 1.1,
    "Call Routing" have appropriate permissions according to the
@@ -609,7 +609,7 @@ if (allow_routing()) {
 };
 ...
 
-4.2.  allow_routing(basename)
+4.2. allow_routing(basename)
 
    Returns true if all pairs constructed as described in Section 1.1,
    "Call Routing" have appropriate permissions according to the
@@ -632,7 +632,7 @@ if (allow_routing("basename")) {
 };
 ...
 
-4.3.  allow_routing(allow_file,deny_file)
+4.3. allow_routing(allow_file,deny_file)
 
    Returns true if all pairs constructed as described in Section 1.1,
    "Call Routing" have appropriate permissions according to the
@@ -657,7 +657,7 @@ if (allow_routing("rules.allow", "rules.deny")) {
 };
 ...
 
-4.4.  allow_register(basename)
+4.4. allow_register(basename)
 
    The function returns true if all pairs constructed as described in
    Section 1.2, "Registration Permissions" have appropriate permissions
@@ -685,7 +685,7 @@ if (method=="REGISTER") {
 };
 ...
 
-4.5.  allow_register(allow_file, deny_file)
+4.5. allow_register(allow_file, deny_file)
 
    The function returns true if all pairs constructed as described in
    Section 1.2, "Registration Permissions" have appropriate permissions
@@ -715,7 +715,7 @@ if (method=="REGISTER") {
 };
 ...
 
-4.6.  allow_uri(basename, pvar)
+4.6. allow_uri(basename, pvar)
 
    Returns true if the pair constructed as described in Section 1.3, "URI
    Permissions" have appropriate permissions according to the
@@ -742,7 +742,7 @@ if (allow_uri("basename", "$avp(i:705)") {  // Check URI stored in $avp(i:705)
 };
 ...
 
-4.7.  allow_address(group_id, ip_addr_pvar, port_pvar)
+4.7. allow_address(group_id, ip_addr_pvar, port_pvar)
 
    Returns true if IP address and port given as values of pvar arguments
    belonging to a group given as group_id argument matches an IP subnet
@@ -765,7 +765,7 @@ if (!allow_address("2", "$avp(i:704)", "$avp(i:705)") {
 };
 ...
 
-4.8.  allow_source_address(group_id)
+4.8. allow_source_address(group_id)
 
    Equal to allow_address(group_id, "$si", "$sp").
 
@@ -780,7 +780,7 @@ if (!allow_source_address("0")) {
 };
 ...
 
-4.9.  allow_source_address_group()
+4.9. allow_source_address_group()
 
    Checks if source address/port is found in cached address or subnet
    table in any group. If yes, returns that group. If not returns -1. Port
@@ -797,7 +797,7 @@ if ($var(group) != -1) {
 };
 ...
 
-4.10.  allow_trusted([src_ip_pvar, proto_pvar])
+4.10. allow_trusted([src_ip_pvar, proto_pvar])
 
    Checks based either on request's source address and transport protocol
    or source address and transport protocol given in pvar arguments, and
@@ -833,7 +833,7 @@ if (allow_trusted("$si", "$proto")) {
    5.5. trusted_dump
    5.6. allow_uri
 
-5.1.  address_reload
+5.1. address_reload
 
    Causes permissions module to re-read the contents of address database
    table into cache memory. In cache memory the entries are for
@@ -842,35 +842,35 @@ if (allow_trusted("$si", "$proto")) {
 
    Parameters: none
 
-5.2.  address_dump
+5.2. address_dump
 
    Causes permissions module to dump contents of cache memory address
    table.
 
    Parameters: none
 
-5.3.  subnet_dump
+5.3. subnet_dump
 
    Causes permissions module to dump contents of cache memory subnet
    table.
 
    Parameters: none
 
-5.4.  trusted_reload
+5.4. trusted_reload
 
    Causes permissions module to re-read the contents of trusted table into
    cache memory.
 
    Parameters: none
 
-5.5.  trusted_dump
+5.5. trusted_dump
 
    Causes permissions module to dump contents of trusted table from cache
    memory.
 
    Parameters: none
 
-5.6.  allow_uri
+5.6. allow_uri
 
    Tests if (URI, Contact) pair is allowed according to allow/deny files.
    The files must already have been loaded by Kamailio.

modules_k/permissions/doc/permissions_admin.xml

@@ -895,7 +895,7 @@ if (method=="REGISTER") {
 		</listitem>
 		<listitem>
 			<para><emphasis>pvar</emphasis> - Any
-			pseudo-variable defined in Kamailio.
+			pseudo-variable defined in &kamailio;.
 			</para>
 		</listitem>
 		</itemizedlist>
@@ -1111,7 +1111,7 @@ if (allow_trusted("$si", "$proto")) {
 		<para>
 		Tests if (URI, Contact) pair is allowed according to
 		allow/deny files.  The files must already have been
-		 loaded by Kamailio.
+		 loaded by &kamailio;.
 		</para>
 		<para>Parameters: </para>
 		<itemizedlist>

modules_k/presence/doc/presence_admin.xml

@@ -31,14 +31,14 @@
 	(by setting module parameter "fallback2db"). In this mode, in case a searched record is not 
 	found in cache, the search is continued	in database. This is useful for
 	an architecture in which processing and memory load might be divided on 
-	several Kamailio instances, maybe on different servers using the same database.
+	several &kamailio; instances, maybe on different servers using the same database.
 	</para>
 	<para>The module implements several API functions, that can be used by other
 	modules. In fact, it can be used only as a resource module, or "library".
 	This mode of operation is enabled if the db_url parameter is not set to any value.
 	</para>
 	<para>
-	The Kamailio Presence module implements the specifications in: RFC3265, RFC3856, RFC3857, 
+	The &kamailio; Presence module implements the specifications in: RFC3265, RFC3856, RFC3857, 
 	RFC3858.
 	</para>
 	</section>
@@ -580,7 +580,7 @@ if (method=="MESSAGE") {
 <section>
 	<title>Installation</title>
 	<para>
-	The module requires 3 tables in the Kamailio database: "presentity",
+	The module requires 3 tables in the &kamailio; database: "presentity",
 	"active_watchers" and "watchers". The SQL 
 	syntax to create them can be found in presence-create.sql     
 	script in the database directories in the kamailio/scripts folder.

modules_k/presence_xml/doc/presence_xml_admin.xml

@@ -233,7 +233,7 @@ modparam("presence_xml", "pidf_manipulation", 1)
 		<title><varname>integrated_xcap_server</varname> (int)</title>
 		<para>
 		This parameter is a flag for the type of XCAP server or servers 
-		used. If the XCAP server is integrated with Kamailio presence_XML
+		used. If the XCAP server is integrated with &kamailio; presence_XML
 		module and access the same database tables directly, like the XCAP-lite 
 		server from AG Projects, the parameter should be
 		set to a positive value. Apart from updating in xcap table,
@@ -322,7 +322,7 @@ modparam("presence_xml", "xml_ns", "rpid=urn:ietf:params:xml:ns:pidf:rpid")
 <section>
 	<title>Installation</title>
 	<para>
-	The module requires one table in Kamailio database: <quote>xcap</quote>. The SQL 
+	The module requires one table in &kamailio; database: <quote>xcap</quote>. The SQL 
 	syntax to create it can be found in presence-create.sql     
 	script in the database directories in the kamailio/scripts folder.
 	You can also find the complete database documentation on the

modules_k/pua/doc/pua_admin.xml

@@ -282,7 +282,7 @@ if(method=="NOTIFY")
 <section>
 	<title>Installation</title>
 	<para>
-	The module requires 1 table in Kamailio database: pua. The SQL 
+	The module requires 1 table in &kamailio; database: pua. The SQL 
 	syntax to create it can be found in presence_xml-create.sql     
 	script in the database directories in the kamailio/scripts folder.
 	You can also find the complete database documentation on the

modules_k/ratelimit/README

@@ -22,58 +22,57 @@ Hendrik Scholz
 
    Copyright © 2008-2009 VoIP Embedded Inc.
    Revision History
-   Revision $Revision: 4594 $ $Date: 2008-08-06 06:08:33 -0400
-                              (Wed, 06 Aug 2008) $
-     __________________________________________________________
+   Revision $Revision$ $Date$
+     __________________________________________________________________
 
    Table of Contents
 
    1. Admin Guide
 
-        1.1. Overview
-        1.2. Use Cases
-        1.3. Static Rate Limiting Algorithms
+        1. Overview
+        2. Use Cases
+        3. Static Rate Limiting Algorithms
 
-              1.3.1. Tail Drop Algorithm (TAILDROP)
-              1.3.2. Random Early Detection Algorithm (RED)
-              1.3.3. Network Algorithm (NETWORK)
+              3.1. Tail Drop Algorithm (TAILDROP)
+              3.2. Random Early Detection Algorithm (RED)
+              3.3. Network Algorithm (NETWORK)
 
-        1.4. Dynamic Rate Limiting Algorithms
+        4. Dynamic Rate Limiting Algorithms
 
-              1.4.1. Feedback Algorithm (FEEDBACK)
+              4.1. Feedback Algorithm (FEEDBACK)
 
-        1.5. Dependencies
+        5. Dependencies
 
-              1.5.1. Kamailio Modules
-              1.5.2. External Libraries or Applications
+              5.1. Kamailio Modules
+              5.2. External Libraries or Applications
 
-        1.6. Exported Parameters
+        6. Exported Parameters
 
-              1.6.1. timer_interval (integer)
-              1.6.2. queue (integer:string)
-              1.6.3. pipe (integer:string:integer)
-              1.6.4. reply_code (integer)
-              1.6.5. reply_reason (string)
+              6.1. timer_interval (integer)
+              6.2. queue (integer:string)
+              6.3. pipe (integer:string:integer)
+              6.4. reply_code (integer)
+              6.5. reply_reason (string)
 
-        1.7. Exported Functions
+        7. Exported Functions
 
-              1.7.1. rl_check([pvar])
-              1.7.2. rl_check_pipe([pipe_no])
-              1.7.3. rl_drop([[min ], max])
+              7.1. rl_check([pvar])
+              7.2. rl_check_pipe([pipe_no])
+              7.3. rl_drop([[min ], max])
 
-        1.8. Exported MI Functions
+        8. Exported MI Functions
 
-              1.8.1. rl_stats
-              1.8.2. rl_set_pipe
-              1.8.3. rl_get_pipes
-              1.8.4. rl_set_queue
-              1.8.5. rl_get_queues
-              1.8.6. rl_set_pid
-              1.8.7. rl_get_pid
-              1.8.8. rl_push_load
-              1.8.9. rl_set_dbg
+              8.1. rl_stats
+              8.2. rl_set_pipe
+              8.3. rl_get_pipes
+              8.4. rl_set_queue
+              8.5. rl_get_queues
+              8.6. rl_set_pid
+              8.7. rl_get_pid
+              8.8. rl_push_load
+              8.9. rl_set_dbg
 
-        1.9. Known limitations
+        9. Known limitations
 
    List of Examples
 
@@ -88,25 +87,71 @@ Hendrik Scholz
 
 Chapter 1. Admin Guide
 
-1.1. Overview
+   Table of Contents
+
+   1. Overview
+   2. Use Cases
+   3. Static Rate Limiting Algorithms
+
+        3.1. Tail Drop Algorithm (TAILDROP)
+        3.2. Random Early Detection Algorithm (RED)
+        3.3. Network Algorithm (NETWORK)
+
+   4. Dynamic Rate Limiting Algorithms
+
+        4.1. Feedback Algorithm (FEEDBACK)
+
+   5. Dependencies
+
+        5.1. Kamailio Modules
+        5.2. External Libraries or Applications
+
+   6. Exported Parameters
+
+        6.1. timer_interval (integer)
+        6.2. queue (integer:string)
+        6.3. pipe (integer:string:integer)
+        6.4. reply_code (integer)
+        6.5. reply_reason (string)
+
+   7. Exported Functions
 
-   This module implements rate limiting for SIP requests. In
-   contrast to the PIKE module this limits the flow based on a per
-   SIP request type basis and not per source IP. The MI interface
-   can be used to change tunables while running Kamailio.
+        7.1. rl_check([pvar])
+        7.2. rl_check_pipe([pipe_no])
+        7.3. rl_drop([[min ], max])
 
-   The module implements the pipe/queue policy from BSD's ipfw
-   manual, with some simplifications. In principle, each specified
-   method is associated with its own queue and a number of queues
-   are connected to a certain pipe (see the queue and pipe
-   params).
+   8. Exported MI Functions
 
-1.2. Use Cases
+        8.1. rl_stats
+        8.2. rl_set_pipe
+        8.3. rl_get_pipes
+        8.4. rl_set_queue
+        8.5. rl_get_queues
+        8.6. rl_set_pid
+        8.7. rl_get_pid
+        8.8. rl_push_load
+        8.9. rl_set_dbg
+
+   9. Known limitations
+
+1. Overview
+
+   This module implements rate limiting for SIP requests. In contrast to
+   the PIKE module this limits the flow based on a per SIP request type
+   basis and not per source IP. The MI interface can be used to change
+   tunables while running Kamailio.
+
+   The module implements the pipe/queue policy from BSD's ipfw manual,
+   with some simplifications. In principle, each specified method is
+   associated with its own queue and a number of queues are connected to a
+   certain pipe (see the queue and pipe params).
+
+2. Use Cases
 
    Limiting the rate messages are processed on a system directly
-   influences the load. The ratelimit module can be used to
-   protect a single host or to protect an Kamailio cluster when
-   run on the dispatching box in front.
+   influences the load. The ratelimit module can be used to protect a
+   single host or to protect an Kamailio cluster when run on the
+   dispatching box in front.
 
    A sample configuration snippet might look like this:
 ...
@@ -118,112 +163,122 @@ Chapter 1. Admin Guide
         };
 ...
 
-   Upon every incoming request listed above rl_check is invoked.
-   It returns an OK code if the current per request load is below
-   the configured threshold. If the load is exceeded the function
-   returns an error and an administrator can discard requests with
-   a stateless response.
-
-1.3. Static Rate Limiting Algorithms
-
-   The ratelimit module supports two different statc algorithms to
-   be used by rl_check to determine whether a message should be
-   blocked or not.
-
-1.3.1. Tail Drop Algorithm (TAILDROP)
-
-   This is a trivial algorithm that imposes some risks when used
-   in conjunction with long timer intervals. At the start of each
-   interval an internal counter is reset and incremented for each
-   incoming message. Once the counter hits the configured limit
-   rl_check returns an error.
-
-   The downside of this algorithm is that it can lead to SIP
-   client synchronization. During a relatively long interval only
-   the first requests (i.e. REGISTERs) would make it through.
-   Following messages (i.e. RE-REGISTERs) will all hit the SIP
-   proxy at the same time when a common Expire timer expired.
-   Other requests will be retransmissed after given time, the same
-   on all devices with the same firmware/by the same vendor.
-
-1.3.2. Random Early Detection Algorithm (RED)
-
-   Random Early Detection tries to circumvent the synchronization
-   problem imposed by the tail drop algorithm by measuring the
-   average load and adapting the drop rate dynamically. When
-   running with the RED algorithm (enabled by default) Kamailio
-   will return errors to the Kamailio routing engine every n'th
-   packet trying to evenly spread the measured load of the last
-   timer interval onto the current interval. As a negative side
-   effect Kamailio might drop messages although the limit might
-   not be reached within the interval. Decrease the timer interval
+   Upon every incoming request listed above rl_check is invoked. It
+   returns an OK code if the current per request load is below the
+   configured threshold. If the load is exceeded the function returns an
+   error and an administrator can discard requests with a stateless
+   response.
+
+3. Static Rate Limiting Algorithms
+
+   3.1. Tail Drop Algorithm (TAILDROP)
+   3.2. Random Early Detection Algorithm (RED)
+   3.3. Network Algorithm (NETWORK)
+
+   The ratelimit module supports two different statc algorithms to be used
+   by rl_check to determine whether a message should be blocked or not.
+
+3.1. Tail Drop Algorithm (TAILDROP)
+
+   This is a trivial algorithm that imposes some risks when used in
+   conjunction with long timer intervals. At the start of each interval an
+   internal counter is reset and incremented for each incoming message.
+   Once the counter hits the configured limit rl_check returns an error.
+
+   The downside of this algorithm is that it can lead to SIP client
+   synchronization. During a relatively long interval only the first
+   requests (i.e. REGISTERs) would make it through. Following messages
+   (i.e. RE-REGISTERs) will all hit the SIP proxy at the same time when a
+   common Expire timer expired. Other requests will be retransmissed after
+   given time, the same on all devices with the same firmware/by the same
+   vendor.
+
+3.2. Random Early Detection Algorithm (RED)
+
+   Random Early Detection tries to circumvent the synchronization problem
+   imposed by the tail drop algorithm by measuring the average load and
+   adapting the drop rate dynamically. When running with the RED algorithm
+   (enabled by default) Kamailio will return errors to the Kamailio
+   routing engine every n'th packet trying to evenly spread the measured
+   load of the last timer interval onto the current interval. As a
+   negative side effect Kamailio might drop messages although the limit
+   might not be reached within the interval. Decrease the timer interval
    if you encounter this.
 
-1.3.3. Network Algorithm (NETWORK)
+3.3. Network Algorithm (NETWORK)
 
-   This algorithm relies on information provided by network
-   interfaces. The total amount of bytes waiting to be consumed on
-   all the network interfaces is retrieved once every
-   timer_interval seconds. If the returned amount exceeds the
-   limit specified in the modparam, rl_check returns an error.
+   This algorithm relies on information provided by network interfaces.
+   The total amount of bytes waiting to be consumed on all the network
+   interfaces is retrieved once every timer_interval seconds. If the
+   returned amount exceeds the limit specified in the modparam, rl_check
+   returns an error.
 
-1.4. Dynamic Rate Limiting Algorithms
+4. Dynamic Rate Limiting Algorithms
 
-   When running openser on different machines, one has to adjust
-   the drop rates for the static algorithms to maintain a sub 100%
-   load average or packets start getting dropped in the network
-   stack. While this is not in itself difficult, it isn't neither
-   accurate nor trivial: another server taking a notable fraction
-   of the cpu time will require re-tuning the parameters.
+   4.1. Feedback Algorithm (FEEDBACK)
 
-   While tuning the drop rates from the outside based on a certain
-   factor is possible, having the algorithm run inside ratelimit
-   permits tuning the rates based on internal server parameters
-   and is somewhat more flexible (or it will be when support for
-   external load factors - as opposed to cpu load - is added).
+   When running openser on different machines, one has to adjust the drop
+   rates for the static algorithms to maintain a sub 100% load average or
+   packets start getting dropped in the network stack. While this is not
+   in itself difficult, it isn't neither accurate nor trivial: another
+   server taking a notable fraction of the cpu time will require re-tuning
+   the parameters.
 
-1.4.1. Feedback Algorithm (FEEDBACK)
+   While tuning the drop rates from the outside based on a certain factor
+   is possible, having the algorithm run inside ratelimit permits tuning
+   the rates based on internal server parameters and is somewhat more
+   flexible (or it will be when support for external load factors - as
+   opposed to cpu load - is added).
 
-   Using the PID Controller model (see Wikipedia page), the drop
-   rate is adjusted dynamically based on the load factor so that
-   the load factor always drifts towards the specified limit (or
-   setpoint, in PID terms).
+4.1. Feedback Algorithm (FEEDBACK)
 
-   As reading the cpu load average is relatively expensive
-   (opening /proc/stat, parsing it, etc), this only happens once
-   every timer_interval seconds and consequently the FEEDBACK
-   value is only at these intervals recomputed. This in turn makes
-   it difficult for the drop rate to adjust quickly. Worst case
-   scenarios are request rates going up/down instantly by
-   thousands - it takes up to 20 seconds for the controller to
-   adapt to the new request rate.
+   Using the PID Controller model (see Wikipedia page), the drop rate is
+   adjusted dynamically based on the load factor so that the load factor
+   always drifts towards the specified limit (or setpoint, in PID terms).
 
-   Generally though, as real life request rates drift by less,
-   adapting should happen much faster.
+   As reading the cpu load average is relatively expensive (opening
+   /proc/stat, parsing it, etc), this only happens once every
+   timer_interval seconds and consequently the FEEDBACK value is only at
+   these intervals recomputed. This in turn makes it difficult for the
+   drop rate to adjust quickly. Worst case scenarios are request rates
+   going up/down instantly by thousands - it takes up to 20 seconds for
+   the controller to adapt to the new request rate.
 
-1.5. Dependencies
+   Generally though, as real life request rates drift by less, adapting
+   should happen much faster.
 
-1.5.1. Kamailio Modules
+5. Dependencies
+
+   5.1. Kamailio Modules
+   5.2. External Libraries or Applications
+
+5.1. Kamailio Modules
 
    The following modules must be loaded before this module:
      * No dependencies on other Kamailio modules.
 
-1.5.2. External Libraries or Applications
+5.2. External Libraries or Applications
 
-   The following libraries or applications must be installed
-   before running Kamailio with this module loaded:
+   The following libraries or applications must be installed before
+   running Kamailio with this module loaded:
      * None.
 
-1.6. Exported Parameters
+6. Exported Parameters
+
+   6.1. timer_interval (integer)
+   6.2. queue (integer:string)
+   6.3. pipe (integer:string:integer)
+   6.4. reply_code (integer)
+   6.5. reply_reason (string)
 
-1.6.1. timer_interval (integer)
+6.1. timer_interval (integer)
 
-   The initial length of a timer interval in seconds. All amounts
-   of messages have to be divided by this timer to get a messages
-   per second value.
+   The initial length of a timer interval in seconds. All amounts of
+   messages have to be divided by this timer to get a messages per second
+   value.
 
-   IMPORTANT: A too small value may lead to performance penalties
-   due to timer process overloading.
+   IMPORTANT: A too small value may lead to performance penalties due to
+   timer process overloading.
 
    Default value is 10.
 
@@ -232,17 +287,16 @@ Chapter 1. Admin Guide
 modparam("ratelimit", "timer_interval", 5)
 ...
 
-1.6.2. queue (integer:string)
+6.2. queue (integer:string)
 
-   The format of the queue parameter is "pipe_no:method". For each
-   defined method, the algorithm defined by pipe number "pipe_no"
-   will be used.
+   The format of the queue parameter is "pipe_no:method". For each defined
+   method, the algorithm defined by pipe number "pipe_no" will be used.
 
-   To specify a queue that accepts all methods, use * instead of
-   METHOD. As queues are matched against request methods, you will
-   usually want to have this as the last queue added or other
-   queues with specific methods will never match. At this time,
-   glob or regexp patterns are not supported.
+   To specify a queue that accepts all methods, use * instead of METHOD.
+   As queues are matched against request methods, you will usually want to
+   have this as the last queue added or other queues with specific methods
+   will never match. At this time, glob or regexp patterns are not
+   supported.
 
    Example 1.2. Set queue parameter
 ...
@@ -254,17 +308,16 @@ modparam("ratelimit", "queue", "3:INVITE")
 modparam("ratelimit", "queue", "2:*")
 ...
 
-1.6.3. pipe (integer:string:integer)
+6.3. pipe (integer:string:integer)
 
-   The format of the pipe param is "pipe_no:algorithm:limit". For
-   each defined pipe, the given algorithm with the given limit
-   will be used.
+   The format of the pipe param is "pipe_no:algorithm:limit". For each
+   defined pipe, the given algorithm with the given limit will be used.
 
-   A pipe is characterised by its algorithm and limit (bandwidth,
-   in ipfw terms). When specifying a limit, the unit depends on
-   the algorithm used and doesn't need to be spedified also (eg,
-   for TAILDROP or RED, limit means packets/sec, whereas with the
-   FEEDBACK algorithm, it means [CPU] load factor).
+   A pipe is characterised by its algorithm and limit (bandwidth, in ipfw
+   terms). When specifying a limit, the unit depends on the algorithm used
+   and doesn't need to be spedified also (eg, for TAILDROP or RED, limit
+   means packets/sec, whereas with the FEEDBACK algorithm, it means [CPU]
+   load factor).
 
    Example 1.3. Set pipe parameter
 ...
@@ -281,7 +334,7 @@ modparam("ratelimit", "pipe", "3:FEEDBACK:80")
 modparam("ratelimit", "pipe", "4:NETWORK:10000")
 ...
 
-1.6.4. reply_code (integer)
+6.4. reply_code (integer)
 
    The code of the reply sent by Kamailio while limiting.
 
@@ -292,7 +345,7 @@ modparam("ratelimit", "pipe", "4:NETWORK:10000")
 modparam("ratelimit", "reply_code", 505)
 ...
 
-1.6.5. reply_reason (string)
+6.5. reply_reason (string)
 
    The reason of the reply sent by Kamailio while limiting.
 
@@ -303,21 +356,24 @@ modparam("ratelimit", "reply_code", 505)
 modparam("ratelimit", "reply_reason", "Limiting")
 ...
 
-1.7. Exported Functions
+7. Exported Functions
 
-1.7.1.  rl_check([pvar])
+   7.1. rl_check([pvar])
+   7.2. rl_check_pipe([pipe_no])
+   7.3. rl_drop([[min ], max])
 
-   Check the current request against the matched ratelimit
-   algorithm. If no parameter is provided, the queue will be
-   matched based on method type, and then the pipe will be
-   identified based on the matched queue. If a pipe number is
-   provided as a parameter, then the given pipe number will be
-   used for identifying the ratelimit algorithm. The pipe number
-   must be provided via a pseudo variabile. It is recommended to
-   provide the pipe number via an integer pseudovariabile.
+7.1. rl_check([pvar])
 
-   The method will return an error code if the limit for the
-   matched algorithm is reached.
+   Check the current request against the matched ratelimit algorithm. If
+   no parameter is provided, the queue will be matched based on method
+   type, and then the pipe will be identified based on the matched queue.
+   If a pipe number is provided as a parameter, then the given pipe number
+   will be used for identifying the ratelimit algorithm. The pipe number
+   must be provided via a pseudo variabile. It is recommended to provide
+   the pipe number via an integer pseudovariabile.
+
+   The method will return an error code if the limit for the matched
+   algorithm is reached.
 
    Meaning of the parameters is as follows:
      * pvar - the pseudovariable holding the pipe id to be used by
@@ -350,17 +406,16 @@ modparam("ratelimit", "reply_reason", "Limiting")
         };
 ...
 
-1.7.2.  rl_check_pipe([pipe_no])
+7.2. rl_check_pipe([pipe_no])
 
-   Check the current request against the matched ratelimit
-   algorithm. If no parameter is provided, the queue will be
-   matched based on method type, and then the pipe will be
-   identified based on the matched queue. If a pipe number is
-   provided as a parameter, then the given pipe number will be
-   used for identifying the ratelimit algorithm.
+   Check the current request against the matched ratelimit algorithm. If
+   no parameter is provided, the queue will be matched based on method
+   type, and then the pipe will be identified based on the matched queue.
+   If a pipe number is provided as a parameter, then the given pipe number
+   will be used for identifying the ratelimit algorithm.
 
-   The method will return an error code if the limit for the
-   matched algorithm is reached.
+   The method will return an error code if the limit for the matched
+   algorithm is reached.
 
    Meaning of the parameters is as follows:
      * pipe_no - the pipe id to be used by ratelimit.
@@ -382,16 +437,15 @@ modparam("ratelimit", "reply_reason", "Limiting")
         };
 ...
 
-1.7.3.  rl_drop([[min ], max])
+7.3. rl_drop([[min ], max])
 
-   For the current request, a "503 - Server Unavailable" reply is
-   sent back. The reply may or may not have a "Retry-After"
-   header. If no parameter is given, there will be no
-   "Retry-After" header. If only the max parameter is given, the
-   reply will contain a "Retry-After: max" header. If both min and
-   max params are given, the reply will contain a "Retry-After:
-   random" header with random being a random value between the
-   given min and max.
+   For the current request, a "503 - Server Unavailable" reply is sent
+   back. The reply may or may not have a "Retry-After" header. If no
+   parameter is given, there will be no "Retry-After" header. If only the
+   max parameter is given, the reply will contain a "Retry-After: max"
+   header. If both min and max params are given, the reply will contain a
+   "Retry-After: random" header with random being a random value between
+   the given min and max.
 
    Meaning of the parameters is as follows:
      * min - the minimum value of "Retry-After" header.
@@ -409,9 +463,19 @@ modparam("ratelimit", "reply_reason", "Limiting")
         };
 ...
 
-1.8. Exported MI Functions
+8. Exported MI Functions
+
+   8.1. rl_stats
+   8.2. rl_set_pipe
+   8.3. rl_get_pipes
+   8.4. rl_set_queue
+   8.5. rl_get_queues
+   8.6. rl_set_pid
+   8.7. rl_get_pid
+   8.8. rl_push_load
+   8.9. rl_set_dbg
 
-1.8.1.  rl_stats
+8.1. rl_stats
 
    Lists the parameters and variabiles in the ratelimit module.
 
@@ -423,7 +487,7 @@ modparam("ratelimit", "reply_reason", "Limiting")
                 :rl_stats:_reply_fifo_file_
                 _empty_line_
 
-1.8.2.  rl_set_pipe
+8.2. rl_set_pipe
 
    Sets the pipe parameters for the given pipe id.
 
@@ -431,8 +495,7 @@ modparam("ratelimit", "reply_reason", "Limiting")
 
    Parameters:
      * pipe_id - pipe id.
-     * pipe_algorithm - the algorithm assigned to the given pipe
-       id.
+     * pipe_algorithm - the algorithm assigned to the given pipe id.
      * pipe_limit - the limit assigned to the given pipe id.
 
    MI FIFO Command Format:
@@ -442,7 +505,7 @@ modparam("ratelimit", "reply_reason", "Limiting")
                 10
                 _empty_line_
 
-1.8.3.  rl_get_pipes
+8.3. rl_get_pipes
 
    Gets the list of in use pipes.
 
@@ -454,7 +517,7 @@ modparam("ratelimit", "reply_reason", "Limiting")
                 :rl_get_pipes:_reply_fifo_file_
                 _empty_line_
 
-1.8.4.  rl_set_queue
+8.4. rl_set_queue
 
    Sets the queue parameters for the given queue id.
 
@@ -472,7 +535,7 @@ modparam("ratelimit", "reply_reason", "Limiting")
                 2
                 _empty_line_
 
-1.8.5.  rl_get_queues
+8.5. rl_get_queues
 
    Gets the list of in use queues.
 
@@ -484,7 +547,7 @@ modparam("ratelimit", "reply_reason", "Limiting")
                 :rl_get_queues:_reply_fifo_file_
                 _empty_line_
 
-1.8.6.  rl_set_pid
+8.6. rl_set_pid
 
    Sets the PID Controller parameters for the Feedback Algorithm.
 
@@ -502,7 +565,7 @@ modparam("ratelimit", "reply_reason", "Limiting")
                 0.5
                 _empty_line_
 
-1.8.7.  rl_get_pid
+8.7. rl_get_pid
 
    Gets the list of in use PID Controller parameters.
 
@@ -514,27 +577,27 @@ modparam("ratelimit", "reply_reason", "Limiting")
                 :rl_get_pid:_reply_fifo_file_
                 _empty_line_
 
-1.8.8.  rl_push_load
+8.8. rl_push_load
 
-   Force the value of the load parameter. This methos is usefull
-   for testing the Feedback algorithm.
+   Force the value of the load parameter. This methos is usefull for
+   testing the Feedback algorithm.
 
    Name: rl_push_load
 
    Parameters:
-     * load - the forced value of load (it must be greater then
-       0.0 and smaller then 1.0).
+     * load - the forced value of load (it must be greater then 0.0 and
+       smaller then 1.0).
 
    MI FIFO Command Format:
                 :rl_push_load:_reply_fifo_file_
                 0.85
                 _empty_line_
 
-1.8.9.  rl_set_dbg
+8.9. rl_set_dbg
 
-   This MI function will enable/disable a WARNING debug log
-   exposing the internal counters for each pipe (useful in
-   monitoring the ratelimit internals).
+   This MI function will enable/disable a WARNING debug log exposing the
+   internal counters for each pipe (useful in monitoring the ratelimit
+   internals).
 
    Name: rl_set_dbg
 
@@ -546,9 +609,9 @@ modparam("ratelimit", "reply_reason", "Limiting")
                 1
                 _empty_line_
 
-1.9. Known limitations
+9. Known limitations
 
-   The pipes and queues are stored as static vectors, so no more
-   than MAX_PIPES/MAX_QUEUES can be added without recompilation.
+   The pipes and queues are stored as static vectors, so no more than
+   MAX_PIPES/MAX_QUEUES can be added without recompilation.
      * MAX_PIPES - 16
      * MAX_QUEUES - 10

modules_k/ratelimit/doc/ratelimit_admin.xml

@@ -19,7 +19,7 @@
 		This module implements rate limiting for SIP requests. In contrast to
 		the PIKE module this limits the flow based on a per SIP request type
 		basis and not per source IP. The MI interface can be used to
-		change tunables while running Kamailio.
+		change tunables while running &kamailio;.
 	</para>
 	<para>
 		The module implements the pipe/queue policy from BSD's ipfw manual,
@@ -33,7 +33,7 @@
 	<para>
 		Limiting the rate messages are processed on a system directly
 		influences the load. The ratelimit module can be used to protect a
-		single host or to protect an Kamailio cluster when run on the dispatching
+		single host or to protect an &kamailio; cluster when run on the dispatching
 		box in front.
 	</para>
 	<para>
@@ -89,10 +89,10 @@
 		Random Early Detection tries to circumvent the synchronization problem
 		imposed by the tail drop algorithm by measuring the average load and
 		adapting the drop rate dynamically. When running with the RED
-		algorithm (enabled by default) Kamailio will return errors to the Kamailio
+		algorithm (enabled by default) &kamailio; will return errors to the &kamailio;
 		routing engine every n'th packet trying to evenly spread the measured
 		load of the last timer interval onto the current interval. As a
-		negative side effect Kamailio might drop messages although the limit might
+		negative side effect &kamailio; might drop messages although the limit might
 		not be reached within the interval. Decrease the timer interval if you
 		encounter this.
 		</para>
@@ -267,7 +267,7 @@ modparam("ratelimit", "pipe", "4:NETWORK:10000")
 	<section>
 		<title><varname>reply_code</varname> (integer)</title>
 		<para>
-		The code of the reply sent by Kamailio while limiting.
+		The code of the reply sent by &kamailio; while limiting.
 		</para>
 		<para>
 		<emphasis>
@@ -286,7 +286,7 @@ modparam("ratelimit", "reply_code", 505)
 	<section>
 		<title><varname>reply_reason</varname> (string)</title>
 		<para>
-		The reason of the reply sent by Kamailio while limiting.
+		The reason of the reply sent by &kamailio; while limiting.
 		</para>
 		<para>
 		<emphasis>

modules_k/regex/doc/regex_admin.xml

@@ -49,7 +49,7 @@
 				<itemizedlist>
 					<listitem>
 						<para>
-							<emphasis>No dependencies on other Kamailio modules</emphasis>.
+							<emphasis>No dependencies on other &kamailio; modules</emphasis>.
 						</para>
 					</listitem>
 				</itemizedlist>

modules_k/registrar/README

@@ -557,7 +557,7 @@ modparam("registrar", "reg_callid_avp", "$avp(s:avp)")
    4.7. reg_fetch_contacts(domain, uri, profile)
    4.8. reg_free_contacts(profile)
 
-4.1.  save(domain)
+4.1. save(domain)
 
    The function processes a REGISTER message. It can add, remove or modify
    usrloc records depending on Contact and Expires HFs in the REGISTER
@@ -584,7 +584,7 @@ modparam("registrar", "reg_callid_avp", "$avp(s:avp)")
 save("location");
 ...
 
-4.2.  save(domain,flags)
+4.2. save(domain,flags)
 
    Same as save() but it accepts a set of flags for controlling its
    behaviour.
@@ -611,7 +611,7 @@ save("location");
 save("location","0x01");
 ...
 
-4.3.  lookup(domain)
+4.3. lookup(domain)
 
    The functions extracts username from Request-URI and tries to find all
    contacts for the username in usrloc. If there are no such contacts, -1
@@ -649,7 +649,7 @@ switch ($retcode) {
 };
 ...
 
-4.4.  registered(domain)
+4.4. registered(domain)
 
    The function returns true if the AOR in the Request-URI is registered,
    false otherwise. The function does not modify the message being
@@ -669,7 +669,7 @@ if (registered("location")) {
 };
 ...
 
-4.5.  add_sock_hdr(hdr_name)
+4.5. add_sock_hdr(hdr_name)
 
    Adds to the current REGISTER request a new header with "hdr_name" which
    contains the description of the received socket (proto:ip:port)
@@ -686,7 +686,7 @@ if (registered("location")) {
 add_sock_hdr("Sock-Info");
 ...
 
-4.6.  unregister(domain, uri)
+4.6. unregister(domain, uri)
 
    The function remove all the contact associated to 'uri'.
 
@@ -705,7 +705,7 @@ unregister("location", "$ru");
 unregister("location", "sip:[email protected]");
 ...
 
-4.7.  reg_fetch_contacts(domain, uri, profile)
+4.7. reg_fetch_contacts(domain, uri, profile)
 
    The function fetches the contacts for 'uri' from table 'domain' to
    pseudo-variable $ulc(profile).
@@ -727,7 +727,7 @@ reg_fetch_contacts("location", "$ru", "callee");
 reg_fetch_contacts("location", "sip:[email protected]", "caller");
 ...
 
-4.8.  reg_free_contacts(profile)
+4.8. reg_free_contacts(profile)
 
    The function frees the contacts from pseudo-variable $ulc(profile).
    Should be called to release the content of a profile. Anyhow, fetching
@@ -850,60 +850,54 @@ Chapter 2. Frequently Asked Questions
 
    2.1.
 
-       What happend with the old "nat_flag" module parameter?
-
-       In was removed, as the module internally loads this value from the
-       "USRLOC" module (see the "nat_bflag" USRLOC parameter).
+   What happend with the old "nat_flag" module parameter?
 
+   In was removed, as the module internally loads this value from the
+   "USRLOC" module (see the "nat_bflag" USRLOC parameter).
    2.2.
 
-       What happend with the old "use_domain" module parameter?
-
-       In was removed, as the module internally loads this option from the
-       "USRLOC" module. This was done in order to simplify the configuration.
+   What happend with the old "use_domain" module parameter?
 
+   In was removed, as the module internally loads this option from the
+   "USRLOC" module. This was done in order to simplify the configuration.
    2.3.
 
-       What happend with the old "save_noreply" and "save_memory" functions?
-
-       There functions were merged into the new "save(domain,flags)"
-       functions. If a reply should be sent or if the DB should be updated
-       also is controlled via the flags.
+   What happend with the old "save_noreply" and "save_memory" functions?
 
+   There functions were merged into the new "save(domain,flags)"
+   functions. If a reply should be sent or if the DB should be updated
+   also is controlled via the flags.
    2.4.
 
-       Where can I find more about Kamailio?
-
-       Take a look at http://www.kamailio.org/.
+   Where can I find more about Kamailio?
 
+   Take a look at http://www.kamailio.org/.
    2.5.
 
-       Where can I post a question about this module?
-
-       First at all check if your question was already answered on one of our
-       mailing lists:
-         * User Mailing List -
-           http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
-         * Developer Mailing List -
-           http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
+   Where can I post a question about this module?
 
-       E-mails regarding any stable Kamailio release should be sent to
-       <[email protected]> and e-mails regarding development versions
-       should be sent to <[email protected]>.
+   First at all check if your question was already answered on one of our
+   mailing lists:
+     * User Mailing List -
+       http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
+     * Developer Mailing List -
+       http://lists.kamailio.org/cgi-bin/mailman/listinfo/devel
 
-       If you want to keep the mail private, send it to
-       <[email protected]>.
+   E-mails regarding any stable Kamailio release should be sent to
+   <[email protected]> and e-mails regarding development versions
+   should be sent to <[email protected]>.
 
+   If you want to keep the mail private, send it to
+   <[email protected]>.
    2.6.
 
-       How can I report a bug?
-
-       Please follow the guidelines provided at:
-       http://sourceforge.net/tracker/?group_id=139143.
+   How can I report a bug?
 
+   Please follow the guidelines provided at:
+   http://sourceforge.net/tracker/?group_id=139143.
    2.7.
 
-       What happened to the desc_time_order parameter?
+   What happened to the desc_time_order parameter?
 
-       It was removed, as its functionality was mmigrate into usrloc module,
-       were there is a parameter with the same name.
+   It was removed, as its functionality was mmigrate into usrloc module,
+   were there is a parameter with the same name.

modules_k/registrar/doc/registrar_faq.xml

@@ -56,7 +56,7 @@
 
 	<qandaentry>
 		<question>
-		<para>Where can I find more about Kamailio?</para>
+		<para>Where can I find more about &kamailio;?</para>
 		</question>
 		<answer>
 		<para>

modules_k/rls/doc/rls_admin.xml

@@ -412,7 +412,7 @@ if(method=="NOTIFY")
 <section>
 	<title>Installation</title>
 	<para>
-	The module requires 2 table in Kamailio database: rls_presentity
+	The module requires 2 tables in &kamailio; database: rls_presentity
 	and rls_watchers.The SQL syntax to create them can be found in
 	rls-create.sql script in the database directories in
 	the kamailio/scripts folder.

modules_k/rr/README

@@ -20,48 +20,47 @@ Bogdan-Andrei Iancu
 
    Copyright © 2005 voice-system.ro
    Revision History
-   Revision $Revision$ $Date: 2008-08-06 12:08:33 +0200
-                              (Mi, 06 Aug 2008) $
-     __________________________________________________________
+   Revision $Revision$ $Date$
+     __________________________________________________________________
 
    Table of Contents
 
    1. Admin Guide
 
-        1.1. Overview
-        1.2. Dialog support
-        1.3. Dependencies
+        1. Overview
+        2. Dialog support
+        3. Dependencies
 
-              1.3.1. Kamailio Modules
-              1.3.2. External Libraries or Applications
+              3.1. Kamailio Modules
+              3.2. External Libraries or Applications
 
-        1.4. Exported Parameters
+        4. Exported Parameters
 
-              1.4.1. enable_full_lr (integer)
-              1.4.2. append_fromtag (integer)
-              1.4.3. enable_double_rr (integer)
-              1.4.4. add_username (integer)
+              4.1. enable_full_lr (integer)
+              4.2. append_fromtag (integer)
+              4.3. enable_double_rr (integer)
+              4.4. add_username (integer)
 
-        1.5. Exported Functions
+        5. Exported Functions
 
-              1.5.1. loose_route()
-              1.5.2. record_route() and record_route(string)
-              1.5.3. record_route_preset(string)
-              1.5.4. add_rr_param(param)
-              1.5.5. check_route_param(re)
-              1.5.6. is_direction(dir)
+              5.1. loose_route()
+              5.2. record_route() and record_route(string)
+              5.3. record_route_preset(string)
+              5.4. add_rr_param(param)
+              5.5. check_route_param(re)
+              5.6. is_direction(dir)
 
    2. Developer Guide
 
-        2.1. Available Functions
+        1. Available Functions
 
-              2.1.1. add_rr_param( msg, param)
-              2.1.2. check_route_param( msg, re)
-              2.1.3. is_direction( msg, dir)
-              2.1.4. get_route_param( msg, name, val)
-              2.1.5. register_rrcb( callback, param)
+              1.1. add_rr_param( msg, param)
+              1.2. check_route_param( msg, re)
+              1.3. is_direction( msg, dir)
+              1.4. get_route_param( msg, name, val)
+              1.5. register_rrcb( callback, param)
 
-        2.2. Examples
+        2. Examples
 
    List of Examples
 
@@ -75,52 +74,72 @@ Bogdan-Andrei Iancu
    1.8. record_route_preset usage
    1.9. add_rr_param usage
    1.10. check_route_param usage
-   1.11. check_route_param usage
+   1.11. is_direction usage
    2.1. Loading RR module's API from another module
 
 Chapter 1. Admin Guide
 
-1.1. Overview
+   Table of Contents
+
+   1. Overview
+   2. Dialog support
+   3. Dependencies
+
+        3.1. Kamailio Modules
+        3.2. External Libraries or Applications
+
+   4. Exported Parameters
+
+        4.1. enable_full_lr (integer)
+        4.2. append_fromtag (integer)
+        4.3. enable_double_rr (integer)
+        4.4. add_username (integer)
+
+   5. Exported Functions
+
+        5.1. loose_route()
+        5.2. record_route() and record_route(string)
+        5.3. record_route_preset(string)
+        5.4. add_rr_param(param)
+        5.5. check_route_param(re)
+        5.6. is_direction(dir)
+
+1. Overview
 
    The module contains record routing logic
 
-1.2. Dialog support
-
-   Kamailio is basically only a transaction statefull proxy,
-   without any dialog support build in. There are many
-   features/services which actually requires a dialog awareness,
-   like storing the information in the dialog creation stage,
-   information which will be used during the whole dialog
-   existence.
-
-   The most urging example is NAT traversal, in dealing with the
-   within the dialog INVITEs (re-INVITEs). When processing the
-   initial INVITE, the proxy detects if the caller or callee is
-   behind some NAT and fixes the signalling and media parts -
-   since not all the detection mechanism are available for within
-   the dialog requests (like usrloc), to be able to fix
-   correspondingly the sequential requests, the proxy must
-   remember that the original request was NAT processed. There are
-   many other cases where dialog awareness fixes or helps.
-
-   The solution is to store additional dialog-related information
-   in the routing set (Record-Route/Route headers), headers which
-   show up in all sequential requests. So any information added to
-   the Record-Route header will be found (with no direction
-   dependencies) in Route header (corresponding to the proxy
-   address).
-
-   As storage container, the parameters of the Record-Route /
-   Route header will be used - Record-Route parameters mirroring
-   are reinforced by RFC 3261 (see 12.1.1 UAS behavior).
+2. Dialog support
+
+   Kamailio is basically only a transaction statefull proxy, without any
+   dialog support build in. There are many features/services which
+   actually requires a dialog awareness, like storing the information in
+   the dialog creation stage, information which will be used during the
+   whole dialog existence.
+
+   The most urging example is NAT traversal, in dealing with the within
+   the dialog INVITEs (re-INVITEs). When processing the initial INVITE,
+   the proxy detects if the caller or callee is behind some NAT and fixes
+   the signalling and media parts - since not all the detection mechanism
+   are available for within the dialog requests (like usrloc), to be able
+   to fix correspondingly the sequential requests, the proxy must remember
+   that the original request was NAT processed. There are many other cases
+   where dialog awareness fixes or helps.
+
+   The solution is to store additional dialog-related information in the
+   routing set (Record-Route/Route headers), headers which show up in all
+   sequential requests. So any information added to the Record-Route
+   header will be found (with no direction dependencies) in Route header
+   (corresponding to the proxy address).
+
+   As storage container, the parameters of the Record-Route / Route header
+   will be used - Record-Route parameters mirroring are reinforced by RFC
+   3261 (see 12.1.1 UAS behavior).
 
    For this purpose, the modules offers the following functions:
-     * add_rr_param() - see Section 1.5.4, " add_rr_param(param) "
-     * check_route_param() - see Section 1.5.5, "
-       check_route_param(re) "
+     * add_rr_param() - see Section 5.4, " add_rr_param(param) "
+     * check_route_param() - see Section 5.5, " check_route_param(re) "
 
    Example 1.1. Dialog support in RR module
-
 UAC                       Kamailio PROXY                          UAS
 
 ---- INVITE ------>       record_route()          ----- INVITE ---->
@@ -135,28 +154,35 @@ UAC                       Kamailio PROXY                          UAS
 <------ BYE -------        loose_route()          <----- BYE -------
                     check_route_param(";foo=true")
 
+3. Dependencies
 
-1.3. Dependencies
+   3.1. Kamailio Modules
+   3.2. External Libraries or Applications
 
-1.3.1. Kamailio Modules
+3.1. Kamailio Modules
 
    The following modules must be loaded before this module:
      * No dependencies on other Kamailio modules.
 
-1.3.2. External Libraries or Applications
+3.2. External Libraries or Applications
 
-   The following libraries or applications must be installed
-   before running Kamailio with this module loaded:
+   The following libraries or applications must be installed before
+   running Kamailio with this module loaded:
      * None.
 
-1.4. Exported Parameters
+4. Exported Parameters
+
+   4.1. enable_full_lr (integer)
+   4.2. append_fromtag (integer)
+   4.3. enable_double_rr (integer)
+   4.4. add_username (integer)
 
-1.4.1. enable_full_lr (integer)
+4.1. enable_full_lr (integer)
 
-   If set to 1 then ";lr=on" instead of just ";lr" will be used.
-   This is to overcome problems with broken UAs which strip ";lr"
-   parameter when generating Route header fields from Record-Route
-   (";lr=on" seems to help).
+   If set to 1 then ";lr=on" instead of just ";lr" will be used. This is
+   to overcome problems with broken UAs which strip ";lr" parameter when
+   generating Route header fields from Record-Route (";lr=on" seems to
+   help).
 
    Default value is 0 (no).
 
@@ -165,12 +191,12 @@ UAC                       Kamailio PROXY                          UAS
 modparam("rr", "enable_full_lr", 1)
 ...
 
-1.4.2. append_fromtag (integer)
+4.2. append_fromtag (integer)
 
-   If turned on, request's from-tag is appended to record-route;
-   that's useful for understanding whether subsequent requests
-   (such as BYE) come from caller (route's from-tag==BYE's
-   from-tag) or callee (route's from-tag==BYE's to-tag)
+   If turned on, request's from-tag is appended to record-route; that's
+   useful for understanding whether subsequent requests (such as BYE) come
+   from caller (route's from-tag==BYE's from-tag) or callee (route's
+   from-tag==BYE's to-tag)
 
    Default value is 1 (yes).
 
@@ -179,13 +205,13 @@ modparam("rr", "enable_full_lr", 1)
 modparam("rr", "append_fromtag", 0)
 ...
 
-1.4.3. enable_double_rr (integer)
+4.3. enable_double_rr (integer)
 
    There are some situations when the server needs to insert two
-   Record-Route header fields instead of one. For example when
-   using two disconnected networks or doing cross-protocol
-   forwarding from UDP->TCP. This parameter enables inserting of 2
-   Record-Routes. The server will later remove both of them.
+   Record-Route header fields instead of one. For example when using two
+   disconnected networks or doing cross-protocol forwarding from UDP->TCP.
+   This parameter enables inserting of 2 Record-Routes. The server will
+   later remove both of them.
 
    Default value is 1 (yes).
 
@@ -194,10 +220,10 @@ modparam("rr", "append_fromtag", 0)
 modparam("rr", "enable_double_rr", 0)
 ...
 
-1.4.4. add_username (integer)
+4.4. add_username (integer)
 
-   If set to a non 0 value (which means yes), the username part
-   will be also added in the Record-Route URI.
+   If set to a non 0 value (which means yes), the username part will be
+   also added in the Record-Route URI.
 
    Default value is 0 (no).
 
@@ -206,36 +232,41 @@ modparam("rr", "enable_double_rr", 0)
 modparam("rr", "add_username", 1)
 ...
 
-1.5. Exported Functions
+5. Exported Functions
 
-1.5.1.  loose_route()
+   5.1. loose_route()
+   5.2. record_route() and record_route(string)
+   5.3. record_route_preset(string)
+   5.4. add_rr_param(param)
+   5.5. check_route_param(re)
+   5.6. is_direction(dir)
 
-   The function performs routing of SIP requests which contain a
-   route set. The name is a little bit confusing, as this function
-   also routes requests which are in the "strict router" format.
+5.1. loose_route()
 
-   This function is usually used to route in-dialog requests (like
-   ACK, BYE, reINVITE). Nevertheless also out-of-dialog requests
-   can have a "pre-loaded route set" and my be routed with
-   loose_route. It also takes care of translating between
-   strict-routers and loose-router.
+   The function performs routing of SIP requests which contain a route
+   set. The name is a little bit confusing, as this function also routes
+   requests which are in the "strict router" format.
 
-   The loose_route function analyzes the Route: headers in the
-   requests. If there is no Route: header, the function returns
-   FALSE and routing should be done with normal lookup functions.
-   If a Route: header is found, the function returns 1 and behaves
-   as described in section 16.12 of RFC 3261. There is only one
-   exception: If the request is out-of-dialog (no to-tag) and
-   there is only one Route: header indicating the local proxy,
-   then the Route: header is removed and the function returns
-   FALSE.
+   This function is usually used to route in-dialog requests (like ACK,
+   BYE, reINVITE). Nevertheless also out-of-dialog requests can have a
+   "pre-loaded route set" and my be routed with loose_route. It also takes
+   care of translating between strict-routers and loose-router.
 
-   Make sure your loose_routing function can't be used by
-   attackers to bypass proxy authorization.
+   The loose_route function analyzes the Route: headers in the requests.
+   If there is no Route: header, the function returns FALSE and routing
+   should be done with normal lookup functions. If a Route: header is
+   found, the function returns 1 and behaves as described in section 16.12
+   of RFC 3261. There is only one exception: If the request is
+   out-of-dialog (no to-tag) and there is only one Route: header
+   indicating the local proxy, then the Route: header is removed and the
+   function returns FALSE.
 
-   The loose_routing topic is very complex. See the RFC3261 for
-   more details (grep for "route set" is a good starting point in
-   this comprehensive RFC).
+   Make sure your loose_routing function can't be used by attackers to
+   bypass proxy authorization.
+
+   The loose_routing topic is very complex. See the RFC3261 for more
+   details (grep for "route set" is a good starting point in this
+   comprehensive RFC).
 
    This function can be used from REQUEST_ROUTE.
 
@@ -244,16 +275,15 @@ modparam("rr", "add_username", 1)
 loose_route();
 ...
 
-1.5.2.  record_route() and record_route(string)
+5.2. record_route() and record_route(string)
 
-   The function adds a new Record-Route header field. The header
-   field will be inserted in the message before any other
-   Record-Route header fields.
+   The function adds a new Record-Route header field. The header field
+   will be inserted in the message before any other Record-Route header
+   fields.
 
-   If any string is passed as parameter, it will be appended as
-   URI parameter to the Record-Route header. The string must
-   follow the ";name=value" scheme and it may contain
-   pseudo-variables.
+   If any string is passed as parameter, it will be appended as URI
+   parameter to the Record-Route header. The string must follow the
+   ";name=value" scheme and it may contain pseudo-variables.
 
    This function can be used from REQUEST_ROUTE, BRANCH_ROUTE and
    FAILURE_ROUTE.
@@ -263,14 +293,14 @@ loose_route();
 record_route();
 ...
 
-1.5.3.  record_route_preset(string)
+5.3. record_route_preset(string)
 
-   This function will put the string into Record-Route, don't use
-   unless you know what you are doing.
+   This function will put the string into Record-Route, don't use unless
+   you know what you are doing.
 
    Meaning of the parameters is as follows:
-     * string - String to be inserted into the header field; it
-       may contain pseudo-variables.
+     * string - String to be inserted into the header field; it may
+       contain pseudo-variables.
 
    This function can be used from REQUEST_ROUTE, BRANCH_ROUTE and
    FAILURE_ROUTE.
@@ -280,17 +310,16 @@ record_route();
 record_route_preset("1.2.3.4:5090");
 ...
 
-1.5.4.  add_rr_param(param)
+5.4. add_rr_param(param)
 
    Adds a parameter to the Record-Route URI (param must be in
-   ";name=value" format. The function may be called also before or
-   after the record_route() call (see Section 1.5.2, "
-   record_route() and record_route(string) ").
+   ";name=value" format. The function may be called also before or after
+   the record_route() call (see Section 5.2, " record_route() and
+   record_route(string) ").
 
    Meaning of the parameters is as follows:
-     * param - String containing the URI parameter to be added. It
-       must follow the ";name=value" scheme; it may contain
-       pseudo-variables.
+     * param - String containing the URI parameter to be added. It must
+       follow the ";name=value" scheme; it may contain pseudo-variables.
 
    This function can be used from REQUEST_ROUTE, BRANCH_ROUTE and
    FAILURE_ROUTE.
@@ -300,16 +329,15 @@ record_route_preset("1.2.3.4:5090");
 add_rr_param(";nat=yes");
 ...
 
-1.5.5.  check_route_param(re)
+5.5. check_route_param(re)
 
-   The function checks if the URI parameters of the local Route
-   header (corresponding to the local server) matches the given
-   regular expression. It must be call after loose_route() (see
-   Section 1.5.1, " loose_route() ").
+   The function checks if the URI parameters of the local Route header
+   (corresponding to the local server) matches the given regular
+   expression. It must be call after loose_route() (see Section 5.1, "
+   loose_route() ").
 
    Meaning of the parameters is as follows:
-     * re - regular expression to check against the Route URI
-       parameters.
+     * re - regular expression to check against the Route URI parameters.
 
    This function can be used from REQUEST_ROUTE.
 
@@ -320,24 +348,23 @@ if (check_route_param("nat=yes")) {
 }
 ...
 
-1.5.6.  is_direction(dir)
+5.6. is_direction(dir)
 
-   The function checks the flow direction of the request. As for
-   checking it's used the "ftag" Route header parameter, the
-   append_fromtag (see Section 1.4.2, "append_fromtag (integer)"
-   module parameter must be enabled. Also this must be called only
-   after loose_route() (see Section 1.5.1, " loose_route() ").
+   The function checks the flow direction of the request. As for checking
+   it's used the "ftag" Route header parameter, the append_fromtag (see
+   Section 4.2, "append_fromtag (integer)" module parameter must be
+   enabled. Also this must be called only after loose_route() (see
+   Section 5.1, " loose_route() ").
 
-   The function returns true if the "dir" is the same with the
-   request's flow direction.
+   The function returns true if the "dir" is the same with the request's
+   flow direction.
 
-   The "downstream" (UAC to UAS) direction is relative to the
-   initial request that created the dialog.
+   The "downstream" (UAC to UAS) direction is relative to the initial
+   request that created the dialog.
 
    Meaning of the parameters is as follows:
-     * dir - string containing the direction to be checked. It may
-       be "upstream" (from UAS to UAC) or "downstream" (UAC to
-       UAS).
+     * dir - string containing the direction to be checked. It may be
+       "upstream" (from UAS to UAC) or "downstream" (UAC to UAS).
 
    This function can be used from REQUEST_ROUTE.
 
@@ -350,96 +377,110 @@ if (is_direction("upstream")) {
 
 Chapter 2. Developer Guide
 
-   The RR module provides an internal API to be used by other
-   Kamailio modules. The API offers support for SIP dialog based
-   functionalities - for more about the dialog support offered by
-   RR module, see Section 1.2, "Dialog support".
+   Table of Contents
+
+   1. Available Functions
+
+        1.1. add_rr_param( msg, param)
+        1.2. check_route_param( msg, re)
+        1.3. is_direction( msg, dir)
+        1.4. get_route_param( msg, name, val)
+        1.5. register_rrcb( callback, param)
 
-   For internal(non-script) usage, the RR module offers to other
-   module the possibility to register callback functions to be
-   executed each time a local Route header is processed. The
-   callback function will receive as parameter the register
-   parameter and the Route header parameter string.
+   2. Examples
 
-2.1. Available Functions
+   The RR module provides an internal API to be used by other Kamailio
+   modules. The API offers support for SIP dialog based functionalities -
+   for more about the dialog support offered by RR module, see Section 2,
+   "Dialog support".
 
-2.1.1.  add_rr_param( msg, param)
+   For internal(non-script) usage, the RR module offers to other module
+   the possibility to register callback functions to be executed each time
+   a local Route header is processed. The callback function will receive
+   as parameter the register parameter and the Route header parameter
+   string.
 
-   Adds a parameter to the requests's Record-Route URI (param must
-   be in ";name=value" format).
+1. Available Functions
+
+   1.1. add_rr_param( msg, param)
+   1.2. check_route_param( msg, re)
+   1.3. is_direction( msg, dir)
+   1.4. get_route_param( msg, name, val)
+   1.5. register_rrcb( callback, param)
+
+1.1. add_rr_param( msg, param)
+
+   Adds a parameter to the requests's Record-Route URI (param must be in
+   ";name=value" format).
 
    The function returns 0 on success. Otherwise, -1 is returned.
 
    Meaning of the parameters is as follows:
-     * struct sip_msg* msg - request that will has the parameter
-       "param" added to its Record-Route header.
-     * str* param - parameter to be added to the Record-Route
-       header - it must be in ";name=value" format.
+     * struct sip_msg* msg - request that will has the parameter "param"
+       added to its Record-Route header.
+     * str* param - parameter to be added to the Record-Route header - it
+       must be in ";name=value" format.
 
-2.1.2.  check_route_param( msg, re)
+1.2. check_route_param( msg, re)
 
-   The function checks for the request "msg" if the URI parameters
-   of the local Route header (corresponding to the local server)
-   matches the given regular expression "re". It must be call
-   after the loose_route was done.
+   The function checks for the request "msg" if the URI parameters of the
+   local Route header (corresponding to the local server) matches the
+   given regular expression "re". It must be call after the loose_route
+   was done.
 
    The function returns 0 on success. Otherwise, -1 is returned.
 
    Meaning of the parameters is as follows:
-     * struct sip_msg* msg - request that will has the Route
-       header parameters checked.
-     * regex_t* param - compiled regular expression to be checked
-       against the Route header parameters.
+     * struct sip_msg* msg - request that will has the Route header
+       parameters checked.
+     * regex_t* param - compiled regular expression to be checked against
+       the Route header parameters.
 
-2.1.3.  is_direction( msg, dir)
+1.3. is_direction( msg, dir)
 
-   The function checks the flow direction of the request "msg". As
-   for checking it's used the "ftag" Route header parameter, the
-   append_fromtag (see Section 1.4.2, "append_fromtag (integer)"
-   module parameter must be enables. Also this must be call only
-   after the loose_route is done.
+   The function checks the flow direction of the request "msg". As for
+   checking it's used the "ftag" Route header parameter, the
+   append_fromtag (see Section 4.2, "append_fromtag (integer)" module
+   parameter must be enables. Also this must be call only after the
+   loose_route is done.
 
-   The function returns 0 if the "dir" is the same with the
-   request's flow direction. Otherwise, -1 is returned.
+   The function returns 0 if the "dir" is the same with the request's flow
+   direction. Otherwise, -1 is returned.
 
    Meaning of the parameters is as follows:
-     * struct sip_msg* msg - request that will have the direction
-       checked.
+     * struct sip_msg* msg - request that will have the direction checked.
      * int dir - direction to be checked against. It may be
        "RR_FLOW_UPSTREAM" or "RR_FLOW_DOWNSTREAM".
 
-2.1.4.  get_route_param( msg, name, val)
+1.4. get_route_param( msg, name, val)
 
-   The function search in to the "msg"'s Route header parameters
-   the parameter called "name" and returns its value into "val".
-   It must be call only after the loose_route is done.
+   The function search in to the "msg"'s Route header parameters the
+   parameter called "name" and returns its value into "val". It must be
+   call only after the loose_route is done.
 
-   The function returns 0 if parameter was found (even if it has
-   no value). Otherwise, -1 is returned.
+   The function returns 0 if parameter was found (even if it has no
+   value). Otherwise, -1 is returned.
 
    Meaning of the parameters is as follows:
-     * struct sip_msg* msg - request that will have the Route
-       header parameter searched.
-     * str *name - contains the Route header parameter to be
-       serached.
-     * str *val - returns the value of the searched Route header
-       parameter if found. It might be empty string if the
-       parameter had no value.
+     * struct sip_msg* msg - request that will have the Route header
+       parameter searched.
+     * str *name - contains the Route header parameter to be serached.
+     * str *val - returns the value of the searched Route header parameter
+       if found. It might be empty string if the parameter had no value.
 
-2.1.5.  register_rrcb( callback, param)
+1.5. register_rrcb( callback, param)
 
-   The function register a new callback (along with its
-   parameter). The callback will be called when a loose route will
-   be performed for the local address.
+   The function register a new callback (along with its parameter). The
+   callback will be called when a loose route will be performed for the
+   local address.
 
    The function returns 0 on success. Otherwise, -1 is returned.
 
    Meaning of the parameters is as follows:
      * rr_cb_t callback - callback function to be registered.
-     * void *param - parameter to be passed to the callback
-       function.
+     * void *param - parameter to be passed to the callback function.
 
-2.2. Examples
+2. Examples
 
    Example 2.1. Loading RR module's API from another module
 ...

modules_k/rr/doc/rr_admin.xml

@@ -67,7 +67,7 @@
 		<title>Dialog support in RR module</title>
 		<programlisting format="linespecific">
   
-UAC                       Kamailio PROXY                          UAS
+UAC                       &kamailio; PROXY                          UAS
 
 ---- INVITE ------&gt;       record_route()          ----- INVITE ----&gt;
                      add_rr_param(";foo=true")

modules_k/seas/doc/seas_admin.xml

@@ -16,18 +16,18 @@
       <section>
         <title>Sip Express Application Server module overview</title>
 
-        <para><acronym>SEAS</acronym> module enables Kamailio to transfer the
+        <para><acronym>SEAS</acronym> module enables &kamailio; to transfer the
         execution logic control of a sip message to a given external entity,
-        called the Application Server. When the Kamailio script is being
+        called the Application Server. When the &kamailio; script is being
         executed on an incoming SIP message, invocation of the as_relay_t()
         function makes this module send the message along with some
         transaction information to the specified Application Server. The
         Application Server then executes some call-control logic code, and
-        tells Kamailio to take some actions, ie. forward the message
+        tells &kamailio; to take some actions, ie. forward the message
         downstream, or respond to the message with a SIP repy, etc.</para>
 
         <para>The module acts implements a network protocol acting as the
-        interface between Kamailio internal API and the external Application
+        interface between &kamailio; internal API and the external Application
         Server entity.</para>
 
         <para>There's only one relevant function, as_relay_t, exported by this
@@ -49,15 +49,15 @@
         information about the associated transaction (recall that invoking
         as_relay_t indirectly calls t_newtran). This way, all the
         SIP-Transaction machinery, and the SIP-Message parsing, is handled at
-        the Kamailio core, while the execution of the Application Logic is
+        the &kamailio; core, while the execution of the Application Logic is
         carried in the Application Server.</para>
 
         <para>The SEAS module and protocol provide a means by which an
-        external entity can utilize Kamailio as a transaction-stateful
+        external entity can utilize &kamailio; as a transaction-stateful
         SIP-stack to act on behalf of it. This means that this external entity
         (which we call the Application Server) is notified whenever a
-        SIP-Request enters Kamailio, and this external entity can then order
-        Kamailio to execute some actions, either replying the request, or
+        SIP-Request enters &kamailio;, and this external entity can then order
+        &kamailio; to execute some actions, either replying the request, or
         generating new UAC transactions.</para>
 
         <para>This version of SEAS works with VozTelecom's WeSIP Application
@@ -67,13 +67,13 @@
       <section id="ApplicationServer">
         <title>Application Servers</title>
 
-        <para>When Kamailio starts and SEAS module is loaded, a new process is
+        <para>When &kamailio; starts and SEAS module is loaded, a new process is
         spawn which listens on a server-socket (IP and port are specified as a
         parameter in the config script). From then on, the Application Servers
-        can connect to that socket so that Kamailio can relay messages to them.
+        can connect to that socket so that &kamailio; can relay messages to them.
         When an Application Server connects to the socket, it sends its name
         through the socket, so every App Server is identified with a name.
-        Within the Kamailio script, invoking as_relay_t() receives a string as
+        Within the &kamailio; script, invoking as_relay_t() receives a string as
         a parameter, which specifies the name of an application server to
         which the message has to be sent. If that concrete application server
         hasn't already connected to the module, the function returns a
@@ -85,7 +85,7 @@
         <title>Dependencies</title>
 
         <section>
-          <title>Kamailio Modules</title>
+          <title>&kamailio; Modules</title>
 
           <para>SEAS module relies on the Transaction Module (TM module) for
           operation.</para>
@@ -95,7 +95,7 @@
           <title>External Applications</title>
 
           <para>Using the SEAS module requires to have an Application Server
-          running and connected to a particular instance of Kamailio.</para>
+          running and connected to a particular instance of &kamailio;.</para>
 
           <para>At the moment, the only Application Server that works with
           SEAS is WeSIP Application Server, which can be downloaded from
@@ -116,7 +116,7 @@
           configured to connect to that port.</para>
 
           <para>In case this parameter is ommited, SEAS listens on the default
-          IP which Kamailio is using, and opens the ports 5080 and 5081 to
+          IP which &kamailio; is using, and opens the ports 5080 and 5081 to
           listen for Application Servers.</para>
 
           <example>
@@ -141,7 +141,7 @@ modparam("seas", "listen_sockets","127.0.0.1:5080")
           <para>Creates a new transaction (if it isn't already created) and
           sends the SIP Request and transaction information to the Application
           Server specified in the parameter. Every Application Server
-          connected to Kamailio through the SEAS module, must be identified
+          connected to &kamailio; through the SEAS module, must be identified
           with a different name.</para>
 
           <para>This function can be used within REQUEST_ROUTE.</para>
@@ -162,14 +162,14 @@ t_reply("500","App Server not connected");
           <section>
             <title>Return value</title>
 
-            <para>In case the Application Server is connected to Kamailio, the
+            <para>In case the Application Server is connected to &kamailio;, the
             function does _not_ return, the Application Server is now in
             charge of processing the request, and it may then reply to the
             request, initiate new transactions, or whatever the application
             being executed wants.</para>
 
             <para>In case the Application Server identified by the string
-            parameter passed to as_relay_t() is not connected to Kamailio, the
+            parameter passed to as_relay_t() is not connected to &kamailio;, the
             function returns 0, so that the script can continue processing the
             request.</para>
           </section>
@@ -480,13 +480,13 @@ ServletException, IOException
 
           <para>Specifies the SIP address and port in which the Application
           Server from which the Application Server will process the SIP
-          messages. This Addres is where Kamailio listens for the messages, so
-          in fact, Kamailio is listening on them, but Kamailio passes the
+          messages. This Addres is where &kamailio; listens for the messages, so
+          in fact, &kamailio; is listening on them, but &kamailio; passes the
           messages to WeSIP, so WeSIP must be aware of this IP/port.</para>
 
           <warning>
             <para>this attribute MUST match one of the listening points
-            declared within Kamailio in the "listen" parameters.</para>
+            declared within &kamailio; in the "listen" parameters.</para>
 
             <para>For example in &kamailioconfig;:<programlisting>listen = tcp:localhost:5060
 listen = udp:localhost:5060</programlisting></para>
@@ -502,15 +502,15 @@ listen = udp:localhost:5060</programlisting></para>
             <listitem>
               <para>com.voztele.javax.sip.SER_ADDRESS</para>
 
-              <para>This specifies the IP and port in which the Kamailio is
+              <para>This specifies the IP and port in which the &kamailio; is
               listening for Application Servers to connect and register.This
-              specifies the IP and port in which the Kamailio is listening for
+              specifies the IP and port in which the &kamailio; is listening for
               Application Servers to connect and register.</para>
 
               <para><warning>
                   <para>This needs to match the
                   <varname>listen_sockets</varname> seas module parameter
-                  within the Kamailio configuration file. Ie.:</para>
+                  within the &kamailio; configuration file. Ie.:</para>
 
                   <para><programlisting>modparam("seas", "listen_sockets","127.0.0.1:5080") </programlisting></para>
                 </warning></para>
@@ -523,13 +523,13 @@ listen = udp:localhost:5060</programlisting></para>
               Application Server.</para>
 
               <para><warning>
-                  <para>This is the name you will set in the Kamailio
+                  <para>This is the name you will set in the &kamailio;
                   configuration script when you invoke the WeSIP Application
                   Server, by calling the as_relay_t function. This is the name
                   you pass as the parameter of the function. If you have
                   different WeSIP instances all connecting to the same
-                  Kamailio, they must each one have a different STACK_NAME",
-                  and within Kamailio you can call each of them by invoking
+                  &kamailio;, they must each one have a different STACK_NAME",
+                  and within &kamailio; you can call each of them by invoking
                   as_relay_t() with a different name. Example:</para>
 
                   <para><programlisting>&lt;Property key="javax.sip.STACK_NAME" value="app_server_one" /&gt;</programlisting></para>
@@ -551,7 +551,7 @@ listen = udp:localhost:5060</programlisting></para>
               and UAC transaction generated from WeSIP, must spiral through
               SER, and will be added a special Header called "X-WeSIP-SPIRAL:
               true" this will make all the outgoing messages pass again
-              through the Kamailio script, so that they can be accounted or
+              through the &kamailio; script, so that they can be accounted or
               whatever the configurator wants. For example, the configuration
               script could go:</para>
 
@@ -629,7 +629,7 @@ listen = udp:localhost:5060</programlisting></para>
           this way. Every host must have a "name" attribute which specifies
           the name of the virtual host, it must also have a "nameSip"
           attribute which MUST MATCH the IP or hostname _and_ port" specified
-          in Kamailio listen parameters and in the Sip Connector the hostname
+          in &kamailio; listen parameters and in the Sip Connector the hostname
           and the port must be separated with an underscore. for example:
           nameSip="localhost_5060" or nameSip="192.168.1.1_5060" The next
           important attribute that must have the Host element is "appBase"
@@ -641,7 +641,7 @@ listen = udp:localhost:5060</programlisting></para>
           should usually be set to "true". The "port" attribute specifies the
           port where this host is going to receive SIP messages . This only
           has to do with the SIP protocol, not with HTTP. It must be the same
-          as the port specified in Kamailio parameter "listen_sockets" (for the
+          as the port specified in &kamailio; parameter "listen_sockets" (for the
           seas module). The "autoDeploy" attribute tells the host to monitor
           the "appBase" directory for new application archives (.sar or .war)
           so they can automatically be deployed. This parameter should be set
@@ -664,16 +664,16 @@ listen = udp:localhost:5060</programlisting></para>
       <section>
         <title>Configuration Examples</title>
 
-        <para>In general, you can configure WeSIP to work with your Kamailio in
-        two ways: have 2 Kamailio instances, the first acting as
+        <para>In general, you can configure WeSIP to work with your &kamailio; in
+        two ways: have 2 &kamailio; instances, the first acting as
         Proxy/Registrar/Redirect and the second cooperating with WeSIP to act
         as the Application Server. This is the preferred deployment layout, as
-        the first Kamailio works as usual, and the requests that need special
-        services are relaied to another Kamailio which acts on behalf of the
+        the first &kamailio; works as usual, and the requests that need special
+        services are relaied to another &kamailio; which acts on behalf of the
         WeSIP AS. This configuration profile distributes load (call-routing
         logic in one instance, and Application Services in the other), and is
         also more fault-tolerant. On the other hand, you can have all your
-        call-routing logic and Application Server on the same Kamailio, having
+        call-routing logic and Application Server on the same &kamailio;, having
         one script handle all the logic, and then invoking the App Server at
         any point.</para>
 

modules_k/seas/doc/seas_devel.xml

@@ -16,7 +16,7 @@
       <title>Internals</title>
 
       <para>The SEAS module runs within the Open Sip Express Router aka.
-      Kamailio. Kamailio uses a pool of processes to execute the script logic on
+      &kamailio;. &kamailio; uses a pool of processes to execute the script logic on
       every new message received. These are called the worker processes. One
       of these processes will be selected to process the script, and at some
       point it will find a function invoking the relay of the SIP message to
@@ -31,25 +31,25 @@
       message being handled, put it in a shared memory segment, and write the
       address of that segment to a pipe (4 bytes pointer in IA32).</para>
 
-      <para>This way, we will have all the Kamailio processes composing the
+      <para>This way, we will have all the &kamailio; processes composing the
       SEAS header along with the SIP message, and putting its shared memory
       address into that pipe. This technique of inter-process communication
       avoids race conditions because writing to a pipe is granted to be an
       atomic operation if the data to write is less than _POSIX_PIPE_BUF,
       which usually is 512 bytes.</para>
 
-      <para>At the initialization of Kamailio, the SEAS module creates the
-      discussed pipe, so that all the Kamailio worker processes inherit the
+      <para>At the initialization of &kamailio;, the SEAS module creates the
+      discussed pipe, so that all the &kamailio; worker processes inherit the
       file descriptor associated to the pipe. Then it spawns a new process,
       which will be the one to open two server sockets, and wait for the
       Application Servers to connect and register.</para>
 
-      <para>Each Application Server wishing to receive events from Kamailio,
+      <para>Each Application Server wishing to receive events from &kamailio;,
       will have to open a socket to the module (the port and IP of the socket
       are defined at start time in the script). After connection, it has to
       print its identification name. The SEAS process (from now on, called
       event dispatcher) will then register it in its internal structures, so
-      that the Kamailio processes can push events for it. The following
+      that the &kamailio; processes can push events for it. The following
       picture, shows the internals of the SEAS Event dispatcher
       process:</para>
 
@@ -89,9 +89,9 @@
       efficiently, because parsing of text headers requires a lot of
       state.</para>
 
-      <para>Kamailio implements a very efficient parsing mechanism and
+      <para>&kamailio; implements a very efficient parsing mechanism and
       SIP-transaction machinery. The goal of the SEAS protocol is to keep all
-      this information that has been already extracted at Kamailio, so that it
+      this information that has been already extracted at &kamailio;, so that it
       can be reused at the Application Server.</para>
 
       <section>
@@ -100,15 +100,15 @@
         <para>The SEAS protocol is a layer of information regarding the
         internal structure of a SIP message that is added whenever SEAS sends
         a SIP event to the Application Servers. The protocol is used for
-        communication between Kamailio and the Application Servers.</para>
+        communication between &kamailio; and the Application Servers.</para>
 
         <para>Once an incoming SIP message has reached the worker process
-        within Kamailio, it copies its content into a private memory area
+        within &kamailio;, it copies its content into a private memory area
         (which is, a memory chunk not shared across processes). In this point,
         the message first line is parsed to know whether it is a SIP request
         or response.</para>
 
-        <para>Kamailio uses a technique called lazy-parsing, which consists in
+        <para>&kamailio; uses a technique called lazy-parsing, which consists in
         delaying the parse of headers until some piece of the code requires
         it.</para>
 
@@ -141,17 +141,17 @@
         meta-information regarding the SIP message structure, is stored in a
         sip_msg structure, using dynamically-allocated memory segments.</para>
 
-        <para>Kamailio defines different structure types describing different
+        <para>&kamailio; defines different structure types describing different
         SIP headers, such as via_body, to_body, cseq_body, via_param, and so
         on. These structures are generally composed of another kind of
         structure called str.</para>
 
-        <para>The str structure is a key component of Kamailio's high
+        <para>The str structure is a key component of &kamailio;'s high
         performance. In the C programming language, a string's length is known
         because a '0' (null-character) is found at the end of it. This forces
         each of the string manipulation functions to keep looking for a '0' in
         the byte stream, which is quite processor consuming. Instead of this,
-        Kamailio defines a structure composed of a char pointer and an integer.
+        &kamailio; defines a structure composed of a char pointer and an integer.
         The char points to the start of a string, and the integer gives its
         length, thus avoiding the '0' lookup problem, and giving a significant
         performance boost.</para>
@@ -168,7 +168,7 @@
         been casted to an unsigned byte (256 values, so 256 characters maximum
         length).</para>
 
-        <para>When messages get transferred from Kamailio to the Application
+        <para>When messages get transferred from &kamailio; to the Application
         Server, it is optimum to keep this worthy meta-information regarding
         the SIP message, so that it can be used at the AS part. For this to be
         possible, it is needed to store the pointers to each of the syntactic

modules_k/siptrace/doc/siptrace_admin.xml

@@ -23,7 +23,7 @@
 		<itemizedlist>
 		<listitem>
 		<para>
-		by calling explicitely the sip_trace() method in Kamailio configuration
+		by calling explicitely the sip_trace() method in &kamailio; configuration
 		file. In this case the original message is processed.
 		</para>
 		</listitem>

modules_k/snmpstats/doc/snmpstats_faq.xml

@@ -67,7 +67,7 @@
     modparam("snmpstats", "dlg_minor_threshold", 600)
 		</programlisting>
 		<para>
-		Then either Kamailio is not reaching these thresholds (which is a good thing),
+		Then either &kamailio; is not reaching these thresholds (which is a good thing),
 		or you haven't set up the trap monitor correctly.  To prove this to yourself,
 		you can start NetSNMP with:
 		</para>
@@ -119,7 +119,7 @@
 	</qandaentry>
 	<qandaentry>
 	    <question>
-		<para>Kamailio refuses to load the SNMPStats module.  Why is it displaying "load_module: could not open module snmpstats.so"?
+		<para>&kamailio; refuses to load the SNMPStats module.  Why is it displaying "load_module: could not open module snmpstats.so"?
 		</para>
 	    </question>
 	    <answer>
@@ -189,7 +189,7 @@
 			</listitem>
 			<listitem>
 				<para>
-				Try starting Kamailio again.
+				Try starting &kamailio; again.
 				</para>
 			</listitem>
 		</orderedlist>
@@ -280,7 +280,7 @@
     		</programlisting>
 
 		For example, consider an snmpget on the openserSIPEntityType scalar, 
-		run on the same machine running the Kamailio instance, with the default
+		run on the same machine running the &kamailio; instance, with the default
 		"public" community string.  The command would be:
 
 		<programlisting format="linespecific">
@@ -311,7 +311,7 @@
     		</programlisting>
 
 		For example, consider the openserSIPRegUserTable.  If we run the snmptable
-		command on the same machine as the running Kamailio instance, configured with
+		command on the same machine as the running &kamailio; instance, configured with
 		the default "public" community string.  The command would be:
 
 		<programlisting format="linespecific">

modules_k/speeddial/README

@@ -12,38 +12,37 @@ Elena-Ramona Modroiu
 
    Copyright © 2004 voice-system.ro
    Revision History
-   Revision $Revision$ $Date: 2008-08-06 12:08:33 +0200
-                              (Mi, 06 Aug 2008) $
-     __________________________________________________________
+   Revision $Revision$ $Date$
+     __________________________________________________________________
 
    Table of Contents
 
    1. Admin Guide
 
-        1.1. Overview
-        1.2. Dependencies
+        1. Overview
+        2. Dependencies
 
-              1.2.1. Kamailio Modules
-              1.2.2. External Libraries or Applications
+              2.1. Kamailio Modules
+              2.2. External Libraries or Applications
 
-        1.3. Exported Parameters
+        3. Exported Parameters
 
-              1.3.1. db_url (string)
-              1.3.2. user_column (string)
-              1.3.3. domain_column (string)
-              1.3.4. sd_user_column (string)
-              1.3.5. sd_domain_column (string)
-              1.3.6. new_uri_column (string)
-              1.3.7. domain_prefix (string)
-              1.3.8. use_domain (int)
+              3.1. db_url (string)
+              3.2. user_column (string)
+              3.3. domain_column (string)
+              3.4. sd_user_column (string)
+              3.5. sd_domain_column (string)
+              3.6. new_uri_column (string)
+              3.7. domain_prefix (string)
+              3.8. use_domain (int)
 
-        1.4. Exported Functions
+        4. Exported Functions
 
-              1.4.1. sd_lookup(table [, owner])
+              4.1. sd_lookup(table [, owner])
 
-        1.5. Installation and Running
+        5. Installation and Running
 
-              1.5.1. Kamailio config file
+              5.1. Kamailio config file
 
    List of Examples
 
@@ -60,33 +59,70 @@ Elena-Ramona Modroiu
 
 Chapter 1. Admin Guide
 
-1.1. Overview
+   Table of Contents
+
+   1. Overview
+   2. Dependencies
+
+        2.1. Kamailio Modules
+        2.2. External Libraries or Applications
+
+   3. Exported Parameters
+
+        3.1. db_url (string)
+        3.2. user_column (string)
+        3.3. domain_column (string)
+        3.4. sd_user_column (string)
+        3.5. sd_domain_column (string)
+        3.6. new_uri_column (string)
+        3.7. domain_prefix (string)
+        3.8. use_domain (int)
+
+   4. Exported Functions
+
+        4.1. sd_lookup(table [, owner])
 
-   This module provides on-server speed dial facilities. An user
-   can store records consisting of pairs short numbers (2 digits)
-   and SIP addresses into a table of Kamailio. Then it can dial
-   the two digits whenever it wants to call the SIP address
-   associated with them.
+   5. Installation and Running
 
-1.2. Dependencies
+        5.1. Kamailio config file
 
-1.2.1. Kamailio Modules
+1. Overview
+
+   This module provides on-server speed dial facilities. An user can store
+   records consisting of pairs short numbers (2 digits) and SIP addresses
+   into a table of Kamailio. Then it can dial the two digits whenever it
+   wants to call the SIP address associated with them.
+
+2. Dependencies
+
+   2.1. Kamailio Modules
+   2.2. External Libraries or Applications
+
+2.1. Kamailio Modules
 
    The following modules must be loaded before this module:
      * database module (mysql, dbtext, ...).
 
-1.2.2. External Libraries or Applications
+2.2. External Libraries or Applications
 
-   The following libraries or applications must be installed
-   before running Kamailio with this module loaded:
+   The following libraries or applications must be installed before
+   running Kamailio with this module loaded:
      * None.
 
-1.3. Exported Parameters
+3. Exported Parameters
 
-1.3.1. db_url (string)
+   3.1. db_url (string)
+   3.2. user_column (string)
+   3.3. domain_column (string)
+   3.4. sd_user_column (string)
+   3.5. sd_domain_column (string)
+   3.6. new_uri_column (string)
+   3.7. domain_prefix (string)
+   3.8. use_domain (int)
 
-   The URL of database where the table containing speed dial
-   records.
+3.1. db_url (string)
+
+   The URL of database where the table containing speed dial records.
 
    Default value is DEFAULT_RODB_URL.
 
@@ -95,10 +131,10 @@ Chapter 1. Admin Guide
 modparam("speeddial", "db_url", "mysql://openser:xxx@localhost/openser")
 ...
 
-1.3.2. user_column (string)
+3.2. user_column (string)
 
-   The name of column storing the user name of the owner of the
-   speed dial record.
+   The name of column storing the user name of the owner of the speed dial
+   record.
 
    Default value is "username".
 
@@ -107,10 +143,10 @@ modparam("speeddial", "db_url", "mysql://openser:xxx@localhost/openser")
 modparam("speeddial", "user_column", "userid")
 ...
 
-1.3.3. domain_column (string)
+3.3. domain_column (string)
 
-   The name of column storing the domain of the owner of the speed
-   dial record.
+   The name of column storing the domain of the owner of the speed dial
+   record.
 
    Default value is "domain".
 
@@ -119,10 +155,9 @@ modparam("speeddial", "user_column", "userid")
 modparam("speeddial", "domain_column", "userdomain")
 ...
 
-1.3.4. sd_user_column (string)
+3.4. sd_user_column (string)
 
-   The name of the column storing the user part of the short dial
-   address.
+   The name of the column storing the user part of the short dial address.
 
    Default value is "sd_username".
 
@@ -131,10 +166,9 @@ modparam("speeddial", "domain_column", "userdomain")
 modparam("speeddial", "sd_user_column", "short_user")
 ...
 
-1.3.5. sd_domain_column (string)
+3.5. sd_domain_column (string)
 
-   The name of the column storing the domain of the short dial
-   address.
+   The name of the column storing the domain of the short dial address.
 
    Default value is "sd_domain".
 
@@ -143,10 +177,10 @@ modparam("speeddial", "sd_user_column", "short_user")
 modparam("speeddial", "sd_domain_column", "short_domain")
 ...
 
-1.3.6. new_uri_column (string)
+3.6. new_uri_column (string)
 
-   The name of the column containing the URI that will be use to
-   replace the short dial URI.
+   The name of the column containing the URI that will be use to replace
+   the short dial URI.
 
    Default value is "new_uri".
 
@@ -155,11 +189,11 @@ modparam("speeddial", "sd_domain_column", "short_domain")
 modparam("speeddial", "new_uri_column", "real_uri")
 ...
 
-1.3.7. domain_prefix (string)
+3.7. domain_prefix (string)
 
-   If the domain of the owner (From URI) starts with the value of
-   this parameter, then it is stripped before performing the
-   lookup of the short number.
+   If the domain of the owner (From URI) starts with the value of this
+   parameter, then it is stripped before performing the lookup of the
+   short number.
 
    Default value is NULL.
 
@@ -168,12 +202,11 @@ modparam("speeddial", "new_uri_column", "real_uri")
 modparam("speeddial", "domain_prefix", "tel.")
 ...
 
-1.3.8. use_domain (int)
+3.8. use_domain (int)
 
-   The parameter specifies wheter or not to use the domain when
-   searching a speed dial record (0 - no domain, 1 - use domain
-   from From URI, 2 - use both domains, from From URI and from
-   request URI).
+   The parameter specifies wheter or not to use the domain when searching
+   a speed dial record (0 - no domain, 1 - use domain from From URI, 2 -
+   use both domains, from From URI and from request URI).
 
    Default value is 0.
 
@@ -182,18 +215,19 @@ modparam("speeddial", "domain_prefix", "tel.")
 modparam("speeddial", "use_domain", 1)
 ...
 
-1.4. Exported Functions
+4. Exported Functions
+
+   4.1. sd_lookup(table [, owner])
 
-1.4.1.  sd_lookup(table [, owner])
+4.1. sd_lookup(table [, owner])
 
-   The function lookups the short dial number from R-URI in
-   'table' and replaces the R-URI with associated address.
+   The function lookups the short dial number from R-URI in 'table' and
+   replaces the R-URI with associated address.
 
    Meaning of the parameters is as follows:
-     * table - The name of the table storing the speed dial
-       records.
-     * owner - The SIP URI of the owner of short dialing codes. If
-       not pressent, URI of From header is used.
+     * table - The name of the table storing the speed dial records.
+     * owner - The SIP URI of the owner of short dialing codes. If not
+       pressent, URI of From header is used.
 
    This function can be used from REQUEST_ROUTE.
 
@@ -207,9 +241,11 @@ if(uri=~"sip:[0-9]{2}@.*")
         sd_lookup("speed_dial", "sip:$au@$fd");
 ...
 
-1.5. Installation and Running
+5. Installation and Running
+
+   5.1. Kamailio config file
 
-1.5.1. Kamailio config file
+5.1. Kamailio config file
 
    Next picture displays a sample usage of speeddial.
 

modules_k/speeddial/doc/speeddial_admin.xml

@@ -18,7 +18,7 @@
 	<para>
 		This module provides on-server speed dial facilities. An user can store
 		records consisting of pairs short numbers (2 digits) and SIP addresses
-		into a table of Kamailio. Then it can dial the two digits whenever it
+		into a table of &kamailio;. Then it can dial the two digits whenever it
 		wants to call the SIP address associated with them.
 	</para>
 	</section>

modules_k/textops/doc/textops_admin.xml

@@ -17,7 +17,7 @@
 	<title>Overview</title>
 	<para>
 		The module implements text based operations over the SIP message
-		processed by Kamailio. SIP is a text based protocol and the module
+		processed by &kamailio;. SIP is a text based protocol and the module
 		provides a large set of very useful functions to manipulate the
 		message at text level, e.g., regular expression search and replace,
 		Perl-like substitutions, checks for method type, header presence,
@@ -218,7 +218,7 @@ search_append_body("[Oo]pen[Ss]er", " SIP Proxy");
 		<title><function>replace</function> usage</title>
 		<programlisting format="linespecific">
 ...
-replace("openser", "Kamailio SIP Proxy");
+replace("openser", "&kamailio; SIP Proxy");
 ...
 </programlisting>
 		</example>
@@ -251,7 +251,7 @@ replace("openser", "Kamailio SIP Proxy");
 		<title><function>replace_body</function> usage</title>
 		<programlisting format="linespecific">
 ...
-replace_body("openser", "Kamailio SIP Proxy");
+replace_body("openser", "&kamailio; SIP Proxy");
 ...
 </programlisting>
 		</example>
@@ -283,7 +283,7 @@ replace_body("openser", "Kamailio SIP Proxy");
 		<title><function>replace_all</function> usage</title>
 		<programlisting format="linespecific">
 ...
-replace_all("openser", "Kamailio SIP Proxy");
+replace_all("openser", "&kamailio; SIP Proxy");
 ...
 </programlisting>
 		</example>
@@ -316,7 +316,7 @@ replace_all("openser", "Kamailio SIP Proxy");
 		<title><function>replace_body_all</function> usage</title>
 		<programlisting format="linespecific">
 ...
-replace_body_all("openser", "Kamailio SIP Proxy");
+replace_body_all("openser", "&kamailio; SIP Proxy");
 ...
 </programlisting>
 		</example>

modules_k/tmx/README

@@ -117,7 +117,7 @@ Chapter 1. Admin Guide
 
    3.1. t_cancel_branches(which)
 
-3.1.  t_cancel_branches(which)
+3.1. t_cancel_branches(which)
 
    Cancel branches of an active SIP transaction. The function can be
    called for a SIP reply that will identify the current branch.
@@ -153,7 +153,7 @@ if (t_cancel_branches("all")) {
    5.3. t_hash
    5.4. t_reply
 
-5.1.  t_uac_dlg
+5.1. t_uac_dlg
 
    Generates and sends a local SIP request.
 
@@ -168,7 +168,7 @@ if (t_cancel_branches("all")) {
      * body - (optional, may not be present) request body (if present,
        requires the "Content-Type" and "Content-length" headers)
 
-5.2.  t_uac_cancel
+5.2. t_uac_cancel
 
    Generates and sends a CANCEL for an existing local SIP request.
 
@@ -176,14 +176,14 @@ if (t_cancel_branches("all")) {
      * callid - callid of the INVITE request to be cancelled.
      * cseq - cseq of the INVITE request to be cancelled.
 
-5.3.  t_hash
+5.3. t_hash
 
    Gets information about the load of TM internal hash table.
 
    Parameters:
      * none
 
-5.4.  t_reply
+5.4. t_reply
 
    Generates and sends a reply for an existing inbound SIP transaction.
 

modules_k/tmx/doc/tmx_admin.xml

@@ -16,10 +16,10 @@
 	<section>
 	<title>Overview</title>
 	<para>
-	This module collects extensions from Kamailio TM module.
+	This module collects extensions from &kamailio; TM module.
 	</para>
 	<para>
-	Kamailio TM (Transaction Management) module documentation is available at:
+	&kamailio; TM (Transaction Management) module documentation is available at:
 	<ulink url="http://www.kamailio.org/docs/modules/1.5.x/tm.html">
 	http://www.kamailio.org/docs/modules/1.5.x/tm.html</ulink>
 	</para>

modules_k/userblacklist/README

@@ -187,7 +187,7 @@ modparam("userblacklist", "use_domain", 0)
 
    4.3. check_blacklist (string table)
 
-4.1.  check_user_blacklist (string user, string domain, string number, string
+4.1. check_user_blacklist (string user, string domain, string number, string
 table)
 
    Finds the longest prefix that matches the request URI user (or the
@@ -208,7 +208,7 @@ if (!check_user_blacklist("$avp(i:80)", "$avp(i:82)"))
 }
 ...
 
-4.2.  check_user_whitelist (string user, string domain, string number, string
+4.2. check_user_whitelist (string user, string domain, string number, string
 table)
 
    Finds the longest prefix that matches the request URI user (or the
@@ -229,7 +229,7 @@ if (!check_user_whitelist("$avp(i:80)", "$avp(i:82)"))
 }
 ...
 
-4.3.  check_blacklist (string table)
+4.3. check_blacklist (string table)
 
    Finds the longest prefix that matches the request URI for the given
    table. If a match is found and it is not set to whitelist, false is
@@ -247,7 +247,7 @@ if (!check_blacklist("global_blacklist")))
 
    5.1. reload_blacklist
 
-5.1.  reload_blacklist
+5.1. reload_blacklist
 
    Reload the internal global blacklist cache. This is necessary after the
    database tables for the global blacklist have been changed.

modules_k/userblacklist/doc/userblacklist_admin.xml

@@ -13,7 +13,7 @@
 	<section>
 	<title>Overview</title>
 	<para>
-	The userblacklist module allows Kamailio to handle blacklists
+	The userblacklist module allows &kamailio; to handle blacklists
 	on a per user basis. This information is stored in a database
 	table, which is queried to decide if the number (more exactly,
 	the request URI user) is blacklisted or not.

modules_k/xcap_client/doc/xcap_client_admin.xml

@@ -16,7 +16,7 @@
 	<section>
 	<title>Overview</title>
 	<para> 
-	The modules is an XCAP client for Kamailio that can be used by other modules.
+	The modules is an XCAP client for &kamailio; that can be used by other modules.
 	It fetches XCAP elements, either documents or part of them, by sending 
 	HTTP GET requests. It also offers support for conditional queries.
 	It uses libcurl library as a client-side HTTP transfer library.

modules_k/xlog/README

@@ -157,7 +157,7 @@ modparam("xlog", "prefix", "-xlog: ")
    5.1. xlog([level,] format)
    5.2. xdbg(format)
 
-5.1.  xlog([level,] format)
+5.1. xlog([level,] format)
 
    Print a formated message using LOG function.
 
@@ -191,7 +191,7 @@ $var(loglevel) = 2;
 xlog("$var(loglevel)", "time [$Tf] method ($rm) r-uri ($ru)\n");
 ...
 
-5.2.  xdbg(format)
+5.2. xdbg(format)
 
    Print a formatted message using DBG function.
 

modules_k/xlog/doc/xlog_admin.xml

@@ -32,7 +32,7 @@
 	in the function avp_printf())
 	</para>
 	<para>
-	The most important changes from earlier versions of Kamailio are:
+	The most important changes from earlier versions of &kamailio; are:
 	</para>
 	<itemizedlist>
 		<listitem>

modules_k/xmpp/doc/xmpp_admin.xml

@@ -15,21 +15,21 @@
 	
 	<section>
 	<title>Overview</title>
-	<para>	This module is a gateway between Kamailio and a XMPP/Jabber server. It enables the exchange of instant messages between
+	<para>	This module is a gateway between &kamailio; and a XMPP/Jabber server. It enables the exchange of instant messages between
 		SIP clients and XMPP(jabber) clients. </para>
 	<para>	The module can be used in two different modes:</para>
 
 	<itemizedlist>
 		<listitem>
-			<para>	<emphasis role='bold'>XMPP Component Mode</emphasis>. In this mode, Kamailio connects to an XMPP server using the standardized XMPP component interface, extending your XMPP services. The connection is done over TCP/IP with authorization.</para>
+			<para>	<emphasis role='bold'>XMPP Component Mode</emphasis>. In this mode, &kamailio; connects to an XMPP server using the standardized XMPP component interface, extending your XMPP services. The connection is done over TCP/IP with authorization.</para>
 		</listitem>
 		<listitem>
-			<para><emphasis role='bold'>XMPP Server</emphasis>. In this mode, the Kamailio XMPP module is a stand-alone XMPP server, with no requirement for another XMPP server in the system. This server uses XMPP S2S (Server to Server) connections to connect to other XMPP servers or receive connections from other servers. NOTE: this is limited implementation of a XMPP server, it does not support SRV or TLS so far. This mode is in beta stage for the moment.</para>
+			<para><emphasis role='bold'>XMPP Server</emphasis>. In this mode, the &kamailio; XMPP module is a stand-alone XMPP server, with no requirement for another XMPP server in the system. This server uses XMPP S2S (Server to Server) connections to connect to other XMPP servers or receive connections from other servers. NOTE: this is limited implementation of a XMPP server, it does not support SRV or TLS so far. This mode is in beta stage for the moment.</para>
 		</listitem>
 	</itemizedlist>
 	<para>	In the component mode, you need a local XMPP server (recommended Jabberd2). The XMPP module will connect by using TCP/IP connection to the local jabber server. The documentation and the source for Jabberd server are located at the following link:
 <ulink url="http://jabberd.jabberstudio.org/2/#download">http://jabberd.jabberstudio.org/2/#download</ulink>	</para>
-	<para> After you have a running XMPP server, what you need to do is set the following parameters in the Kamailio configuration file:</para>
+	<para> After you have a running XMPP server, what you need to do is set the following parameters in the &kamailio; configuration file:</para>
 	<itemizedlist>
 		<listitem>
 			<para>gateway_domain, xmpp_domain (which can be the same as gateway_domain) and xmpp_host, which are explained in the Exported Parameters section;
@@ -39,7 +39,7 @@
 			<para>listen = your ip;</para>
 		</listitem> 
 		<listitem>
-			<para>alias=Kamailio SIP domain and alias=gateway domain;</para>
+			<para>alias=&kamailio; SIP domain and alias=gateway domain;</para>
 		</listitem>
 		<listitem>
 			<para>in the following section of the configuration file, change to your gateway domain:</para>
@@ -58,7 +58,7 @@
 	<para>	A use case, for the component-mode, would look like this:</para>
 	<itemizedlist>
 		<listitem>
-			<para>Kamailio is hosting the sip-server.kamailio.org SIP domain</para>
+			<para>&kamailio; is hosting the sip-server.kamailio.org SIP domain</para>
 		</listitem>
 		<listitem>
 			<para>The gateway SIP domain is sip-xmpp.kamailio.org</para>
@@ -76,7 +76,7 @@
 	<para>	A use case, for the server-mode, would look like this: </para>
 	<itemizedlist>
 		<listitem>
-			<para>Kamailio is hosting the SIP domain sip-server.kamailio.org </para>
+			<para>&kamailio; is hosting the SIP domain sip-server.kamailio.org </para>
 		</listitem>
 		<listitem>
 			<para>The gateway is hosting the SIP domain sip-xmpp.kamailio.org;</para>
@@ -279,8 +279,8 @@
 		<title><varname>outbound_proxy</varname> (string)</title>
 		<para>
 		The SIP address used as next hop when sending the message. Very
-		useful when using Kamailio with a domain name not in DNS, or
-		when using a separate Kamailio instance for XMPP processing. If
+		useful when using &kamailio; with a domain name not in DNS, or
+		when using a separate &kamailio; instance for XMPP processing. If
 		not set, the message will be sent to the address in destination
 		URI.
 		</para>
@@ -326,7 +326,7 @@ xmpp_send_message();
 	<title>Configuration</title>
 		<para>
 		Next is presented a sample configuration file one can use to implement a
-		standalone SIP-to-XMPP gateway. You can run an instance of Kamailio on a
+		standalone SIP-to-XMPP gateway. You can run an instance of &kamailio; on a
 		separate machine or on different port with the following config, and have
 		the main SIP server configured to forward all SIP requests for XMPP world
 		to it.