11 Jan
2011
11 Jan
'11
6:46 a.m.
Module: sip-router
Branch: mariuszbihlei/p_usrloc
Commit: edef9f7b0d3a67a349b53b8f5779550eb0a56b98
URL:
http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=edef9f7…
Author: Marius Zbihlei <marius.zbihlei(a)1and1.ro>
Committer: Marius Zbihlei <marius.zbihlei(a)1and1.ro>
Date: Tue Jan 11 12:19:06 2011 +0200
modules/p_usrloc Updated documentation
---
modules_k/p_usrloc/README | 96 +++++++++++++++++++++++-------
modules_k/p_usrloc/doc/p_usrloc_user.xml | 63 +++++++++++++++++++
2 files changed, 138 insertions(+), 21 deletions(-)
diff --git a/modules_k/p_usrloc/README b/modules_k/p_usrloc/README
index 90e3b75..edf137e 100644
--- a/modules_k/p_usrloc/README
+++ b/modules_k/p_usrloc/README
@@ -55,14 +55,19 @@ Marius Zbihlei
3.21. connection_expires (int)
3.22. alg_location (int)
- 4. Installation & Running
+ 4. Changes from usrloc module
- 4.1. Database setup
+ 4.1. db_mode (integer)
+ 4.2. db_url
- 4.1.1. Configuration Table
+ 5. Installation & Running
- 4.2. Maintenance
- 4.3. Additional configuration
+ 5.1. Database setup
+
+ 5.1.1. Configuration Table
+
+ 5.2. Maintenance
+ 5.3. Additional configuration
2. Developer's Guide
@@ -114,7 +119,8 @@ Marius Zbihlei
1.20. Set write_on_db parameter
1.21. Set connection_expires parameter
1.22. Set alg_location parameter
- 1.23. Example database content - reg_table (locdb) table
+ 1.23. Set db_mode parameter
+ 1.24. Example database content - reg_table (locdb) table
Chapter 1. User's Guide
@@ -155,14 +161,19 @@ Chapter 1. User's Guide
3.21. connection_expires (int)
3.22. alg_location (int)
- 4. Installation & Running
+ 4. Changes from usrloc module
+
+ 4.1. db_mode (integer)
+ 4.2. db_url
+
+ 5. Installation & Running
- 4.1. Database setup
+ 5.1. Database setup
- 4.1.1. Configuration Table
+ 5.1.1. Configuration Table
- 4.2. Maintenance
- 4.3. Additional configuration
+ 5.2. Maintenance
+ 5.3. Additional configuration
1. Overview
@@ -539,18 +550,61 @@ modparam("p_usrloc", "connection_expires",
"300")
modparam("p_usrloc", "alg_location", 1)
...
-4. Installation & Running
+4. Changes from usrloc module
+
+ 4.1. db_mode (integer)
+ 4.2. db_url
+
+4.1. db_mode (integer)
+
+ The p_usrloc module must utilize database for persistent contact
+ storage. So mode 0 makes no sense in this setup.
+ * 1 - Write-Through scheme. All changes to usrloc are immediately
+ reflected in database too. This is very slow, but very reliable.
+ Use this scheme if speed is not your priority but need to make sure
+ that no registered contacts will be lost during crash or reboot.
+ * 2 - Write-Back scheme. This is a combination of previous two
+ schemes. All changes are made to memory and database
+ synchronization is done in the timer. The timer deletes all expired
+ contacts and flushes all modified or new contacts to database. Use
+ this scheme if you encounter high-load peaks and want them to
+ process as fast as possible. The mode will not help at all if the
+ load is high all the time. Also, latency of this mode is much lower
+ than latency of mode 1, but slightly higher than latency of mode 0.
+ * 3 - DB-Only scheme. No memory cache is kept, all operations being
+ directly performed with the database. The timer deletes all expired
+ contacts from database - cleans after clients that didn't
+ un-register or re-register. The mode is useful if you configure
+ more servers sharing the same DB without any replication at SIP
+ level. The mode may be slower due the high number of DB operation.
+ For example NAT pinging is a killer since during each ping cycle
+ all nated contact are loaded from the DB; The lack of memory
+ caching also disable the statistics exports.
+
+ Default value is 3.
+
+ Example 1.23. Set db_mode parameter
+...
+modparam("p_usrloc", "db_mode", 2)
+...
+
+4.2. db_url
+
+ This parameters is now obsolete, and replaced by specific p_usrloc
+ parameters
+
+5. Installation & Running
- 4.1. Database setup
+ 5.1. Database setup
- 4.1.1. Configuration Table
+ 5.1.1. Configuration Table
- 4.2. Maintenance
- 4.3. Additional configuration
+ 5.2. Maintenance
+ 5.3. Additional configuration
-4.1. Database setup
+5.1. Database setup
-4.1.1. Configuration Table
+5.1.1. Configuration Table
Before running Kamailio with p_usrloc, you have to setup the master
database table where the module will find data about the distributed
@@ -563,7 +617,7 @@ modparam("p_usrloc", "alg_location", 1)
complete database documentation on the project webpage,
http://www.kamailio.org/docs/db-tables/kamailio-db-devel.html.
- Example 1.23. Example database content - reg_table (locdb) table
+ Example 1.24. Example database content - reg_table (locdb) table
...
+----+----+------+--------+--------+---------------------+-------+----+
| id | no | url | status | errors | failover | spare | rg |
@@ -583,7 +637,7 @@ modparam("p_usrloc", "alg_location", 1)
This table contains two database groups. The first with id one, and the
second with the id two.
-4.2. Maintenance
+5.2. Maintenance
The module supports the decativation of redundant databases for
maintenance reasons. This can be done by setting the status column of
@@ -606,7 +660,7 @@ modparam("p_usrloc", "alg_location", 1)
then also used to read contacts from, the cluster is in normal
operation with full redundancy again.
-4.3. Additional configuration
+5.3. Additional configuration
As this module is only used internally from other modules, there is no
additional configuration except for the module parameter setup
diff --git a/modules_k/p_usrloc/doc/p_usrloc_user.xml
b/modules_k/p_usrloc/doc/p_usrloc_user.xml
index 537a327..6690909 100644
--- a/modules_k/p_usrloc/doc/p_usrloc_user.xml
+++ b/modules_k/p_usrloc/doc/p_usrloc_user.xml
@@ -561,6 +561,69 @@ modparam("p_usrloc", "alg_location", 1)
</section>
</section>
<section>
+ <title> Changes from usrloc module </title>
+ <section>
+ <title><varname>db_mode</varname> (integer)</title>
+ <para>
+ The p_usrloc module must utilize database for persistent contact storage.
+ So mode 0 makes no sense in this setup.
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ 1 - Write-Through scheme. All changes to usrloc are immediately
+ reflected in database too. This is very slow, but very reliable.
+ Use this scheme if speed is not your priority but need to make
+ sure that no registered contacts will be lost during crash or
+ reboot.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ 2 - Write-Back scheme. This is a combination of previous two
+ schemes. All changes are made to memory and database
+ synchronization is done in the timer. The timer deletes all
+ expired contacts and flushes all modified or new contacts to
+ database. Use this scheme if you encounter high-load peaks
+ and want them to process as fast as possible. The mode will
+ not help at all if the load is high all the time. Also, latency
+ of this mode is much lower than latency of mode 1, but slightly
+ higher than latency of mode 0.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ 3 - DB-Only scheme. No memory cache is kept, all operations being
+ directly performed with the database. The timer deletes all
+ expired contacts from database - cleans after clients that didn't
+ un-register or re-register. The mode is useful if you configure
+ more servers sharing the same DB without any replication at SIP
+ level. The mode may be slower due the high number of DB operation.
+ For example NAT pinging is a killer since during each ping cycle
+ all nated contact are loaded from the DB; The lack of memory
+ caching also disable the statistics exports.
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ <emphasis>
+ Default value is 3.
+ </emphasis>
+ </para>
+ <example>
+ <title>Set <varname>db_mode</varname> parameter</title>
+ <programlisting format="linespecific">
+...
+modparam("p_usrloc", "db_mode", 2)
+...
+</programlisting>
+ </example>
+ </section>
+ <section>
+ <title><varname>db_url</varname></title> <para> This
parameters is now obsolete, and replaced by specific p_usrloc parameters</para>
+ </section>
+ </section>
+ <section>
<title>Installation & Running</title>
<section>
<title>Database setup</title>