doc Remove SVN ID's, remove history, change "SIP-router" and "ser" to "Kamailio"

doc/cfg.txt

@@ -1,9 +1,3 @@
-# $Id$
-#
-# History:
-# --------
-# 2007-12-06:	Created by Miklos
-
 SIP-router Configuration Framework
 
 1. Overview

doc/config_migration.txt

@@ -1,9 +1,3 @@
-# $Id$
-#
-# History:
-# --------
-# 2009-05-06  created by andrei
-
 =============================================================
 = Config migration guide from ser or kamailio to sip-router =
 =============================================================

doc/cvs-commit-rules.txt

@@ -1,23 +1,23 @@
-# $Id$
-#
-# SIP-router git commit rules
-
+Kamailio git commit rules
+=========================
 
 1. Changing other people's code:
 --------------------------------
- - send a patch to the code/module mantainer and/or sr-dev (don't commit changes to code you don't own if you don't have the mantainer's approval)
+ - send a patch to the code/module mantainer and/or sr-dev 
+   (don't commit changes to code you don't own if you don't have the mantainer's approval)
 Exceptions:
  a. compilation (this includes warning) fixes
  b. bug fixes
- c. api changes (some external functions definitions change)
+ c. API changes (some external functions definitions change)
  d. small changes due to a new release in the very near future (allowed only for the release manager)
 
 2. Code requirements
 --------------------
 2.1 Unstable branch:
