瀏覽代碼

- renamed: openser.cfg -> kamailio.cfg

git-svn-id: https://openser.svn.sourceforge.net/svnroot/openser/trunk@4577 689a6050-402a-0410-94f2-e92a70836424
Klaus Darilion 17 年之前
父節點
當前提交
ded7d2082b

+ 1 - 1
modules_k/cfgutils/README

@@ -156,7 +156,7 @@ modparam("cfgutils", "initial_probability", 15)
 
    Example 1.2. hash_file parameter usage
 
-modparam("cfgutils", "hash_file", "/etc/openser/openser.cfg")
+modparam("cfgutils", "hash_file", "/etc/openser/kamailio.cfg")
 
 
 1.3.3. shvset (string)

+ 1 - 1
modules_k/cfgutils/doc/cfgutils_admin.xml

@@ -91,7 +91,7 @@ modparam("cfgutils", "initial_probability", 15)
 		<title><varname>hash_file</varname> parameter usage</title>
 		<programlisting format="linespecific">
    
-modparam("cfgutils", "hash_file", "/etc/openser/openser.cfg")
+modparam("cfgutils", "hash_file", "/etc/openser/kamailio.cfg")
    
 </programlisting>
 	    </example>

+ 1 - 1
modules_k/domainpolicy/domainpolicy.h

@@ -52,7 +52,7 @@ int dp_can_connect(struct sip_msg* _msg, char* _s1, char* _s2);
 /*
  * Apply DP-DDDS policy to current SIP message. This means
  * build a new destination URI from the policy AVP and export it
- * as AVP. Then in openser.cfg this new target AVP can be pushed
+ * as AVP. Then in kamailio.cfg this new target AVP can be pushed
  * into the destination URI $duri
  */
 int dp_apply_policy(struct sip_msg* _msg, char* _s1, char* _s2);

+ 6 - 6
modules_k/lcr/README

@@ -344,7 +344,7 @@ modparam("lcr","priority_column","priority")
    of the destination set.
 
    There is NO default value, thus this variable must be defined
-   in openser.cfg.
+   in kamailio.cfg.
 
    Example 1.16. Setting contact_avp module parameter
 ...
@@ -358,7 +358,7 @@ modparam("lcr", "contact_avp", "$avp(i:711)")
    parameter.
 
    There is NO default value, thus this variable must be defined
-   in openser.cfg.
+   in kamailio.cfg.
 
    Example 1.17. Setting fr_inv_timer_avp module parameter
 ...
@@ -371,7 +371,7 @@ modparam("lcr|tm", "fr_inv_timer_avp", "$avp(i:704)")
    of matching gateways.
 
    There is NO default value, thus this variable must be defined
-   in openser.cfg.
+   in kamailio.cfg.
 
    Example 1.18. Setting gw_uri_avp module parameter
 ...
@@ -383,7 +383,7 @@ modparam("lcr", "gw_uri_avp", "$avp(i:709)")
    An AVP that contains caller's RPID (if any).
 
    There is NO default value, thus this variable must be defined
-   in openser.cfg.
+   in kamailio.cfg.
 
    Example 1.19. Setting rpid_avp module parameter
 ...
@@ -396,7 +396,7 @@ modparam("^auth$|lcr", "rpid_avp", "$avp(i:302)")
    user for subsequent next_gw calls.
 
    There is NO default value, thus this variable must be defined
-   in openser.cfg.
+   in kamailio.cfg.
 
    Example 1.20. Setting ruri_user_avp module parameter
 ...
@@ -438,7 +438,7 @@ modparam("lcr","fr_inv_timer_next",30)
    gateway's flags.
 
    There is NO default value, thus this variable must be defined
-   in openser.cfg.
+   in kamailio.cfg.
 
    Example 1.23. Setting flags_avp module parameter
 ...

+ 6 - 6
modules_k/lcr/doc/lcr_admin.xml

@@ -420,7 +420,7 @@ modparam("lcr","priority_column","priority")
 		<para>
 		<emphasis>
 			There is NO default value, thus this variable must
-			be defined in openser.cfg.
+			be defined in kamailio.cfg.
 		</emphasis>
 		</para>
 		<example>
@@ -443,7 +443,7 @@ modparam("lcr", "contact_avp", "$avp(i:711)")
 		<para>
 		<emphasis>
 			There is NO default value, thus this variable must
-			be defined in openser.cfg.
+			be defined in kamailio.cfg.
 		</emphasis>
 		</para>
 		<example>
@@ -465,7 +465,7 @@ modparam("lcr|tm", "fr_inv_timer_avp", "$avp(i:704)")
 		<para>
 		<emphasis>
 			There is NO default value, thus this variable must
-			be defined in openser.cfg.
+			be defined in kamailio.cfg.
 		</emphasis>
 		</para>
 		<example>
@@ -486,7 +486,7 @@ modparam("lcr", "gw_uri_avp", "$avp(i:709)")
 		<para>
 		<emphasis>
 			There is NO default value, thus this variable must
-			be defined in openser.cfg.
+			be defined in kamailio.cfg.
 		</emphasis>
 		</para>
 		<example>
@@ -508,7 +508,7 @@ modparam("^auth$|lcr", "rpid_avp", "$avp(i:302)")
 		<para>
 		<emphasis>
 			There is NO default value, thus this variable must
-			be defined in openser.cfg.
+			be defined in kamailio.cfg.
 		</emphasis>
 		</para>
 		<example>
@@ -578,7 +578,7 @@ modparam("lcr","fr_inv_timer_next",30)
 		<para>
 		<emphasis>
 			There is NO default value, thus this variable must
-			be defined in openser.cfg.
+			be defined in kamailio.cfg.
 		</emphasis>
 		</para>
 		<example>

+ 121 - 121
modules_k/perl/README

@@ -36,13 +36,13 @@ Bastian Friedrich
               1.6.1. perl_exec_simple(func, [param])
               1.6.2. perl_exec(func, [param])
 
-   2. OpenSER Perl API
+   2. Kamailio Perl API
 
-        2.1. OpenSER
+        2.1. Kamailio
 
               2.1.1. log(level,message)
 
-        2.2. OpenSER::Message
+        2.2. Kamailio::Message
 
               2.2.1. getType()
               2.2.2. getStatus()
@@ -67,7 +67,7 @@ Bastian Friedrich
               2.2.21. next_branches()
               2.2.22. getParsedRURI()
 
-        2.3. OpenSER::URI
+        2.3. Kamailio::URI
 
               2.3.1. user()
               2.3.2. host()
@@ -90,13 +90,13 @@ Bastian Friedrich
               2.3.19. lr_val()
               2.3.20. r2_val()
 
-        2.4. OpenSER::AVP
+        2.4. Kamailio::AVP
 
               2.4.1. add(name,val)
               2.4.2. get(name)
               2.4.3. destroy(name)
 
