Module: sip-router
Branch: master
Commit: 247a71839a3112aac26ce0ac27e0507664bfe810
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=247a718…
Author: Henning Westerholt <henning.westerholt(a)1und1.de>
Committer: Henning Westerholt <henning.westerholt(a)1und1.de>
Date: Thu Apr 30 19:58:20 2009 +0200
spelling fixes in documentation
---
modules_s/registrar/README | 14 +++++++-------
modules_s/registrar/doc/registrar.xml | 4 ++--
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/modules_s/registrar/README b/modules_s/registrar/README
index 102fe58..0bb62ee 100644
--- a/modules_s/registrar/README
+++ b/modules_s/registrar/README
@@ -70,12 +70,12 @@ UA2 ---- NAT2 ----| 5090 |
Registrar and usrloc would store the public IP of NAT with each
registered contact, thus it would know how to reach both user agents.
- In addition to the publi IP and port of the NAT device, registrar would
- also remember the destination IP and port of the REGISTER request (the
- IP and port used in SER). If registrar did not store this information,
- it would not know what outbound socket it should use when sending SIP
- messages to the registered contact. It would use the default port
- number (often 5060) for such outgoing requests.
+ In addition to the public IP and port of the NAT device, registrar
+ would also remember the destination IP and port of the REGISTER request
+ (the IP and port used in SER). If registrar did not store this
+ information, it would not know what outbound socket it should use when
+ sending SIP messages to the registered contact. It would use the
+ default port number (often 5060) for such outgoing requests.
When an INVITE for UA1 comes, everything would work because UA1 used
port 5060 when registering and that is also the destination port in the
@@ -98,7 +98,7 @@ UA1 ---- NAT1 +------ | 5060 | <---------------
UA2 ---- NAT2 X <----+ | 5090 |
+--------+
- That is the reason why registrar and usrloc also need to remmember the
+ That is the reason why registrar and usrloc also need to remember the
IP and port used on the server side, that information would be used
later when forwarding INVITEs:
SER
diff --git a/modules_s/registrar/doc/registrar.xml b/modules_s/registrar/doc/registrar.xml
index da8e93e..b553f0a 100644
--- a/modules_s/registrar/doc/registrar.xml
+++ b/modules_s/registrar/doc/registrar.xml
@@ -72,7 +72,7 @@ UA2 ---- NAT2 ----| 5090 |
agents.
</para>
<para>
- In addition to the publi IP and port of the NAT device, registrar
+ In addition to the public IP and port of the NAT device, registrar
would also remember the destination IP and port of the REGISTER
request (the IP and port used in SER). If registrar did not store
this information, it would not know what outbound socket it should
@@ -111,7 +111,7 @@ UA2 ---- NAT2 X <----+ | 5090 |
]]>
</programlisting>
<para>
- That is the reason why registrar and usrloc also need to remmember
+ That is the reason why registrar and usrloc also need to remember
the IP and port used on the server side, that information would be
used later when forwarding INVITEs:
</para>
Module: sip-router
Branch: master
Commit: 26fa3cf1464b0cddb67be64cd30918b9c2965c13
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=26fa3cf…
Author: Henning Westerholt <henning.westerholt(a)1und1.de>
Committer: Henning Westerholt <henning.westerholt(a)1und1.de>
Date: Sun May 3 19:23:22 2009 +0200
spelling fix in documentation
---
modules/tm/README | 2 +-
modules/tm/doc/functions.xml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/modules/tm/README b/modules/tm/README
index 87579b1..7b1ce8f 100644
--- a/modules/tm/README
+++ b/modules/tm/README
@@ -838,7 +838,7 @@ t_reply("404", "Not found");
Checks if a transaction exists. Returns a positive value if so,
negative otherwise. Most likely you will not want to use it, as a
- typical application of a looku-up is to introduce a new transaction if
+ typical application of a look-up is to introduce a new transaction if
none was found. However this is safely (atomically) done using
t_newtran.
diff --git a/modules/tm/doc/functions.xml b/modules/tm/doc/functions.xml
index 6571fd3..1c25aeb 100644
--- a/modules/tm/doc/functions.xml
+++ b/modules/tm/doc/functions.xml
@@ -320,7 +320,7 @@ t_reply("404", "Not found");
<para>
Checks if a transaction exists. Returns a positive value if so,
negative otherwise. Most likely you will not want to use it, as a
- typical application of a looku-up is to introduce a new transaction
+ typical application of a look-up is to introduce a new transaction
if none was found. However this is safely (atomically) done using
<function>t_newtran</function>.
</para>
Module: sip-router
Branch: master
Commit: a13da049257f5c6b9a5da52ac1a55f25e6dadfe5
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a13da04…
Author: Henning Westerholt <henning.westerholt(a)1und1.de>
Committer: Henning Westerholt <henning.westerholt(a)1und1.de>
Date: Thu Apr 30 18:55:41 2009 +0200
generate README for blst module
---
modules_s/blst/README | 82 +++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 82 insertions(+), 0 deletions(-)
diff --git a/modules_s/blst/README b/modules_s/blst/README
new file mode 100644
index 0000000..8387e98
--- /dev/null
+++ b/modules_s/blst/README
@@ -0,0 +1,82 @@
+1. Blst Module
+
+Andrei Pelinescu-Onciul
+
+ iptelorg GmbH
+
+ Copyright � 2007 iptelorg GmbH
+ Revision History
+ Revision $Revision$ $Date$
+ __________________________________________________________________
+
+ 1.1. Overview
+ 1.2. Functions
+
+ 1.2.1. blst_add([timeout])
+ 1.2.2. blst_add_retry_after(min, max)
+ 1.2.3. blst_del()
+ 1.2.4. blst_is_blacklisted()
+
+1.1. Overview
+
+ This module exports blacklist related functions to the script.
+
+1.2. Functions
+
+ Revision History
+ Revision $Revision$ $Date$
+
+1.2.1. blst_add([timeout])
+
+ Adds the source of the current message to the blacklist for timeout
+ seconds. If timeout is missing or 0 it uses the default blacklist
+ timeout (dst_blacklist_expire).
+
+ Example 1. blst_add usage
+...
+if (src_ip==10.0.0.0/9)
+ blst_add(30); # 30 s
+else
+ blst_add(); # use default blacklist timeout
+...
+
+1.2.2. blst_add_retry_after(min, max)
+
+ Adds the source of the current message to the blacklist for the time
+ interval specified in the Retry-After header. If the Retry-After header
+ is missing, it will fail (returns false). If the Retry-After value is
+ less then min, then min seconds will be used instead. If the
+ Retry-After value is greater then max, then max seconds will be used
+ instead.
+
+ Example 2. blst_add_retry_after usage
+...
+# on_reply route
+if (msg_status==503){ # blacklist 503 source for Retry-After seconds
+ if (! blst_add_retry_after(30, 3600))
+ blst_add(60); # if no retry_after header add it for 60s
+}
+...
+
+1.2.3. blst_del()
+
+ Removes the source of the current message from the blacklist. If the
+ address is not present in the blacklist at the time of the call it
+ returns false.
+
+ Example 3. blst_del usage
+...
+ blst_del();
+...
+
+1.2.4. blst_is_blacklisted()
+
+ Returns true if the source of the current message is blacklisted.
+
+ Example 4. blst_is_blacklisted usage
+...
+ if (blst_is_blacklisted()){
+ log("message from a blacklisted source");
+ drop;
+ }
+...
Module: sip-router
Branch: master
Commit: c90d02e608c048a3bbcf263daadb024c829bded2
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=c90d02e…
Author: Henning Westerholt <henning.westerholt(a)1und1.de>
Committer: Henning Westerholt <henning.westerholt(a)1und1.de>
Date: Thu Apr 30 18:54:26 2009 +0200
generate README for bdb module
---
modules_s/bdb/README | 199 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 199 insertions(+), 0 deletions(-)
diff --git a/modules_s/bdb/README b/modules_s/bdb/README
new file mode 100644
index 0000000..4817972
--- /dev/null
+++ b/modules_s/bdb/README
@@ -0,0 +1,199 @@
+1. BDB Module
+
+ Sippy Software, Inc.
+
+ Copyright � 2006 Sippy Software, Inc.
+ Revision History
+ Revision $Revision$ $Date$
+ __________________________________________________________________
+
+ 1.1. Overview
+
+ 1.1.1. Design of DBD Engine
+
+ 1.2. Dependencies
+
+ 1.2.1. External libraries or applications
+
+ 1.3. Exported parameters
+
+ 1.3.1. describe_table (string)
+
+ 1.4. Constrains and limitations
+ 1.5. Installation and running
+
+ 1.5.1. Using BDB With Basic SER Configuration
+
+1.1. Overview
+
+ The SER (SIP Express Router) supports several different persistent
+ storage backends (flatfile, dbtext and several SQL servers). However,
+ in certain cases those existing backends don't satisfy conditions.
+ Particularly, SQL server-based backends typically provide good
+ performance and scalability, but at the same time require considerable
+ efforts to configure and manage and also have significant memory and
+ on-disk footprint, while simpler storage backends (flatfile, dbtext)
+ are lighter and simpler to setup and manage, but scale poorly and don't
+ provide sufficient performance. For certain types of applications (i.e.
+ embedded SIP applications, SIP load balancing farms etc), different
+ solution that would combine some of the non-overlapping properties of
+ those two existing classes of backends is necessary.
+
+ Berkeley DB is widely regarded as industry-leading open source,
+ embeddable database engine that provides developers with fast,
+ reliable, local persistence with almost zero administration.
+
+1.1.1. Design of DBD Engine
+
+ The dbtext database system architecture:
+ * A database is represented by a directory in the local file system
+ where BDB environment is located.
+
+Note
+ When using BDB driver in SER, the database URL for modules must be
+ the path to the directory where the BDB environment is located,
+ prefixed by "bdb://", e.g., "bdb:///var/db/ser". If there is no "/"
+ after "bdb://" then "CFG_DIR/" (the OS-specific path defined at
+ SER's compile time) is inserted at the beginning of the database
+ path automatically. So that, either an absolute path to database
+ directory, or one relative to "CFG_DIR" directory should be
+ provided in the URL.
+ * The individual tables internaly are represented by binary files
+ inside environment directory.
+
+Note
+ The BDB driver uses BTree access method.
+ On-disk storage format has been developed to be as simple as
+ possible, while meeting performance requirements set forth above.
+ It is not compatible with on-disk format of any other BDB-based DB
+ engine (e.g. MySQL's BDB table handler).
+
+1.2. Dependencies
+
+1.2.1. External libraries or applications
+
+ The next libraries or applications must be installed before running SER
+ with this module:
+ * Berkeley DB 4.X
+
+1.3. Exported parameters
+
+1.3.1. describe_table (string)
+
+ Define the table and its structure. Each table that will be used by
+ other modules has to be defined. The format of the parameter is:
+ table_name:column_name_1(column_type_1)[column_name_2(column_type_2)[..
+ . column_name_N(column_type_N)]]
+
+ The names of table and columns must not include white spaces.
+
+ The first column in definition is used as index.
+
+ Between name of table and name of first column must be ":".
+
+ Between two columns definitions must be exactly one white space.
+
+ Type of column has to be enclosed into parentheses.
+
+ Supported column types are:
+ * int
+ * float
+ * double
+ * string
+ * str
+ * datetime
+ * blob
+ * bitmap
+
+1.4. Constrains and limitations
+
+ Use of indexes:
+ * Effective SELECT, UPDATE and DELETE operations on a structured
+ storage that contains any more or less decent number of records are
+ impossible without using some kind of indexing scheme. Since
+ Berkley DB is relatively simple storage engine it provides only
+ basic support for indexing, nearly not as rich as usually expected
+ by an average SQL user. Therefore, it has been decided to limit
+ number of indexes supported to one per table. This is sufficient
+ for most of the uses in the SER (for example: usrloc, auth_db etc).
+ * SELECT/UPDATE/DELETE records matching criteria. Due to its
+ simplicity, Berkley DB only supports exact match on indexed field.
+ In order to support <, >, <= and >= operations mandated by the SIP
+ DB API it is necessary to fall back to sequental scan of the index
+ values, which obviously has significant negative impact on
+ performance. Fortunately those advanced records matching criterias
+ are not required neither by the usrloc module nor by auth_db
+ module.
+ * BDB driver uses index only if key column appears in search clause
+ at least once and records matching operator associated with it is
+ '='.
+ * It is not allowed to set index value to NULL or an empty string.
+ * It is not allowed to update index value. The DELETE followed by
+ INSERT should be used instead.
+
+ BDB driver does not support db_raw_query() method.
+
+ BDB driver does not support ORDER BY clause of db_query() method.
+
+1.5. Installation and running
+
+ Compile the module and load it instead of mysql or other DB modules.
+
+ Example 1. Load the bdb module
+...
+loadmodule "/path/to/ser/modules/dbb.so"
+...
+modparam("module_name", "db_url", "bdb:///path/to/bdb/database")
+...
+
+ Example 2. definition of the standard version table
+...
+modparam("bdb", "describe_table", "version:table_name(str) table_version(int)")
+...
+
+1.5.1. Using BDB With Basic SER Configuration
+
+ Here are the definitions for tables used by usrloc module as well as a
+ part of basic configuration file to use BDB driver with SER. The table
+ structures may change in future releases, so that some adjustment to
+ example below may be necessary. That example corresponds to SER v0.9.4
+
+ According to the configuration file below, the table files will be
+ placed in the //var/db/ser/ directory.
+
+ The table version should be populated manually before the SER is
+ started. To do this version.dump file located in the directotry of BDB
+ driver sources and db_load utility from Berkeley BD distribution should
+ be used as follows:
+
+ Example 3. Population of version table
+$ db_load -h /var/db/ser -f version.dump version
+
+ Example 4. Configuration file
+# ---------- global configuration parameters ------------------------
+
+# [skip]
+
+# ---------- module loading -----------------------------------------
+
+loadmodule "/usr/local/lib/ser/modules/usrloc.so"
+loadmodule "/usr/local/lib/ser/modules/bdb.so"
+
+# ---------- module-specific configuration parameteres --------------
+
+modparam("usrloc", "db_mode", 2)
+modparam("usrloc", "timer_interval", 3)
+modparam("usrloc", "db_url", "bdb:///var/db/ser")
+
+modparam("bdb", "describe_table", "version:table_name(str) table_version(int)")
+
+modparam("bdb", "describe_table", "location:username(str) domain(str) contact(st
+r) i_env(int) expires(datetime) q(double) callid(str) cseq(int) method(str) flag
+s(int) user_agent(str) received(str)")
+modparam("bdb", "describe_table", "aliases:username(str) domain(str) contact(str
+) i_env(int) expires(datetime) q(double) callid(str) cseq(int) method(str) flags
+(int) user_agent(str) received(str)")
+
+# ---------- request routing logic ----------------------------------
+
+# [skip]
Module: sip-router
Branch: master
Commit: 45974eba796c4cf5d3b0888ce51634fe4109ed92
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=45974eb…
Author: Henning Westerholt <henning.westerholt(a)1und1.de>
Committer: Henning Westerholt <henning.westerholt(a)1und1.de>
Date: Thu Apr 30 18:20:23 2009 +0200
small spelling fix in docs and comment
---
forward.c | 2 +-
modules_s/auth/doc/params.xml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/forward.c b/forward.c
index 5fca78e..f651120 100644
--- a/forward.c
+++ b/forward.c
@@ -407,7 +407,7 @@ int forward_request(struct sip_msg* msg, str* dst, unsigned short port,
}
}
/* try to send the message until success or all the ips are exhausted
- * (if dns lookup is peformed && the dns cache used ) */
+ * (if dns lookup is performed && the dns cache used ) */
#ifdef USE_DNS_FAILOVER
do{
#endif
diff --git a/modules_s/auth/doc/params.xml b/modules_s/auth/doc/params.xml
index 8a84cac..403de2c 100644
--- a/modules_s/auth/doc/params.xml
+++ b/modules_s/auth/doc/params.xml
@@ -24,7 +24,7 @@
These three module parameters control which optional integrity
checks will be performed on the SIP message carrying digest response
during digest authentication. <varname>auth_check_register</varname>
- controls integrity checks to be peformed on REGISTER messages,
+ controls integrity checks to be performed on REGISTER messages,
<varname>auth_checks_no_dlg</varname> controls which optional
integrity checks will be performed on SIP requests that have no To
header field or no To tag (in other words the requests either