- - the code must compile (at least on one architecture). If the code does not compile, but you still want to commit it, comment it out (#if 0 ... #endif)
+ - the code must compile (at least on one architecture). If the code does not compile, 
+   but you still want to commit it, comment it out (#if 0 ... #endif)
  - the code should compile without warnings (with -Wall) (exceptions: very difficult to avoid warnings)
- - follow SIP-router coding style
+ - follow Kamailio coding style
 
 2.2. Stable branch (everything for unstable branch +)
 ------------------------------------------------------

doc/dns.txt

@@ -1,27 +1,22 @@
-# $Id$
-#
-# History:
-# --------
-# 2006-09-08  created by andrei
-# 2007-06-18  added naptr & friends, dns_srv_lb, more compile options (andrei)
-#
-
-SIP-router and DNS Overview
+
+Kamailio and DNS Overview
 ---------------------------
 
- The dns subsystem in sip-router can either directly use libresolv and a combination
-  of the locally configured dns server, /etc/hosts and the local Network 
+ The DNS subsystem in Kamailio can either directly use libresolv and a combination
+  of the locally configured DNS server, /etc/hosts and the local Network 
   Information Service (NIS/YP a.s.o) or cache the query results (both positive
   and negative) and look first in its internal cache.
- When its internal dns cache is enabled, sip-router can also use dns failover: if
-  one destination resolves to multiple addresses sip-router can try all of them until
+
+ When its internal DNS cache is enabled, Kamailio can also use DNS failover: if
+  one destination resolves to multiple addresses Kamailio can try all of them until
   it finds one to which it can successfully send the packet or it exhausts all 
-  of them. sip-router (The tm module to be more precise) uses the DNS failover also 
+  of them. Kamailio (The tm module to be more precise) uses the DNS failover also 
   when the destination host doesn't send any reply to a forwarded invite within the
   SIP timeout interval (whose value can be configured using the tm fr_timer
   parameter).
-  When SRV based load balancing is enabled sip-router can even do DNS based load 
-  balancing (see RFC2782 and the dns_srv_lb option below).
+  When SRV based load balancing is enabled Kamailio can even do DNS based load 
+  balancing (see RFC2782 and the dns_srv_lb option below). This is using the
+  weight value in the DNS SRV record.
 
 
 DNS Cache and Failover Drawbacks
@@ -29,18 +24,18 @@ DNS Cache and Failover Drawbacks
 
  Using the DNS cache and the DNS failover has also some drawbacks: 
 
-  1. only the locally configured DNS server (usually in /etc/resolv.conf) is
-  used for the requests (/etc/hosts and the local Network Information Service
-  are ignored). 
-     Workaround: disable the dns cache (use_dns_cache=off or compile without -DUSE_DNS_CACHE).
+  1. Only the locally configured DNS server (usually in /etc/resolv.conf) is
+     used for the requests (/etc/hosts and the local Network Information Service
+     are ignored). 
+     Workaround: disable the DNS cache (use_dns_cache=off or compile without -DUSE_DNS_CACHE).
 
-  2. the DNS cache uses extra memory
+  2. The DNS cache uses extra memory
       Workaround: disable the DNS cache.
 
-  3. the DNS failover introduces a very small performance penalty 
+  3. The DNS failover introduces a very small performance penalty 
      Workaround: disable the DNS failover (use_dns_failover=off).
 
-  4. the DNS failover increases the memory usage (the internal structures
+  4. The DNS failover increases the memory usage (the internal structures
      used to represent the transaction are bigger when the DNS failover support is
      compiled).
      Workaround: compile without DNS failover support (-DUSE_DNS_FAILOVER).
@@ -49,9 +44,9 @@ DNS Cache and Failover Drawbacks
  
  On the other hand using the DNS cache saves lots of DNS queries and makes
  DNS based failover and DNS based load balancing possible. If the destination
- blacklist is enabled, sip-router can do failover even if forwarding in stateless 
+ blacklist is enabled, Kamailio can do failover even if forwarding in stateless 
  mode.
- In the ideal case with the DNS cache enabled sip-router will do only one query for
+ In the ideal case with the DNS cache enabled Kamailio will do only one query for
  a NAPTR (if enabled) or SRV lookup and then it will use the results for the
  record's TTL (for example if all the resulting records have 1 minute TTL,
  the server won't make another query for this domain for 1 minute). Even negative
@@ -64,29 +59,29 @@ DNS Cache and Failover Drawbacks
 DNS Resolver Options
 --------------------
 
- The DNS resolver options control how sip-router will interact with the external
+ The DNS resolver options control how Kamailio will interact with the external
  DNS servers. These options (with the dns_try_ipv6 exception) are passed to
- libresolv and are used each time a dns request is made.
+ libresolv and are used each time a DNS request is made.
 
  The default values are system specific and generally depend on the
  /etc/resolv.conf content. For servers doing a lot of DNS requests it is
- highly recommended to change the default values in the sip-router config file
-  (even if using sip-router's internal dns cache).
+ highly recommended to change the default values in the Kamailio config file
+  (even if using Kamailio's internal DNS cache).
 
-   dns_try_ipv6 = on | off - if on and sip-router listens on at least one ipv6 socket,
+   dns_try_ipv6 = on | off - if on and Kamailio listens on at least one ipv6 socket,
       ipv6 (AAAA) lookups will be performed if the ipv4 (A) lookups fail. 
       If off only ipv4 (A) lookups will be used.
-      Default: on if sip-router is compiled with ipv6 support.
+      Default: on if Kamailio is compiled with ipv6 support.
 
-   dns_try_naptr = on | off - if on sip-router will first try a NAPTR lookup for
+   dns_try_naptr = on | off - if on Kamailio will first try a NAPTR lookup for
       destinations that don't have the protocol or port specified and 
       are not simple ip addresses (as described in RFC 3263). This will 
       introduce a slight performance penalty and will probably cause extra
       DNS lookups. For example a lookup for a non-existing domain will
       produce one extra query: NAPTR(domain), SRV(_sip._udp.domain) 
       and A/AAAA(domain).
-      If the result of a query contains several NAPTR records, sip-router will select
-      among them according to the RFC2915 and sip-router preference towards a
+      If the result of a query contains several NAPTR records, Kamailio will select
+      among them according to the RFC2915 and Kamailio preference towards a
       specific protocol (see dns_udp_pref, dns_tcp_pref and dns_tls_pref 
       below). For an RFC3263 compliant configuration (choose the remote side
       preferred protocol if supported), set dns_udp_pref, dns_tcp_pref and
@@ -96,17 +91,17 @@ DNS Resolver Options
    dns_udp_pref = number - udp protocol preference when doing NAPTR lookups.
       This option works together with dns_tcp_pref, dns_tls_pref and 
       dns_sctp_pref. If all this options have the same positive value and more
-      NAPTR records are available, ser will select the NAPTR record preferred
+      NAPTR records are available, Kamailio will select the NAPTR record preferred
       by the remote side (according to RFC2915). If the values are positive
-      but different, ser will select the NAPTR record whose protocol it
+      but different, Kamailio will select the NAPTR record whose protocol it
       prefers the most (the protocol with the highest dns_<proto>_pref
       number). If there are several NAPTR records with the same preferred
-      protocol, ser will select among them based on their order and preference
+      protocol, Kamailio will select among them based on their order and preference
       (see RFC2915).
       To completely disable selecting a specific protocol, use  a negative
       number. For example dns_tcp_pref=-1 will completely disable selection
       of tcp NAPTR records, even if this will result in the NAPTR lookup
-      failure. Note: if a protocol is disabled in ser (e.g. tls_disable=1)
+      failure. Note: if a protocol is disabled in Kamailio (e.g. tls_disable=1)
       the corresponding NAPTR records selection will be also disabled,
       irrespective of the dns_<proto>_preference value.
       Default: dns_udp_pref=30, dns_tcp_pref=20,  dns_tls_pref=10 and 
@@ -121,14 +116,14 @@ DNS Resolver Options
 
    dns_sctp_pref = number (see dns_udp_pref above)
 
-   dns_retr_time = time - time in s before retrying a dns request.
+   dns_retr_time = time - time in s before retrying a DNS request.
       Default: system specific, depends also on the/etc/resolv.conf content
       (usually 5 s).
 
-   dns_retr_no = no. - number of dns retransmissions before giving up.
+   dns_retr_no = no. - number of DNS retransmissions before giving up.
       Default: see above (usually 4)
 
-   dns_servers_no = no. - how many dns servers from the ones defined in 
+   dns_servers_no = no. - how many DNS servers from the ones defined in 
       /etc/resolv.conf will be used. Default: all of them.
 
    dns_use_search_list= yes/no - if no, the search list in /etc/resolv.conf
@@ -137,7 +132,7 @@ DNS Resolver Options
       HINT: even if you don't have a search list defined, setting this option
       to "no" will still be "faster", because an empty search list is in 
       fact search "" (so even if the search list is empty/missing there will
-      still be 2 dns queries, eg. foo+'.' and foo+""+'.')
+      still be 2 DNS queries, eg. foo+'.' and foo+""+'.')
 
    dns_search_full_match = yes/no - controls the check of the name part
       which is found in the answer expanding the searched name before
@@ -147,11 +142,11 @@ DNS Resolver Options
       If set to no - no additional check is done.
       If set to yes - the additional part is checked against the search list.
 
- The maximum time a dns request can take (before failing) is:
- (dns_retr_time*dns_retr_no)*(search_list_domains) If dns_try_ipv6 is yes,
+ The maximum time a DNS request can take (before failing) is:
+ (dns_retr_time*dns_retr_no) * (search_list_domains) If dns_try_ipv6 is yes,
  mutliply it again by 2.
 
- The option combination that produces the "fastest" dns resolver config
+ The option combination that produces the "fastest" DNS resolver config
   (the "faster" in the sense that it gives up the quickest) is:
 
       dns_try_ipv6=no
@@ -160,19 +155,19 @@ DNS Resolver Options
       dns_servers_no=1
       dns_use_search_list=no
 
- The recommended dns configuration is to have a "close" dns caching recursive
- server configured in /etc/resolv.conf, set the dns resolver options in ser's
- config as in the above example and enable the dns cache (in ser).
+ The recommended DNS configuration is to have a "close" DNS caching recursive
+ server configured in /etc/resolv.conf, set the DNS resolver options in Kamailio's
+ config as in the above example and enable the DNS cache (in Kamailio).
  Pay particular attention to dns_servers_no and dns_use_search_list. It's a
  good idea to make sure you don't need / use the search list or more then one
- dns server (to avoid unnecessary extra lookups).
+ DNS server (to avoid unnecessary extra lookups).
 
 
 DNS Resolver Compile Options
 ----------------------------
 
    USE_NAPTR - if defined the naptr lookup support will be compiled in.
-      NAPTR support still has to be enabled from ser's config file (it's
+      NAPTR support still has to be enabled from Kamailio's config file (it's
       off by default).
 
    RESOLVE_DBG - if defined, the resolver will be very verbose: it will log
@@ -185,8 +180,8 @@ DNS Resolver Compile Options
 DNS Cache and Failover Config Variables
 ---------------------------------------
 
-   use_dns_cache = on | off - if off the dns cache won't be used (all dns
-      lookups will result into a dns request).  When on all the dns request
+   use_dns_cache = on | off - if off the DNS cache won't be used (all dns
+      lookups will result into a DNS request).  When on all the DNS request
       results will be cached.
       WARNING: when enabled /etc/hosts will be completely bypassed, all the dns
       request will go directly to the system configured (resolv.conf) dns
@@ -200,17 +195,17 @@ DNS Cache and Failover Config Variables
       re-tried using the next ip/record. In tm's case a new branch will be
       created for each new send attempt.
       Default: off.
-   Depends on use_dns_cache being on. If tm is used along with dns failover is
+   Depends on use_dns_cache being on. If tm is used along with DNS failover is
    recommended to also turn on dst_blacklist.
 
    dns_srv_lb = on | off or
-   dns_srv_loadbalancing = on | off - if on instead of doing simple dns 
-        failover (like above), ser will load balance requests to different srv
-        records of the same priority based on the srv records weights (like 
+   dns_srv_loadbalancing = on | off - if on instead of doing simple DNS 
+        failover (like above), Kamailio will load balance requests to different srv
+        records of the same priority based on the SRV records weights (like 
         described in RFC2782). For a destination which has different priorities
-        for all its srv records, this option will be equivalent with simple
-        dns failover.
-        Note: this option requires having dns failover enabled (see 
+        for all its SRV records, this option will be equivalent with simple
+        DNS failover.
+        Note: this option requires having DNS failover enabled (see 
         use_dns_failover above).
         Default: off.
 
@@ -229,13 +224,13 @@ DNS Cache and Failover Config Variables
    dns_tls_pref =  number - shared with the resolver (see resolver 
         description).
 
-   dns_cache_flags = dns cache specific resolver flags, used for overriding
+   dns_cache_flags = DNS cache specific resolver flags, used for overriding
      the default behaviour (low level).
       Possible values:
-         1 - ipv4 only: only DNS A requests are performed, even if ser listens
+         1 - ipv4 only: only DNS A requests are performed, even if Kamailio listens
                         also on ipv6 addresses.
          2 - ipv6 only: only DNS AAAA requests are performed. Ignored if
-                        dns_try_ipv6 is off or ser doesn't listen on any ipv6
+                        dns_try_ipv6 is off or Kamailio doesn't listen on any ipv6
                         address.
          4 - prefer ipv6: try first to resolve a host name to an ipv6 address
                           (DNS AAAA request) and only if this fails try an ipv4
@@ -257,10 +252,10 @@ DNS Cache and Failover Config Variables
       dns_cache_max_ttl will be used instead.
       Default: MAXINT
 
-   dns_cache_mem = maximum memory used for the dns cache in Kb.
+   dns_cache_mem = maximum memory used for the DNS cache in Kb.
       Default: 500 Kb
 
-   dns_cache_gc_interval = how often (in s) the dns cache will be garbage 
+   dns_cache_gc_interval = how often (in s) the DNS cache will be garbage 
       collected.
       Default:  120 s.
       
@@ -270,37 +265,37 @@ DNS Cache and Failover Config Variables
       ones. The last-recently used entries are deleted first.
       Default: no
 
-   dns_cache_init = on | off - if off, the dns cache is not initialized
+   dns_cache_init = on | off - if off, the DNS cache is not initialized
       at startup and cannot be enabled runtime, that saves some memory.
       Default: on
 
 DNS Cache Compile Options
 -------------------------
 
-   USE_DNS_CACHE - if defined the dns cache support will be compiled in 
+   USE_DNS_CACHE - if defined the DNS cache support will be compiled in 
       (default). If not needed/wanted the dns_cache can be disabled from the
-      ser's config file. The only advantages for not compiling the dns cache
+      Kamailio's config file. The only advantages for not compiling the DNS cache
       support is a slight decrease of the executable size and an extremely 
-      small performance increase (1 less comparison per dns request).
+      small performance increase (1 less comparison per DNS request).
 
-   USE_DNS_FAILOVER - if defined the dns failover support will be compiled in.
-      (default). Compiling the dns failover support has a few disadvantages,
+   USE_DNS_FAILOVER - if defined the DNS failover support will be compiled in.
+      (default). Compiling the DNS failover support has a few disadvantages,
       see the "Drawbacks" section.
 
    DNS_SRV_LB  - if defined (default) support for load balancing using 
-       srv records weights (as described in RFC2782) will be compiled in.
-       Note however that it still must be enabled from the ser config, it's
+       SRV records weights (as described in RFC2782) will be compiled in.
+       Note however that it still must be enabled from the Kamailio config, it's
        disabled by default (see the dns_srv_lb config option).
 
    USE_NAPTR  - (shared with the resolver)  if defined NAPTR support will
        be compiled in (default). Note that even if compiled, NAPTR support
-       must be enabled also from the ser config (see the dns_try_naptr option).
+       must be enabled also from the Kamailio config (see the dns_try_naptr option).
 
    NAPTR_CACHE_ALL_ARS - if defined all the additional records in a NAPTR
-       answer will be cached. Normally ser would cache only "related" records
+       answer will be cached. Normally Kamailio would cache only "related" records
        (records that are directly referred), but for answers with lots of 
         A/AAAA records it might happen that not all of the SRV records will fit
-       in the AR section. In this case, without this compile option ser will 
+       in the AR section. In this case, without this compile option Kamailio will 
        not cache the un-referred A/AAAA records. BY default this option is
        disabled.
 
@@ -312,10 +307,10 @@ DNS Cache Compile Options
        If this option is not defined (experimental), everything in the AR
        section will be added to the cache.
 
-   DNS_CACHE_DEBUG - if defined the dns cache will be very verbose (it will
+   DNS_CACHE_DEBUG - if defined the DNS cache will be very verbose (it will
        log lots of messages at the L_DBG levell).
  
- Note: To remove a compile options,  edit sip-router's Makefile.defs and remove it 
+ Note: To remove a compile options,  edit Kamailio's Makefile.defs and remove it 
    from DEFS list. To add a compile options add it to the make command line,
      e.g.: make proper; make all extra_defs=-DUSE_DNS_FAILOVER
    or for a permanent solution, edit Makefile.defs and add it to DEFS 

doc/dst_blacklist.txt

@@ -1,10 +1,3 @@
-# $Id$
-#
-# History:
-# --------
-# 2006-09-08  created by andrei
-#
-
 Destination blacklist Overview
 ------------------------------
 

doc/locking.txt

@@ -1,19 +1,12 @@
-# $Id$
-#
-# History:
-#---------
-#  2003-03-11  created by andrei
-#  2006-04-04  minor archs updates, added lock_try(..)  (andrei)
 
-
-SIP-router locking interface
+Kamailio locking interface
 ============================
 
 1. Why use it?
 --------------
 
 The main reason for creating it was to have a single transparent interface to various locking methods. 
-For example right now SIP-router uses the following locking methods, depending on their availability on the 
+For example right now Kamailio uses the following locking methods, depending on their availability on the 
 target system:
 	FAST_LOCK - fast inline assembly locks, defined in fast_lock.h. They are currently available for 
 	x86, x86_64, sparc, sparc64, arm , armv6 (no smp mode supported yet), ppc, ppc64, mips, mips64 
@@ -39,7 +32,7 @@ target system:
 -----------------
 
 First of all you have to include locking.h. Then when compiling the code one or all of FAST_LOCK, 
-USE_PTHREAD_MUTEX, USE_PTHREAD_SEM or USE_SYSV_SEM must be defined (the SIP-router Makefile.defs takes 
+USE_PTHREAD_MUTEX, USE_PTHREAD_SEM or USE_SYSV_SEM must be defined (the Kamailio Makefile.defs takes 
 care of this, you should need to change it only for new arhitectures or compilers).
 
 locking.h defines 2 new types: gen_lock_t and lock_set_t.

doc/logging-api.txt

@@ -7,7 +7,7 @@
                          Ondrej Martinek <[email protected]>
                                               January 2009
 
-This document contains the short description of the logging API in SIP-router
+This document contains the short description of the logging API in Kamailio
 for developers.
 
 Source files:
@@ -121,7 +121,7 @@ Source files:
 !!! IMPORTANT! READ ME!
 !!!
 !!!  These changes (mainly the first two) require reformating of the most log
-!!!  messages in SIP-router core and module source files.  This step can be done
+!!!  messages in Kamailio core and module source files.  This step can be done
 !!!  automatically by running "scripts/logging/fix-logs-all" script BUT it
 !!!  was NOT originally performed because it would have generated too many
 !!!  changes in CVS which was discouraged by Andrei.  Instead, the developers
@@ -130,5 +130,3 @@ Source files:
 !!! IMPORTANT! READ ME!
 !!!  
 
---
-$Id$

doc/management_api.txt

@@ -1,7 +1,7 @@
-Management API's in SIP-router
+Management API's in Kamailio
 ------------------------------
 
-SIP-router has an API based on RPC. This allows modules and core to expose commands that can be 
+Kamailio has an API based on RPC. This allows modules and core to expose commands that can be 
 issued by external applications. Commands can change states, read status variables or expose
 internal structures.
 
@@ -14,7 +14,7 @@ you can adapt the interface to one of several protocols supported:
 
 The MI interfaces can often run over Unix fifo sockets, UDP or TCP connections.
 
-The "sercmd" application is the command line tool used to connect to SIP-router
+The "kamcmd" application is the command line tool used to connect to Kamailio
 over the command line. Use it to discover available commands.
 
 For backwards compatibilty, the kamctrl and kamdbctrl commands are still supported.
@@ -25,7 +25,7 @@ web site in the wiki section.
 Modules
 -------
 
-mi_rpc		Exports Kamailio's MI interface over SIP-router's RPC interface
+mi_rpc		Exports Kamailio's MI interface over Kamailio's RPC interface
 xmlrpc		Exports the RPC interface using XML-rpc
 ctl		Implements the binrpc transport interface for SER rpcs
 		Also implements the old SER fifo-based management interface.

doc/modules_init.txt

@@ -1,12 +1,5 @@
-#$Id$
-#
-#
-# History
-#--------
-#  2007-06-07  created by Andrei Pelinescu <[email protected]>
-#
-
-SIP-router Module intialization description
+
+Kamailio Module intialization description
 ===========================================
 
 This document is a very brief overview on what possibilities are for a module
@@ -24,21 +17,21 @@ mod_init is called after parsing the config, loading all the modules and
 going into daemon mode. mod_init is called in the main process context,
 before changing the uid or gid (so if you want to do something requiring
 higher privileges this is the place to do it). This is not the right place
-to fork more SIP-router processes, but instead is the only place where one can 
+to fork more Kamailio processes, but instead is the only place where one can 
 register future forked processes (see register_procs()).
 
 mod_init is ideal for initializing per process variables, assuming that you
-don't need different values for each SIP-router child (in which case see 
+don't need different values for each Kamailio child (in which case see 
 mod_child_init below) and shared memory variables assuming that you don't 
-need SIP-router's number of processes (which is not available at this point).
+need Kamailio's number of processes (which is not available at this point).
 
 
 mod_child_init
 ---------------
 
-mod_child_init is called for each forked SIP-router process with 2 exceptions:
+mod_child_init is called for each forked Kamailio process with 2 exceptions:
  - it's called for the main process too and it's called twice
- - it's not called for SIP-router processes forked with PROC_NOCHLDINIT
+ - it's not called for Kamailio processes forked with PROC_NOCHLDINIT
 
 mod_child_init is always called after mod_init. It takes one parameter, the
  process rank. This parameter can be used to differentiate between normal
@@ -48,7 +41,7 @@ There are two very special rank values: PROC_INIT (as of 2007-06-06) and
 mod_child_init(PROC_INIT) is the first mod_child_init call made, and it's
  guaranteed to happen before any child process is forked. The process context
   is the "main" process (as for mod_init), but this time we have a little bit
- more information: we know the number of SIP-router processes. This is the right
+ more information: we know the number of Kamailio processes. This is the right
   place to initialize things like shared arrays[get_max_procs()].
 Note also that everything done here will be inherited in all the future
  children processes (since it's executed in the "main" process context before
@@ -56,14 +49,14 @@ Note also that everything done here will be inherited in all the future
 
 mod_child_init(PROC_MAIN) is another call that is done in the same "main"
  process context. This call happens just before initializing the main tcp
-  process. This is the only right place for forking more SIP-router processes
+  process. This is the only right place for forking more Kamailio processes
   (see fork_process()). WARNING: the context is the same "main" process as
  for mod_child_init(PROC_INIT) and mod_init() so care must be taken not to
  initialize things twice or three times for the "main" process.
 
 Except for the "main" process case mod_child_init(rank) will be called only
 once for each new child process, just after forking. A positive non-zero rank
- means the current process is a normal SIP-router process and a negative rank has
+ means the current process is a normal Kamailio process and a negative rank has
   some special meaning (grep PROC_ sr_module.h for more info).
 mod_child_init(rank) is the best place for initializing per process variables,
  opening per process database connections, new sockets a.s.o. Note however
@@ -76,7 +69,7 @@ mod_child_init(rank) is the best place for initializing per process variables,
 mod_child_init in the no-fork case
 ----------------------------------
 
-If SIP-router is started in no-fork mode it will try to start as few processes as
+If Kamailio is started in no-fork mode it will try to start as few processes as
 possible (as of this date it will start 3 processes the main process and the
 2 timers). In this case mod_child_init() will be called 3 times in the
 same "main" process context: mod_child_init(PROC_INIT);
@@ -84,7 +77,7 @@ mod_child_init(PROC_MAIN) and mod_child_init(1) (since the first process is
 also the "main" one).
 
 
-Forking new SIP-router processes from a module
+Forking new Kamailio processes from a module
 ---------------------------------------
 
 static int mod_init()
@@ -140,7 +133,7 @@ mod_child_init(PROC_INIT)
   process.
 
 mod_child_init(PROC_MAIN)
- - the only place from where another SIP-router process can be forked 
+ - the only place from where another Kamailio process can be forked 
    (see fork_process  ()), but remember first to register the number of 
    to-be-forked processes in mod_init()
 

doc/parse_headers.txt

@@ -1,5 +1,3 @@
-# $Id$
-#
 # parse headers api changes
 #
 # 2004.02.23  created (andrei)

doc/ser.txt

@@ -1,5 +1,3 @@
-$Id$
-
 iptel.org SIP Express Router (SER) is a high-performance, 
 configurable, free server implementing Session Initiation 
 Protocol (SIP, RFC3216). SIP is a signaling protocol that 

doc/sr-coding-style.txt

@@ -1,6 +1,4 @@
-# $Id$
-#
-# SIP-router Coding Style
+# Kamailio Coding Style
 #
 #  2004-06-07  Andrei Pelinescu - Onciul <[email protected]>
 
@@ -47,7 +45,7 @@ Doxygen
 -------
 - try to always add doxygen comments to functions and variables declared in your code. 
   Especially remember to document public functions, functions and structures
-  that are part of the SIP-router API.
+  that are part of the Kamailio API.
 - each file needs a declaration of the purpose of the file in the \file section
 
 If you are editing someone elses code, try to use his coding conventions

doc/tcp_tunning.txt

@@ -1,17 +1,11 @@
-# $Id$
-#
-# History:
-# --------
-# 2006-01-26  created by andrei
-
-SIP-router TCP Tunning/monitoring for lots of open connections
+Kamailio TCP Tunning/monitoring for lots of open connections
 ==============================================================
 
 0. Introduction
 ----------------
 
 This document describes very briefly various settings that should improve
-sip-router+TCP performance for sites handling a lot of TCP traffic (> 1000 open
+Kamailio TCP performance for sites handling a lot of TCP traffic (> 1000 open
 connections or very high connection/disconnection rates).
 
 For now it deals only with Linux specific optimizations.
@@ -77,7 +71,6 @@ iptables  - remove the ip_conntrack module (it limits the maximum tcp
   all the iptables modules.
 
 
-
 2. Monitoring (values to watch for)
 -----------------------------------
 
@@ -96,15 +89,15 @@ fs.inode-state  -  format: nr. allocated, nr. free, preshrink
 /proc/net/sockstat
 
 
-3. Sip-router settings
+3. Kamailio settings
 ----------------------
 
 - Don't forget to increase tcp_max_connections and the amount of shared memory
-- You should increase the number of ser "tcp_children" processes (-N no)
+- You should increase the number of Kamailio "tcp_children" processes (-N no)
   As a rule of thumb, (maximum simultaneous connections)/2000 should be ok
 - You might have to decrease TCP_BUF_SIZE to a smaller value (e.g 8K)
 - You might want to increase PKG_MEM_POOL_SIZE (for large queues)
 
-- You might need to increase the maximum open fds limit before starting ser
+- You might need to increase the maximum open fds limit before starting Kamailio
   (e.g. ulimit -n 1000000)
 

doc/timers.txt

@@ -1,18 +1,12 @@
-# $Id$
-#
-# History:
-# --------
-# 2005-11-30    created by andrei
 
-
-SIP-router :: timer interface
+Kamailio :: timer interface
 =============================
 
 
 1. Introduction
 ---------------
 
-SIP-router's timer interface is based on a 3 level hierarchical timing wheel
+Kamailio's timer interface is based on a 3 level hierarchical timing wheel
 (see [1]). Most timeouts will go in the first "wheel" (all timeouts < 1<<14 
 ticks, which by default mean 1024 s). Each wheel acts as a circular buffer.
 The big advantage of this scheme is that most of the time you just run all the 
@@ -78,10 +72,12 @@ timer_free(t);
 
 To use a timer you need a timer_ln structure. This structure must be stored
  in shared memory.
-You can either use timer_alloc() which will return a pointer to a shared memory allocated timer_ln structure or you can "attach" timer_ln as a member to one
+You can either use timer_alloc() which will return a pointer to a shared memory 
+allocated timer_ln structure or you can "attach" timer_ln as a member to one
  of your structures which is already stored in the shared memory.
 
-The timer_ln structure must be always initialized. Use the timer_init(...) macro for this. To the timer_init macro takes as parameters a pointer to the timer_ln structure, a pointer to a timer_handler_f function, a void* parameter for this
+The timer_ln structure must be always initialized. Use the timer_init(...) macro for this. 
+To the timer_init macro takes as parameters a pointer to the timer_ln structure, a pointer to a timer_handler_f function, a void* parameter for this
  function and some timer flags.
 Example:
 
@@ -145,15 +141,26 @@ timer_add(&f->timer, rand());
 timer_del(&f->timer); /* if the timer is already expired => f is already
                          deleted => problems */
 
-The above timer_del/free_in_one_shot_timer race example is very simple, but consider that you can have much more complex scenarios, when timer_del can be called from different processes on some asynchronous events. If this looks like your intended usage, make sure you use some  reference counters or some other protection mechanism to avoid the above race.
+The above timer_del/free_in_one_shot_timer race example is very simple, but 
+consider that you can have much more complex scenarios, when timer_del can be 
+called from different processes on some asynchronous events. If this looks like your 
+intended usage, make sure you use some  reference counters or some other 
+protection mechanism to avoid the above race.
 
 4.5 timer_allow_del
 -------------------
 
-Marks a timer as "to be deleted when the handler ends", usefull when the timer handler knows it won't prolong the timer anymore (it will return 0) and will do some time consuming work. Calling this function will cause simultaneous timer_dels to return immediately (they won't  wait anymore for the timer handle to finish). It will also allow  self-deleting from the timer handle without logging a bug.
- WARNING: - if you rely on timer_del to know when the timer handle execution finishes (e.g. to free resources used in the timer handle), don't use this function.
-          - call this function only if this is your last timer handle run (the timer handle will return 0)
-          - this function can be called only from a timer handle (in timer context), all other calls will have no effect and will log a bug message
+Marks a timer as "to be deleted when the handler ends", usefull when the timer handler 
+knows it won't prolong the timer anymore (it will return 0) and will do some time 
+consuming work. Calling this function will cause simultaneous timer_dels to return 
+immediately (they won't  wait anymore for the timer handle to finish). 
+It will also allow  self-deleting from the timer handle without logging a bug.
+ WARNING: - if you rely on timer_del to know when the timer handle execution 
+	    finishes (e.g. to free resources used in the timer handle), don't use this function.
+          - call this function only if this is your last timer handle run
+	    (the timer handle will return 0)
+          - this function can be called only from a timer handle (in timer context), 
+  	    all other calls will have no effect and will log a bug message
 
 
 4.6 Getting the ticks value
@@ -179,26 +186,30 @@ TICKS_TO_S(t)  /* converts from ticks to s, rounded down */
 4.8 Ticks value comparison
 ---------------------------
 
-The ticks value can (and will) overflow so ticks values should never be compared directly (e.g. ticks1<ticks2). To compare them include timer_ticks.h and use
- one of the macros:
+The ticks value can (and will) overflow so ticks values should never be compared directly
+(e.g. ticks1<ticks2). To compare them include timer_ticks.h and use
+one of the macros:
 
 TICKS_LT(t1, t2)  /*  t1 < t2 */
 TICKS_GT(t1, t2)  /*  t1 > t2 */
 TICKS_LE(t1, t2)  /*  t1 <= t2 */
 TICKS_GE(t1, t2)  /*  t1 >= t2 */
 
-These macros work as long as the difference between t1 and t2 is less then 2^(sizeof(ticks_t)*8-1). For the default TIMER_TICKS_HZ values, this means 4.25 years.
+These macros work as long as the difference between t1 and t2 is less than 2^(sizeof(ticks_t)*8-1). 
+For the default TIMER_TICKS_HZ values, this means 4.25 years.
 
 4.9 Backward compatibility
 --------------------------
 
-The old  register_timer and get_ticks() are still supported for backward compatibility. This means that you don't have to change your existing working code.
+The old  register_timer and get_ticks() are still supported for backward compatibility. 
+This means that you don't have to change your existing working code.
 
 
 5.0 Debugging
 -------------
 
-The timers have built-in debugging information. To activate it you only need to define TIMER_DEBUG (recompile ser with make CC_EXTRA_OPTS=-DTIMER_DEBUG all).
+The timers have built-in debugging information. To activate it you only need to
+define TIMER_DEBUG (recompile Kamailio with make CC_EXTRA_OPTS=-DTIMER_DEBUG all).
 The timer debug log level is by default L_WARN. [ FIXME: add it as script option]
 TIMER_DEBUG enables extra sanity checks and it will log a lot of information
  (like the caller of timer_* functions, where a timer was added a.s.o).