-        2.5. OpenSER::Utils::PhoneNumbers
+        2.5. Kamailio::Utils::PhoneNumbers
 
               2.5.1.
                       new(publicAccessPrefix,internationalPrefix,lon
@@ -106,7 +106,7 @@ Bastian Friedrich
               2.5.2. canonicalForm( number [, context] )
               2.5.3. dialNumber( number [, context] )
 
-        2.6. OpenSER::LDAPUtils::LDAPConf
+        2.6. Kamailio::LDAPUtils::LDAPConf
 
               2.6.1. Constructor new()
               2.6.2. Method base()
@@ -118,51 +118,51 @@ Bastian Friedrich
               2.6.8. Method binddn()
               2.6.9. Method bindpw()
 
-        2.7. OpenSER::LDAPUtils::LDAPConnection
+        2.7. Kamailio::LDAPUtils::LDAPConnection
 
               2.7.1. Constructor new( [config, [authenticated]] )
               2.7.2. Function/Method search( conf, filter, base,
                       [requested_attributes ...])
 
-        2.8. OpenSER::VDB
-        2.9. OpenSER::Constants
-        2.10. OpenSER::VDB::Adapter::Speeddial
-        2.11. OpenSER::VDB::Adapter::Alias
+        2.8. Kamailio::VDB
+        2.9. Kamailio::Constants
+        2.10. Kamailio::VDB::Adapter::Speeddial
+        2.11. Kamailio::VDB::Adapter::Alias
 
               2.11.1. query(conds,retkeys,order)
 
-        2.12. OpenSER::VDB::Adapter::AccountingSIPtrace
-        2.13. OpenSER::VDB::Adapter::Describe
-        2.14. OpenSER::VDB::Adapter::Auth
-        2.15. OpenSER::VDB::ReqCond
+        2.12. Kamailio::VDB::Adapter::AccountingSIPtrace
+        2.13. Kamailio::VDB::Adapter::Describe
+        2.14. Kamailio::VDB::Adapter::Auth
+        2.15. Kamailio::VDB::ReqCond
 
               2.15.1. new(key,op,type,name)
               2.15.2. op()
 
-        2.16. OpenSER::VDB::Pair
+        2.16. Kamailio::VDB::Pair
 
               2.16.1. new(key,type,name)
               2.16.2. key()
 
-        2.17. OpenSER::VDB::VTab
+        2.17. Kamailio::VDB::VTab
 
               2.17.1. new()
               2.17.2. call(op,[args])
 
-        2.18. OpenSER::VDB::Value
+        2.18. Kamailio::VDB::Value
 
               2.18.1. stringification
               2.18.2. new(type,data)
               2.18.3. type()
               2.18.4. data()
 
-        2.19. OpenSER::VDB::Column
+        2.19. Kamailio::VDB::Column
 
               2.19.1. Stringification
               2.19.2. new(type,name)
               2.19.3. type( )
               2.19.4. name()
-              2.19.5. OpenSER::VDB::Result
+              2.19.5. Kamailio::VDB::Result
               2.19.6. new(coldefs,[row, row, ...])
               2.19.7. coldefs()
               2.19.8. rows()
@@ -186,12 +186,12 @@ Chapter 1. Admin Guide
 
 1.1. Overview
 
-   The time needed when writing a new OpenSER module unfortunately
+   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.
 
    With this Perl module, you can easily implement your own
-   OpenSER extensions in Perl. This allows for simple access to
+   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
@@ -199,7 +199,7 @@ Chapter 1. Admin Guide
 
 1.2. Installing the module
 
-   This Perl module is loaded in openser.cfg (just like all the
+   This Perl module is loaded in kamailio.cfg (just like all the
    other modules) with loadmodule("/path/to/perl.so");.
 
    For the Perl module to compile, you need a reasonably recent
@@ -222,9 +222,9 @@ Utils/typemap"
 1.3. Using the module
 
    The Perl module has two interfaces: The perl side, and the
-   OpenSER side. Once a Perl function is defined and loaded via
+   Kamailio side. Once a Perl function is defined and loaded via
    the module parameters (see below), it may be called in
-   OpenSER's configuration at an arbitary point. E.g., you could
+   Kamailio's configuration at an arbitary point. E.g., you could
    write a function "ldap_alias" in Perl, and then execute
 ...
 if (perl_exec("ldap_alias")) {
@@ -258,7 +258,7 @@ if (perl_exec("ldap_alias")) {
      * Perl 5.8.x or later
 
    Additionally, a number of perl modules should be installed. The
-   OpenSER::LDAPUtils package relies on Net::LDAP to be installed.
+   Kamailio::LDAPUtils package relies on Net::LDAP to be installed.
    One of the sample scripts needs IPC::Shareable
 
    This module has been developed and tested with Perl 5.8.8, but
@@ -307,7 +307,7 @@ modparam("perl", "filename", "/home/john/openser/myperl.pl")
 
 1.5.2. modpath (string)
 
-   The path to the Perl modules included (OpenSER.pm et.al). It is
+   The path to the Perl modules included (Kamailio.pm et.al). It is
    not absolutely crucial to set this path, as you may install the
    Modules in Perl's standard path, or update the "%INC" variable
    from within your script. Using this module parameter is the
@@ -345,7 +345,7 @@ if (method=="INVITE") {
    Calls a perl function with passing it the current SIP message.
    The SIP message is reflected by a Perl module that gives you
    access to the information in the current SIP message
-   (OpenSER::Message).
+   (Kamailio::Message).
 
    The first parameter is the function to be called. An arbitrary
    string may be passed as a parameter.
@@ -360,17 +360,17 @@ if (perl_exec("ldapalias")) {
 };
 ...
 
-Chapter 2. OpenSER Perl API
+Chapter 2. Kamailio Perl API
 
-2.1. OpenSER
+2.1. Kamailio
 
-   This module provides access to a limited number of OpenSER core
+   This module provides access to a limited number of Kamailio core
    functions. As the most interesting functions deal with SIP
-   messages, they are located in the OpenSER::Message class below.
+   messages, they are located in the Kamailio::Message class below.
 
 2.1.1. log(level,message)
 
-   Logs the message with OpenSER's logging facility. The logging
+   Logs the message with Kamailio's logging facility. The logging
    level is one of the following:
 * L_ALERT
 * L_CRIT
@@ -383,12 +383,12 @@ Chapter 2. OpenSER Perl API
    Please note that this method is NOT automatically exported, as
    it collides with the perl function log (which calculates the
    logarithm). Either explicitly import the function (via use
-   OpenSER qw ( log );), or call it with its full name:
-OpenSER::log(L_INFO, "foobar");
+   Kamailio qw ( log );), or call it with its full name:
+Kamailio::log(L_INFO, "foobar");
 
-2.2. OpenSER::Message
+2.2. Kamailio::Message
 
-   This package provides access functions for an OpenSER sip_msg
+   This package provides access functions for an Kamailio sip_msg
    structure and its sub-components. Through its means it is
    possible to fully configure alternative routing decisions.
 
@@ -468,7 +468,7 @@ OpenSER::log(L_INFO, "foobar");
    string1 and/or string2 may be omitted.
 
    As this function provides access to the functions that are
-   exported to the OpenSER configuration file, it is autoloaded
+   exported to the Kamailio configuration file, it is autoloaded
    for unknown functions. Instead of writing
 $m->moduleFunction("sl_send_reply", "500", "Internal Error");
 $m->moduleFunction("xlog", "L_INFO", "foo");
@@ -479,7 +479,7 @@ $m->xlog("L_INFO", "foo");
 
    WARNING
 
-   In OpenSER 1.2, only a limited subset of module functions is
+   In Kamailio 1.2, only a limited subset of module functions is
    available. This restriction will be removed in a later version.
 
    Here is a list of functions that are expected to be working
@@ -581,7 +581,7 @@ $m->xlog("L_INFO", "foo");
 
 2.2.13. log(level,message) (deprecated type)
 
-   Logs the message with OpenSER's logging facility. The logging
+   Logs the message with Kamailio's logging facility. The logging
    level is one of the following:
 * L_ALERT
 * L_CRIT
@@ -591,8 +591,8 @@ $m->xlog("L_INFO", "foo");
 * L_INFO
 * L_DBG
 
-   The logging function should be accessed via the OpenSER module
-   variant. This one, located in OpenSER::Message, is deprecated.
+   The logging function should be accessed via the Kamailio module
+   variant. This one, located in Kamailio::Message, is deprecated.
 
 2.2.14. rewrite_ruri(newruri)
 
@@ -638,9 +638,9 @@ if ($m->getRURI() =~ m/\@somedomain.net/) {
 
 2.2.22. getParsedRURI()
 
-   Returns the current destination URI as an OpenSER::URI object.
+   Returns the current destination URI as an Kamailio::URI object.
 
-2.3. OpenSER::URI
+2.3. Kamailio::URI
 
    This package provides functions for access to sip_uri
    structures.
@@ -725,9 +725,9 @@ if ($m->getRURI() =~ m/\@somedomain.net/) {
 
    Returns the r2_val part of this URI.
 
-2.4. OpenSER::AVP
+2.4. Kamailio::AVP
 
-   This package provides access functions for OpenSER's AVPs.
+   This package provides access functions for Kamailio's AVPs.
    These variables can be created, evaluated, modified and removed
    through this package.
 
@@ -739,13 +739,13 @@ if ($m->getRURI() =~ m/\@somedomain.net/) {
 
    Add an AVP.
 
-   Add an OpenSER AVP to its environment. name and val may both be
+   Add an Kamailio AVP to its environment. name and val may both be
    integers or strings; this function will try to guess what is
    correct. Please note that
-OpenSER::AVP::add("10", "10")
+Kamailio::AVP::add("10", "10")
 
    is something different than
-OpenSER::AVP::add(10, 10)
+Kamailio::AVP::add(10, 10)
 
    due to this evaluation: The first will create _string_ AVPs
    with the name 10, while the latter will create a numerical AVP.
@@ -754,23 +754,23 @@ OpenSER::AVP::add(10, 10)
 
 2.4.2. get(name)
 
-   get an OpenSER AVP:
-my $numavp = OpenSER::AVP::get(5);
-my $stravp = OpenSER::AVP::get("foo");
+   get an Kamailio AVP:
+my $numavp = Kamailio::AVP::get(5);
+my $stravp = Kamailio::AVP::get("foo");
 
 2.4.3. destroy(name)
 
    Destroy an AVP.
-OpenSER::AVP::destroy(5);
-OpenSER::AVP::destroy("foo");
+Kamailio::AVP::destroy(5);
+Kamailio::AVP::destroy("foo");
 
-2.5. OpenSER::Utils::PhoneNumbers
+2.5. Kamailio::Utils::PhoneNumbers
 
-   OpenSER::Utils::PhoneNumbers - Functions for canonical forms of
+   Kamailio::Utils::PhoneNumbers - Functions for canonical forms of
    phone numbers.
-use OpenSER::Utils::PhoneNumbers;
+use Kamailio::Utils::PhoneNumbers;
 
-my $phonenumbers = new OpenSER::Utils::PhoneNumbers(
+my $phonenumbers = new Kamailio::Utils::PhoneNumbers(
      publicAccessPrefix => "0",
      internationalPrefix => "+",
      longDistancePrefix => "0",
@@ -823,7 +823,7 @@ countryCode,areaCode,pbxCode)
 
    The new operator returns an object of this type and sets its
    locational context according to the passed parameters. See
-   OpenSER::Utils::PhoneNumbers above.
+   Kamailio::Utils::PhoneNumbers above.
 
 2.5.2. canonicalForm( number [, context] )
 
@@ -839,12 +839,12 @@ countryCode,areaCode,pbxCode)
    second argument, a default context from the systems
    configuration is used.
 
-2.6. OpenSER::LDAPUtils::LDAPConf
+2.6. Kamailio::LDAPUtils::LDAPConf
 
-   OpenSER::LDAPUtils::LDAPConf - Read openldap config from
+   Kamailio::LDAPUtils::LDAPConf - Read openldap config from
    standard config files.
-use OpenSER::LDAPUtils::LDAPConf;
-my $conf = new OpenSER::LDAPUtils::LDAPConf();
+use Kamailio::LDAPUtils::LDAPConf;
+my $conf = new Kamailio::LDAPUtils::LDAPConf();
 
    This module may be used to retrieve the global LDAP
    configuration as used by other LDAP software, such as
@@ -856,7 +856,7 @@ my $conf = new OpenSER::LDAPUtils::LDAPConf();
 
 2.6.1. Constructor new()
 
-   Returns a new, initialized OpenSER::LDAPUtils::LDAPConf object.
+   Returns a new, initialized Kamailio::LDAPUtils::LDAPConf object.
 
 2.6.2. Method base()
 
@@ -900,20 +900,20 @@ my $conf = new OpenSER::LDAPUtils::LDAPConf();
    server. When no bind password has been specified, returns the
    rootbindpw if any.
 
-2.7. OpenSER::LDAPUtils::LDAPConnection
+2.7. Kamailio::LDAPUtils::LDAPConnection
 
-   OpenSER::LDAPUtils::LDAPConnection - Perl module to perform
+   Kamailio::LDAPUtils::LDAPConnection - Perl module to perform
    simple LDAP queries.
 
    OO-Style interface:
-use OpenSER::LDAPUtils::LDAPConnection;
-my $ldap = new OpenSER::LDAPUtils::LDAPConnection;
+use Kamailio::LDAPUtils::LDAPConnection;
+my $ldap = new Kamailio::LDAPUtils::LDAPConnection;
 my @rows = $ldap-search("uid=andi","ou=people,ou=coreworks,ou=de");
 
    Procedural interface:
-use OpenSER::LDAPUtils::LDAPConnection;
+use Kamailio::LDAPUtils::LDAPConnection;
 my @rows = $ldap->search(
-      new OpenSER::LDAPUtils::LDAPConfig(), "uid=andi","ou=people,ou=cor
+      new Kamailio::LDAPUtils::LDAPConfig(), "uid=andi","ou=people,ou=cor
 eworks,ou=de");
 
    This perl module offers a somewhat simplified interface to the
@@ -927,9 +927,9 @@ eworks,ou=de");
 
    The first argument, when given, should be a hash reference
    pointing to to the connection parameters, possibly an
-   OpenSER::LDAPUtils::LDAPConfig object. This argument may be
+   Kamailio::LDAPUtils::LDAPConfig object. This argument may be
    undef in which case a new (default)
-   OpenSER::LDAPUtils::LDAPConfig object is used.
+   Kamailio::LDAPUtils::LDAPConfig object is used.
 
    When the optional second argument is a true value, the
    connection will be authenticated. Otherwise an anonymous bind
@@ -947,14 +947,14 @@ eworks,ou=de");
    returned.
 
    When the first argument (conf) is a
-   OpenSER::LDAPUtils::LDAPConnection, it will be used to perform
+   Kamailio::LDAPUtils::LDAPConnection, it will be used to perform
    the queries. You can pass the first argument implicitly by
    using the "method" syntax.
 
    Otherwise the conf argument should be a reference to a hash
    containing the connection setup parameters as contained in a
-   OpenSER::LDAPUtils::LDAPConf object. In this mode, the
-   OpenSER::LDAPUtils::LDAPConnection from previous queries will
+   Kamailio::LDAPUtils::LDAPConf object. In this mode, the
+   Kamailio::LDAPUtils::LDAPConnection from previous queries will
    be reused.
 
 2.7.2.1. Arguments:
@@ -984,27 +984,27 @@ eworks,ou=de");
    those attibutes. When multiple entries match the query, the
    attribute lists are concatenated.
 
-2.8. OpenSER::VDB
+2.8. Kamailio::VDB
 
    This package is an (abstract) base class for all virtual
    databases. Derived packages can be configured to be used by
-   OpenSER as a database.
+   Kamailio as a database.
 
    The base class itself should NOT be used in this context, as it
    does not provide any functionality.
 
-2.9. OpenSER::Constants
+2.9. Kamailio::Constants
 
    This package provides a number of constants taken from enums
-   and defines of OpenSER header files. Unfortunately, there is no
+   and defines of Kamailio header files. Unfortunately, there is no
    mechanism for updating the constants automatically, so check
    the values if you are in doubt.
 
-2.10. OpenSER::VDB::Adapter::Speeddial
+2.10. Kamailio::VDB::Adapter::Speeddial
 
    This adapter can be used with the speeddial module.
 
-2.11. OpenSER::VDB::Adapter::Alias
+2.11. Kamailio::VDB::Adapter::Alias
 
    This package is intended for usage with the alias_db module.
    The query VTab has to take two arguments and return an array of
@@ -1015,12 +1015,12 @@ eworks,ou=de");
    Queries the vtab with the given arguments for request
    conditions, keys to return and sort order column name.
 
-2.12. OpenSER::VDB::Adapter::AccountingSIPtrace
+2.12. Kamailio::VDB::Adapter::AccountingSIPtrace
 
    This package is an Adapter for the acc and siptrace modules,
    featuring only an insert operation.
 
-2.13. OpenSER::VDB::Adapter::Describe
+2.13. Kamailio::VDB::Adapter::Describe
 
    This package is intended for debug usage. It will print
    information about requested functions and operations of a
@@ -1029,19 +1029,19 @@ eworks,ou=de");
    Use this module to request schema information when creating new
    adapters.
 
-2.14. OpenSER::VDB::Adapter::Auth
+2.14. Kamailio::VDB::Adapter::Auth
 
    This adapter is intended for usage with the auth_db module. The
    VTab should take a username as an argument and return a (plain
    text!) password.
 
-2.15. OpenSER::VDB::ReqCond
+2.15. Kamailio::VDB::ReqCond
 
    This package represents a request condition for database
    access, consisting of a column name, an operator (=, <, >,
    ...), a data type and a value.
 
-   This package inherits from OpenSER::VDB::Pair and thus includes
+   This package inherits from Kamailio::VDB::Pair and thus includes
    its methods.
 
 2.15.1. new(key,op,type,name)
@@ -1052,12 +1052,12 @@ eworks,ou=de");
 
    Returns or sets the current operator.
 
-2.16. OpenSER::VDB::Pair
+2.16. Kamailio::VDB::Pair
 
    This package represents database key/value pairs, consisting of
    a key, a value type, and the value.
 
-   This package inherits from OpenSER::VDB::Value and thus has the
+   This package inherits from Kamailio::VDB::Value and thus has the
    same methods.
 
 2.16.1. new(key,type,name)
@@ -1068,10 +1068,10 @@ eworks,ou=de");
 
    Returns or sets the current key.
 
-2.17. OpenSER::VDB::VTab
+2.17. Kamailio::VDB::VTab
 
    This package handles virtual tables and is used by the
-   OpenSER::VDB class to store information about valid tables. The
+   Kamailio::VDB class to store information about valid tables. The
    package is not inteded for end user access.
 
 2.17.1. new()
@@ -1083,27 +1083,27 @@ Constructs a new VTab object
    Invokes an operation on the table (insert, update, ...) with
    the given arguments.
 
-2.18. OpenSER::VDB::Value
+2.18. Kamailio::VDB::Value
 
    This package represents a database value. Additional to the
    data itself, information about its type is stored.
 
 2.18.1. stringification
 
-   When accessing a OpenSER::VDB::Value object as a string, it
+   When accessing a Kamailio::VDB::Value object as a string, it
    simply returns its data regardless of its type. =cut
 
    use strict;
 
-   package OpenSER::VDB::Value;
+   package Kamailio::VDB::Value;
 
    use overload '""' => \&stringify;
 
    sub stringify { shift->{data} }
 
-   use OpenSER; use OpenSER::Constants;
+   use Kamailio; use Kamailio::Constants;
 
-   our @ISA = qw ( OpenSER::Utils::Debug );
+   our @ISA = qw ( Kamailio::Utils::Debug );
 
 2.18.2. new(type,data)
 
@@ -1113,31 +1113,31 @@ Constructs a new VTab object
 2.18.3. type()
 
    Returns or sets the current data type. Please consider using
-   the constants from OpenSER::Constants
+   the constants from Kamailio::Constants
 
 2.18.4. data()
 
    Returns or sets the current data.
 
-2.19. OpenSER::VDB::Column
+2.19. Kamailio::VDB::Column
 
    This package represents database column definition, consisting
    of a column name and its data type.
 
 2.19.1. Stringification
 
-   When accessing a OpenSER::VDB::Column object as a string, it
+   When accessing a Kamailio::VDB::Column object as a string, it
    simply returns its column name regardless of its type. =cut
 
-   package OpenSER::VDB::Column;
+   package Kamailio::VDB::Column;
 
    use overload '""' => \&stringify;
 
    sub stringify { shift->{name} }
 
-   use OpenSER; use OpenSER::Constants;
+   use Kamailio; use Kamailio::Constants;
 
-   our @ISA = qw ( OpenSER::Utils::Debug );
+   our @ISA = qw ( Kamailio::Utils::Debug );
 
 2.19.2. new(type,name)
 
@@ -1147,13 +1147,13 @@ Constructs a new VTab object
 2.19.3. type( )
 
    Returns or sets the current type. Please consider using the
-   constants from OpenSER::Constants
+   constants from Kamailio::Constants
 
 2.19.4. name()
 
    Returns or sets the current column name.
 
-2.19.5. OpenSER::VDB::Result
+2.19.5. Kamailio::VDB::Result
 
    This class represents a VDB result set. It contains a column
    definition, plus an array of rows. Rows themselves are simply
@@ -1162,7 +1162,7 @@ Constructs a new VTab object
 2.19.6. new(coldefs,[row, row, ...])
 
    The constructor creates a new Result object. Its first
-   parameter is a reference to an array of OpenSER::VDB::Column
+   parameter is a reference to an array of Kamailio::VDB::Column
    objects. Additional parameters may be passed to provide initial
    rows, which are references to arrays of scalars.
 
@@ -1199,7 +1199,7 @@ Chapter 3. Perl samples
    The minimal function in branches.pl demonstrates that you can
    access the "append_branch" function from within perl, just as
    you would have done from your normal configuration file. You'll
-   find documentation on the concepts of branching in the OpenSER
+   find documentation on the concepts of branching in the Kamailio
    documentation.
 
 3.1.1.2. firstline.pl
@@ -1211,9 +1211,9 @@ Chapter 3. Perl samples
 
 3.1.1.3. flags.pl
 
-   The perl module provides access to OpenSER's flagging
-   mechanism. The flag names available for OpenSER modules are
-   made available through the OpenSER::Constants package, so you
+   The perl module provides access to Kamailio's flagging
+   mechanism. The flag names available for Kamailio modules are
+   made available through the Kamailio::Constants package, so you
    can flag messages as "green", "magenta" etc.
 
    The first function, setflag, demonstrates how the "green" flag
@@ -1224,7 +1224,7 @@ Chapter 3. Perl samples
 
    This sample script demonstrates different things related to
    calling functions from within perl, and the different types of
-   functions you can offer for OpenSER access.
+   functions you can offer for Kamailio access.
 
    "exportedfuncs" simply demonstrates that you can use the
    moduleFunction method to call functions offered by other
@@ -1235,19 +1235,19 @@ Chapter 3. Perl samples
    addresses are passed to the alias_db module.
 
    Please note that the moduleFunction method is not fully
-   available in OpenSER 1.2. See the method's documentation for
+   available in Kamailio 1.2. See the method's documentation for
    details.
 
    "paramfunc" shows that you can pass arbitrary strings to perl
    functions. Do with them whatever you want :)
 
    "autotest" demonstrates that unknown functions in
-   OpenSER::Message objects are automatically transformed into
+   Kamailio::Message objects are automatically transformed into
    calls to module functions.
 
    The "diefunc"s show that dying perl scripts - by "manual"
-   dying, or because of script errors - are handled by the OpenSER
-   package. The error message is logged through OpenSER's logging
+   dying, or because of script errors - are handled by the Kamailio
+   package. The error message is logged through Kamailio's logging
    mechanism. Please note that this only works correctly if you do
    NOT overwrite the default die handler. Oh, yes, that works for
    warnings, too.
@@ -1269,15 +1269,15 @@ Chapter 3. Perl samples
 
    For debugging purposes, you probably want to write messages to
    the syslog. The "logdemo" shows three ways to access the
-   OpenSER log function: it is available through the OpenSER class
-   as well as through the OpenSER::Message class.
+   Kamailio log function: it is available through the Kamailio class
+   as well as through the Kamailio::Message class.
 
    Remember that you can use exported functions from other
    modules. You may thus as well use the "xlog" module and it's
    xlog function.
 
    The L_INFO, L_DBG, L_ERR, L_CRIT... constants are available
-   through the OpenSER::Constants package.
+   through the Kamailio::Constants package.
 
 3.1.1.7. messagedump.pl
 
@@ -1292,13 +1292,13 @@ Chapter 3. Perl samples
    data across multiple calls to your Perl functions. Your first
    option is to use global variables in your script.
    Unfortunately, these globals are not visible from the mulitple
-   instances of OpenSER. You may want to use a mechanism such as
+   instances of Kamailio. You may want to use a mechanism such as
    the IPC::Shareable shared memory access package to correct
    this.
 
 3.1.1.9. phonenumbers.pl
 
-   The OpenSER::Utils::PhoneNumbers package provides two methods
+   The Kamailio::Utils::PhoneNumbers package provides two methods
    for the transformation of local to canonical telephone numbers,
    and vice versa. This script demonstrates it's use.
 
@@ -1322,14 +1322,14 @@ Chapter 4. Frequently Asked Questions
        regarded as bugs.
          * Missing module functions. Not all functions of other
            modules are available for Perl access. The reason for this
-           is a design property of OpenSER. Making available more
+           is a design property of Kamailio. Making available more
            functions is work in progress.
          * Perl and threads. Perl itself is, when compiled with the
            correct parameters, thread safe; unfortunately, not all
            Perl modules are. The DBI modules, especially (but not
            restricted to) DBI::ODBC are known NOT to be thread safe.
            Using DBI::ODBC -- and possibly other non-thread-safe Perl
-           extensions -- may result in erroneous behavior of OpenSER,
+           extensions -- may result in erroneous behavior of Kamailio,
            including (but not restricted to) server crashes and wrong
            routing.
 

+ 8 - 8
modules_k/perl/doc/perl_admin.xml

@@ -7,12 +7,12 @@
 	<section>
 		<title>Overview</title>
 		<para>
-		The time needed when writing a new OpenSER 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 OpenSER 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.
@@ -21,7 +21,7 @@
 	<section>
 		<title>Installing the module</title>
 		<para>
-		This Perl module is loaded in openser.cfg (just like all the other modules) with
+		This Perl module is loaded in kamailio.cfg (just like all the other modules) with
 		loadmodule("/path/to/perl.so");.
 		</para>
 
@@ -49,9 +49,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 OpenSER 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 OpenSER'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")) {
@@ -101,7 +101,7 @@ if (perl_exec("ldap_alias")) {
 			</para>
 			</listitem>
 		</itemizedlist>
-		Additionally, a number of perl modules should be installed. The OpenSER::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>
@@ -167,7 +167,7 @@ modparam("perl", "filename", "/home/john/openser/myperl.pl")
 		<section>
 			<title><varname>modpath</varname> (string)</title>
 			<para>
-			The path to the Perl modules included (OpenSER.pm et.al). It is not absolutely
+			The path to the Perl modules included (Kamailio.pm et.al). It is not absolutely
 			crucial to set this path,
 			as you <emphasis>may</emphasis> install the Modules in Perl's standard path, or update
 			the <quote>%INC</quote> variable from within your script. Using this module parameter
@@ -221,7 +221,7 @@ if (method=="INVITE") {
 			<para>
 			Calls a perl function <emphasis>with</emphasis> passing it the current SIP message.
 			The SIP message is reflected by a Perl module that gives you access to the information
-			in the current SIP message (OpenSER::Message).
+			in the current SIP message (Kamailio::Message).
 			</para>
 			<para>
 			The first parameter is the function to be called.

+ 52 - 52
modules_k/seas/README

@@ -77,19 +77,19 @@ Chapter 1. The Sip Express Application Server User's Guide
 
 1.1.1. Sip Express Application Server module overview
 
-   SEAS module enables OpenSER to transfer the execution logic
+   SEAS module enables Kamailio to transfer the execution logic
    control of a sip message to a given external entity, called the
-   Application Server. When the OpenSER script is being executed
+   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 OpenSER to take some actions, ie. forward the
+   code, and tells Kamailio to take some actions, ie. forward the
    message downstream, or respond to the message with a SIP repy,
    etc.
 
    The module acts implements a network protocol acting as the
-   interface between OpenSER internal API and the external
+   interface between Kamailio internal API and the external
    Application Server entity.
 
    There's only one relevant function, as_relay_t, exported by
@@ -113,15 +113,15 @@ Chapter 1. The Sip Express Application Server User's Guide
    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
-   OpenSER core, while the execution of the Application Logic is
+   Kamailio core, while the execution of the Application Logic is
    carried in the Application Server.
 
    The SEAS module and protocol provide a means by which an
-   external entity can utilize OpenSER 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 OpenSER, and this external entity
-   can then order OpenSER to execute some actions, either replying
+   whenever a 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.
 
    This version of SEAS works with VozTelecom's WeSIP Application
@@ -129,14 +129,14 @@ Chapter 1. The Sip Express Application Server User's Guide
 
 1.1.2. Application Servers
 
-   When OpenSER starts and SEAS module is loaded, a new process is
+   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
-   OpenSER can relay messages to them. When an Application Server
+   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
-   OpenSER script, invoking as_relay_t() receives a string as a
+   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
@@ -145,7 +145,7 @@ Chapter 1. The Sip Express Application Server User's Guide
 
 1.1.3. Dependencies
 
-1.1.3.1. OpenSER Modules
+1.1.3.1. Kamailio Modules
 
    SEAS module relies on the Transaction Module (TM module) for
    operation.
@@ -153,7 +153,7 @@ Chapter 1. The Sip Express Application Server User's Guide
 1.1.3.2. External Applications
 
    Using the SEAS module requires to have an Application Server
-   running and connected to a particular instance of OpenSER.
+   running and connected to a particular instance of Kamailio.
 
    At the moment, the only Application Server that works with SEAS
    is WeSIP Application Server, which can be downloaded from
@@ -170,7 +170,7 @@ Chapter 1. The Sip Express Application Server User's Guide
    be configured to connect to that port.
 
    In case this parameter is ommited, SEAS listens on the default
-   IP which OpenSER 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.
 
    Example 1.1. Set listen_sockets parameter
@@ -185,7 +185,7 @@ modparam("seas", "listen_sockets","127.0.0.1:5080")
    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 OpenSER through the SEAS
+   Application Server connected to Kamailio through the SEAS
    module, must be identified with a different name.
 
    This function can be used within REQUEST_ROUTE.
@@ -200,14 +200,14 @@ t_reply("500","App Server not connected");
 
 1.1.5.1.1. Return value
 
-   In case the Application Server is connected to OpenSER, the
+   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.
 
    In case the Application Server identified by the string
-   parameter passed to as_relay_t() is not connected to OpenSER,
+   parameter passed to as_relay_t() is not connected to Kamailio,
    the function returns 0, so that the script can continue
    processing the request.
 
@@ -489,17 +489,17 @@ addresses="localhost:5060"
 
    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 OpenSER listens for the
-   messages, so in fact, OpenSER is listening on them, but OpenSER
+   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.
 
 Warning
 
    this attribute MUST match one of the listening points declared
-   within OpenSER in the "listen" parameters.
+   within Kamailio in the "listen" parameters.
 
-   For example in openser.cfg:
+   For example in kamailio.cfg:
 listen = tcp:localhost:5060
 listen = udp:localhost:5060
 
@@ -509,28 +509,28 @@ listen = udp:localhost:5060
    Each property is specified by a key and a value. The most
    significant keys are:
      * com.voztele.javax.sip.SER_ADDRESS
-       This specifies the IP and port in which the OpenSER is
+       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
-       OpenSER is listening for Application Servers to connect and
+       Kamailio is listening for Application Servers to connect and
        register.
 
 Warning
        This needs to match the listen_sockets seas module
-       parameter within the OpenSER configuration file. Ie.:
+       parameter within the Kamailio configuration file. Ie.:
 modparam("seas", "listen_sockets","127.0.0.1:5080")
      * javax.sip.STACK_NAME
        Specifies the name identifying this instance of the
        Application Server.
 
 Warning
-       This is the name you will set in the OpenSER configuration
+       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 OpenSER, they
+       WeSIP instances all connecting to the same Kamailio, they
        must each one have a different STACK_NAME", and within
-       OpenSER you can call each of them by invoking as_relay_t()
+       Kamailio you can call each of them by invoking as_relay_t()
        with a different name. Example:
 <Property key="javax.sip.STACK_NAME" value="app_server_one" />
      * com.voztele.javax.sip.THREAD_POOL_SIZE (integer)
@@ -542,7 +542,7 @@ Warning
        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 OpenSER script, so that
+       messages pass again through the Kamailio script, so that
        they can be accounted or whatever the configurator wants.
        For example, the configuration script could go:
 route{
@@ -606,7 +606,7 @@ route{
    hosting is not done in 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 OpenSER listen parameters and
+   hostname _and_ port" specified 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
@@ -620,7 +620,7 @@ route{
    "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 OpenSER parameter "listen_sockets" (for the seas
+   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
@@ -638,21 +638,21 @@ route{
 
 1.2.3. Configuration Examples
 
-   In general, you can configure WeSIP to work with your OpenSER
-   in two ways: have 2 OpenSER instances, the first acting as
+   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 OpenSER works as usual, and the
+   deployment layout, as the first Kamailio works as usual, and the
    requests that need special services are relaied to another
-   OpenSER which acts on behalf of the WeSIP AS. This
+   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
-   OpenSER, having one script handle all the logic, and then
+   Kamailio, having one script handle all the logic, and then
    invoking the App Server at any point.
 
-1.2.3.1. Openser.cfg in standalone
+1.2.3.1. kamailio.cfg in standalone
 
 debug=3            # debug level (cmd line: -dddddddddd)
 fork=yes
@@ -716,7 +716,7 @@ route[1] {
                }
 }
 
-1.2.3.2. Openser.cfg working as WeSIP front-end
+1.2.3.2. kamailio.cfg working as WeSIP front-end
 
 debug=9            # debug level (cmd line: -dddddddddd)
 fork=yes
@@ -798,7 +798,7 @@ Chapter 2. Developer Guide
 2.1. Internals
 
    The SEAS module runs within the Open Sip Express Router aka.
-   OpenSER. OpenSER uses a pool of processes to execute the script
+   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
@@ -815,26 +815,26 @@ Chapter 2. Developer Guide
    memory segment, and write the address of that segment to a pipe
    (4 bytes pointer in IA32).
 
-   This way, we will have all the OpenSER processes composing the
+   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.
 
-   At the initialization of OpenSER, the SEAS module creates the
-   discussed pipe, so that all the OpenSER worker processes
+   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.
 
-   Each Application Server wishing to receive events from OpenSER,
+   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 OpenSER
+   register it in its internal structures, so that the Kamailio
    processes can push events for it. The following picture, shows
    the internals of the SEAS Event dispatcher process:
 
@@ -859,26 +859,26 @@ Chapter 2. Developer Guide
    efficiently, because parsing of text headers requires a lot of
    state.
 
-   OpenSER implements a very efficient parsing mechanism and
+   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
-   OpenSER, so that it can be reused at the Application Server.
+   Kamailio, so that it can be reused at the Application Server.
 
 2.2.1. The SEAS protocol
 
    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 OpenSER and the Application
+   used for communication between Kamailio and the Application
    Servers.
 
    Once an incoming SIP message has reached the worker process
-   within OpenSER, it copies its content into a private memory
+   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.
 
-   OpenSER uses a technique called lazy-parsing, which consists in
+   Kamailio uses a technique called lazy-parsing, which consists in
    delaying the parse of headers until some piece of the code
    requires it.
 
@@ -913,17 +913,17 @@ Chapter 2. Developer Guide
    in a sip_msg structure, using dynamically-allocated memory
    segments.
 
-   OpenSER defines different structure types describing different
+   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.
 
-   The str structure is a key component of OpenSER's high
+   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, OpenSER defines a
+   processor consuming. Instead of this, 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
@@ -941,7 +941,7 @@ Chapter 2. Developer Guide
    giving the length, has been casted to an unsigned byte (256
    values, so 256 characters maximum length).
 
-   When messages get transferred from OpenSER to the Application
+   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

+ 37 - 37
modules_k/seas/doc/seas_admin.xml

@@ -7,18 +7,18 @@
       <section>
         <title>Sip Express Application Server module overview</title>
 
-        <para><acronym>SEAS</acronym> module enables OpenSER 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 OpenSER 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 OpenSER 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 OpenSER 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
@@ -40,15 +40,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 OpenSER 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 OpenSER 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 OpenSER, and this external entity can then order
-        OpenSER 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
@@ -58,13 +58,13 @@
       <section id="ApplicationServer">
         <title>Application Servers</title>
 
-        <para>When OpenSER 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 OpenSER 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 OpenSER 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
@@ -76,7 +76,7 @@
         <title>Dependencies</title>
 
         <section>
-          <title>OpenSER Modules</title>
+          <title>Kamailio Modules</title>
 
           <para>SEAS module relies on the Transaction Module (TM module) for
           operation.</para>
@@ -86,7 +86,7 @@
           <title>External Applications</title>
 
           <para>Using the SEAS module requires to have an Application Server
-          running and connected to a particular instance of OpenSER.</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
@@ -107,7 +107,7 @@
           configured to connect to that port.</para>
 
           <para>In case this parameter is ommited, SEAS listens on the default
-          IP which OpenSER 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>
@@ -132,7 +132,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 OpenSER 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>
@@ -153,14 +153,14 @@ t_reply("500","App Server not connected");
           <section>
             <title>Return value</title>
 
-            <para>In case the Application Server is connected to OpenSER, 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 OpenSER, 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>
@@ -471,15 +471,15 @@ 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 OpenSER listens for the messages, so
-          in fact, OpenSER is listening on them, but OpenSER 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 OpenSER in the "listen" parameters.</para>
+            declared within Kamailio in the "listen" parameters.</para>
 
-            <para>For example in openser.cfg:<programlisting>listen = tcp:localhost:5060
+            <para>For example in kamailio.cfg:<programlisting>listen = tcp:localhost:5060
 listen = udp:localhost:5060</programlisting></para>
           </warning>
 
@@ -493,15 +493,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 OpenSER 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 OpenSER 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 OpenSER 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>
@@ -514,13 +514,13 @@ listen = udp:localhost:5060</programlisting></para>
               Application Server.</para>
 
               <para><warning>
-                  <para>This is the name you will set in the OpenSER
+                  <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
-                  OpenSER, they must each one have a different STACK_NAME",
-                  and within OpenSER 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>
@@ -542,7 +542,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 OpenSER 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>
 
@@ -620,7 +620,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 OpenSER 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"
@@ -632,7 +632,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 OpenSER 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
@@ -655,23 +655,23 @@ listen = udp:localhost:5060</programlisting></para>
       <section>
         <title>Configuration Examples</title>
 
-        <para>In general, you can configure WeSIP to work with your OpenSER in
-        two ways: have 2 OpenSER 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 OpenSER works as usual, and the requests that need special
-        services are relaied to another OpenSER 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 OpenSER, 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>
 
         <para/>
 
         <section>
-          <title>Openser.cfg in standalone</title>
+          <title>kamailio.cfg in standalone</title>
 
           <para><programlisting>debug=3            # debug level (cmd line: -dddddddddd)
 fork=yes
@@ -737,7 +737,7 @@ route[1] {
         </section>
 
         <section>
-          <title>Openser.cfg working as WeSIP front-end</title>
+          <title>kamailio.cfg working as WeSIP front-end</title>
 
           <para><programlisting>debug=9            # debug level (cmd line: -dddddddddd)
 fork=yes

+ 1 - 1
modules_k/snmpstats/README

@@ -505,7 +505,7 @@ Chapter 2. Frequently Asked Questions
 
    Why am I not receiving any SNMP Traps?
 
-   Assuming you've configured the trap thresholds in openser.cfg
+   Assuming you've configured the trap thresholds in kamailio.cfg
    with something similar to:
     modparam("snmpstats", "MsgQueueMinorThreshold", 1234)
     modparam("snmpstats", "MsgQueueMajorThreshold", 5678)

+ 7 - 7
modules_k/snmpstats/doc/snmpstats_faq.xml

@@ -47,7 +47,7 @@
 	    </question>
 	    <answer>
 		<para>
-		Assuming you've configured the trap thresholds in openser.cfg with something similar to:
+		Assuming you've configured the trap thresholds in kamailio.cfg with something similar to:
 		</para>
 
 		<programlisting format="linespecific">
@@ -58,7 +58,7 @@
     modparam("snmpstats", "dlg_minor_threshold", 600)
 		</programlisting>
 		<para>
-		Then either OpenSER 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>
@@ -110,7 +110,7 @@
 	</qandaentry>
 	<qandaentry>
 	    <question>
-		<para>OpenSER 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>
@@ -180,7 +180,7 @@
 			</listitem>
 			<listitem>
 				<para>
-				Try starting OpenSER again.
+				Try starting Kamailio again.
 				</para>
 			</listitem>
 		</orderedlist>
@@ -225,7 +225,7 @@
 
 		<programlisting format="linespecific">
     -- FROM       OPENSER-SIP-COMMON-MIB
-    -- TEXTUAL CONVENTION OpenSERSIPEntityRole
+    -- TEXTUAL CONVENTION KamailioSIPEntityRole
     SYNTAX        BITS {other(0), userAgent(1), proxyServer(2), redirectServer(3), registrarServer(4)} 
     MAX-ACCESS    read-only
     STATUS        current
@@ -271,7 +271,7 @@
     		</programlisting>
 
 		For example, consider an snmpget on the openserSIPEntityType scalar, 
-		run on the same machine running the OpenSER 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">
@@ -302,7 +302,7 @@
     		</programlisting>
 
 		For example, consider the openserSIPRegUserTable.  If we run the snmptable
-		command on the same machine as the running OpenSER 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">

+ 2 - 2
modules_k/snmpstats/openserObjects.c

@@ -26,7 +26,7 @@
  * --------
  * 2006-11-23 initial version (jmagder)
  * 2007-02-16 Moved all OID registrations from the experimental branch to 
- *            OpenSER's IANA assigned enterprise branch. (jmagder)
+ *            Kamailio's IANA assigned enterprise branch. (jmagder)
  * 
  * Note: this file originally auto-generated by mib2c using
  *		: mib2c.scalar.conf,v 1.9 2005/01/07 09:37:18 dts12 Exp $
@@ -263,7 +263,7 @@ void init_openserObjects(void)
  * - All scalars involving alarm status's and thresholds.  
  *
  * By default they are initialized to -1, which disables alarm checks.
- * These are set through the openser.cfg file with the following modparams to
+ * These are set through the kamailio.cfg file with the following modparams to
  * the snmpstats module:
  *
  *  - dlg_minor_threshold  

+ 1 - 1
modules_k/snmpstats/openserObjects.h

@@ -63,7 +63,7 @@ Netsnmp_Node_Handler handle_openserDialogLimitMinorAlarm;
 Netsnmp_Node_Handler handle_openserDialogLimitMajorAlarm;
 
 /* The following four functions are used to retrieve thresholds set via the
- * openser.cfg configuration file. */
+ * kamailio.cfg configuration file. */
 int get_msg_queue_minor_threshold();
 int get_msg_queue_major_threshold();
 int get_dialog_minor_threshold();

+ 18 - 18
modules_k/snmpstats/snmpstats.c

@@ -79,7 +79,7 @@
 #include "utilities.h"
 #include "sub_agent.h"
 
-/* Required in every OpenSER Module. */
+/* Required in every Kamailio Module. */
 MODULE_VERSION
 
 /* 
@@ -89,7 +89,7 @@ MODULE_VERSION
  * handler.  
  *
  * Specifically, If the process that generated the SIGCHLD doesn't match this
- * pid, we call OpenSER's default handlers.  Otherwise, we just ignore SIGCHLD.
+ * pid, we call Kamailio's default handlers.  Otherwise, we just ignore SIGCHLD.
  */
 volatile pid_t sysUpTime_pid;
 
@@ -97,7 +97,7 @@ volatile pid_t sysUpTime_pid;
  * for a full description. */
 static int spawn_sysUpTime_child();
 
-/* Storage for the "snmpgetPath" and "snmpCommunity" openser.cfg parameters.
+/* Storage for the "snmpgetPath" and "snmpCommunity" kamailio.cfg parameters.
  * The parameters are used to define what happens with the sysUpTime child.  */
 char *snmpget_path   = NULL;
 char *snmp_community = NULL;
@@ -105,7 +105,7 @@ char *snmp_community = NULL;
 /* 
  * This module replaces the default SIGCHLD handler with our own, as explained
  * in the documentation for sysUpTime_pid above.  This structure holds the old
- * handler so we can call and restore OpenSER's usual handler when appropriate
+ * handler so we can call and restore Kamailio's usual handler when appropriate
  */
 static struct sigaction old_sigchld_handler;
 
@@ -209,9 +209,9 @@ static int register_message_code_statistics(void)
 	return 0;
 }
 
-/* This is the first function to be called by OpenSER, to initialize the module.
+/* This is the first function to be called by Kamailio, to initialize the module.
  * This call must always return a value as soon as possible.  If it were not to
- * return, then OpenSER would not be able to initialize any of the other
+ * return, then Kamailio would not be able to initialize any of the other
  * modules. */
 static int mod_init(void) 
 {
@@ -228,9 +228,9 @@ static int mod_init(void)
 	
 	/* We need to register for callbacks with usrloc module, for whenever a
 	 * contact is added or removed from the system.  We need to do it now
-	 * before OpenSER's functions get a chance to load up old user data from
+	 * before Kamailio's functions get a chance to load up old user data from
 	 * the database.  That load will happen if a lookup() function is come
-	 * across in openser.cfg. */
+	 * across in kamailio.cfg. */
 
 	if (!registerForUSRLOCCallbacks()) 
 	{
@@ -244,7 +244,7 @@ static int mod_init(void)
 						" with the usrloc module\n");
 		LM_ERR("Are you sure that the usrloc module was loaded"
 				" before the snmpstats module in ");
-		LM_ERR("openser.cfg?  openserSIPRegUserTable will not be "
+		LM_ERR("kamailio.cfg?  openserSIPRegUserTable will not be "
 			   "updated.");
 		*/
 	} 
@@ -257,7 +257,7 @@ static int mod_init(void)
 }
 
 
-/* This function is called when OpenSER has finished creating all instances of
+/* This function is called when Kamailio has finished creating all instances of
  * itself.  It is at this point that we want to create our AgentX sub-agent
  * process, and register a handler for any state changes of our child. */
 static int mod_child_init(int rank) 
@@ -273,7 +273,7 @@ static int mod_child_init(int rank)
 	return 0;
 }
 
-/* This function is called when OpenSER is shutting down. When this happens, we
+/* This function is called when Kamailio is shutting down. When this happens, we
  * log a useful message and kill the AgentX Sub-Agent child process */
 static void mod_destroy(void) 
 {
@@ -289,8 +289,8 @@ static void mod_destroy(void)
 /* The SNMPStats module forks off a child process to run an snmp command via
  * execve(). We need a customized handler to catch and ignore its SIGCHLD when 
  * it terminates. We also need to make sure to forward other processes 
- * SIGCHLD's to OpenSER's usual SIGCHLD handler.  We do this by resetting back
- * OpenSER's own signal handlers after we caught our appropriate SIGCHLD. */
+ * SIGCHLD's to Kamailio's usual SIGCHLD handler.  We do this by resetting back
+ * Kamailio's own signal handlers after we caught our appropriate SIGCHLD. */
 static void sigchld_handler(int signal)
 {
 	int pid_of_signalled_process_status;
@@ -298,7 +298,7 @@ static void sigchld_handler(int signal)
 
 	/* We need to lookout for the expected SIGCHLD from our
 	 * sysUpTime child process, and ignore it.  If the SIGCHLD is
-	 * from another process, we need to call OpenSER's usual
+	 * from another process, we need to call Kamailio's usual
 	 * handlers */
 	pid_of_signalled_process = 
 			waitpid(-1, &pid_of_signalled_process_status, WNOHANG);
@@ -307,16 +307,16 @@ static void sigchld_handler(int signal)
 	{
 		/* It was the sysUpTime process which died, which was expected.
 		 * At this point we will never see any SIGCHLDs from any other
-		 * SNMPStats process.  This means that we can restore OpenSER's
+		 * SNMPStats process.  This means that we can restore Kamailio's
 		 * original handlers. */
 		sigaction(SIGCHLD, &old_sigchld_handler, NULL);
 	} else 
 	{
 
-		/* We need this 'else-block' in case another OpenSER process dies
+		/* We need this 'else-block' in case another Kamailio process dies
 		 * unexpectantly before the sysUpTime process dies.  If this
 		 * doesn't happen, then this code will never be called, because
-		 * the block above re-assigns OpenSER's original SIGCHLD
+		 * the block above re-assigns Kamailio's original SIGCHLD
 		 * handler.  If it does happen, then we make sure to call the
 		 * default signal handlers. */
 		if (old_sigchld_handler.sa_handler != SIG_IGN &&
@@ -454,7 +454,7 @@ static int spawn_sysUpTime_child(void)
 }
 
 
-/* This function is called whenever the openser.cfg file specifies the
+/* This function is called whenever the kamailio.cfg file specifies the
  * snmpgetPath parameter.  The function will set the snmpget_path parameter. */
 int set_snmpget_path( modparam_t type, void *val) 
 {

+ 5 - 5
modules_k/snmpstats/snmpstats.h

@@ -72,19 +72,19 @@
 #define SNMPSTATS_MODULE_NAME "snmpstats"
 #define SYSUPTIME_OID         ".1.3.6.1.2.1.1.3.0"
 
-/* This is the first function to be called by OpenSER, to initialize the module.
+/* This is the first function to be called by Kamailio, to initialize the module.
  * This call must always return a value as soon as possible.  If it were not to
- * return, then OpenSER would not be able to initialize any of the other
+ * return, then Kamailio would not be able to initialize any of the other
  * modules. */
 static int  mod_init(void);
 
-/* This function is called when OpenSER has finished creating all instances of
+/* This function is called when Kamailio has finished creating all instances of
  * itself.  It is at this point that we want to create our AgentX sub-agent
  * process, and register a handler for any state changes of our child. */
 static int  mod_child_init(int rank);
 
 
-/* This function is called when OpenSER is shutting down.  When this happens, we
+/* This function is called when Kamailio is shutting down.  When this happens, we
  * log a useful message and kill the AgentX Sub-Agent child process */
 static void mod_destroy(void);
 
@@ -97,7 +97,7 @@ static proc_export_t mod_procs[] = {
 
 /*
  * This structure defines the SNMPStats parameters that can be configured
- * through the openser.cfg configuration file.  
+ * through the kamailio.cfg configuration file.  
  */
 static param_export_t mod_params[] = 
 {

+ 6 - 6
modules_k/sst/README

@@ -59,12 +59,12 @@ Chapter 1. Admin Guide
 
    The sst module provides a way to update the dialog expire timer
    based on the SIP INVITE/200 OK Session-Expires header value.
-   You can use the sst module in an OpenSER proxy to allow freeing
+   You can use the sst module in an Kamailio proxy to allow freeing
    of local resources of dead (expired) calls.
 
    You can also use the sst module to validate the MIN_SE header
    value and reply to any request with a "422 - Session Timer Too
-   Small" if the value is too small for your OpenSER
+   Small" if the value is too small for your Kamailio
    configuration.
 
 1.2. How it works
@@ -76,12 +76,12 @@ Chapter 1. Admin Guide
    setting the avp value.
 
    You flag any call setup INVITE that you want to cause a timed
-   session to be established. This will cause OpenSER to request
+   session to be established. This will cause Kamailio to request
    the use of session times if the UAC does not request it.
 
    All of this happens with a properly configured dialog and sst
    module and setting the dialog flag and the sst flag at the time
-   any INVITE sip message is seen. There is no openser.cfg script
+   any INVITE sip message is seen. There is no kamailio.cfg script
    function call required to set the dialog expire timeout value.
    See the dialog module users guide for more information.
 
@@ -221,8 +221,8 @@ modparam("sst", "reject_to_small", 0)
 
 1.4.5. sst_flag (integer)
 
-   Keeping with OpenSER, the module will not do anything to any
-   message unless instructed to do so via the openser.cfg script.
+   Keeping with Kamailio, the module will not do anything to any
+   message unless instructed to do so via the kamailio.cfg script.
    You must set the sst_flag value in the setflag() call of the
    INVITE you want the sst module to process. But before you can
    do that, you need to tell the sst module which flag value you

+ 2 - 2
modules_k/sst/doc/sst_admin.xml

@@ -37,7 +37,7 @@
 	<para>All of this happens with a properly configured dialog
 	and sst module and setting the dialog flag and the sst flag at
 	the time any INVITE sip message is seen. There is no
-	openser.cfg script function call required to set the dialog
+	kamailio.cfg script function call required to set the dialog
 	expire timeout value. See the dialog module users guide for
 	more information.</para>
 
@@ -248,7 +248,7 @@ modparam("sst", "reject_to_small", 0)
 		
 		<para>Keeping with OpenSER, the module will not do
 		anything to any message unless instructed to do so via
-		the openser.cfg script. You must set the sst_flag
+		the kamailio.cfg script. You must set the sst_flag
 		value in the setflag() call of the INVITE you want the
 		sst module to process. But before you can do that, you
 		need to tell the sst module which flag value you are

+ 1 - 1
modules_k/textops/textops.c

@@ -872,7 +872,7 @@ static int remove_hf_f(struct sip_msg* msg, char* str_hf, char* foo)
 	parse_headers(msg, HDR_EOH_F, 0);
 	for (hf=msg->headers; hf; hf=hf->next) {
 		/* for well known header names str_hf->s will be set to NULL 
-		   during parsing of openser.cfg and str_hf->len contains 
+		   during parsing of kamailio.cfg and str_hf->len contains 
 		   the header type */
 		if(gp->type==GPARAM_TYPE_INT)
 		{