Module: sip-router Branch: mariuszbihlei/p_usrloc Commit: edef9f7b0d3a67a349b53b8f5779550eb0a56b98 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=edef9f7b...
Author: Marius Zbihlei marius.zbihlei@1and1.ro Committer: Marius Zbihlei marius.zbihlei@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>