Module: sip-router
Branch: master
Commit: 353ab4c8e6229c70c4ac97a1f03e8a269df1b6b2
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=353ab4c…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: Mon Oct 4 21:06:50 2010 +0200
pkg/kamailio/deb: some updates for v3.1.0
---
pkg/kamailio/debian/changelog | 6 +++++
pkg/kamailio/debian/control | 45 ++++++++++++++++++++++++++++++++++++----
pkg/kamailio/debian/rules | 7 +++--
3 files changed, 50 insertions(+), 8 deletions(-)
diff --git a/pkg/kamailio/debian/changelog b/pkg/kamailio/debian/changelog
index ee826c6..bf4af02 100644
--- a/pkg/kamailio/debian/changelog
+++ b/pkg/kamailio/debian/changelog
@@ -1,3 +1,9 @@
+kamailio (3.1.0) unstable; urgency=low
+
+ * update to 3.1.0 from upstream
+
+ -- Daniel-Constantin Mierla <miconda(a)gmail.com> Thu, 27 May 2010 10:27:36 +0100
+
kamailio (3.0.2.99) unstable; urgency=low
* update to 3.0.2.99 for development version builds
diff --git a/pkg/kamailio/debian/control b/pkg/kamailio/debian/control
index d4f1d6c..4da0aaf 100644
--- a/pkg/kamailio/debian/control
+++ b/pkg/kamailio/debian/control
@@ -2,7 +2,7 @@ Source: kamailio
Section: net
Priority: optional
Maintainer: Jon Bonilla <manwe(a)aholab.ehu.es>
-Build-Depends: debhelper (>= 5), dpatch, libmysqlclient-dev, libexpat1-dev, libxml2-dev, libpq-dev, libradiusclient-ng-dev, flex, bison, zlib1g-dev, unixodbc-dev, libxmlrpc-c3-dev, libperl-dev, libsnmp-dev, dpkg-dev (>= 1.13.19), libdb-dev (>= 4.6.19), xsltproc, libconfuse-dev, libldap2-dev, libssl-dev, libcurl3-openssl-dev, python, libpcre3-dev, docbook-xml, libpurple-dev, libmemcache-dev, libreadline5-dev
+Build-Depends: debhelper (>= 5), dpatch, libmysqlclient-dev, libexpat1-dev, libxml2-dev, libpq-dev, libradiusclient-ng-dev, flex, bison, zlib1g-dev, unixodbc-dev, libxmlrpc-c3-dev, libperl-dev, libsnmp-dev, dpkg-dev (>= 1.13.19), libdb-dev (>= 4.6.19), xsltproc, libconfuse-dev, libldap2-dev, libssl-dev, libcurl3-openssl-dev, python, libpcre3-dev, docbook-xml, libpurple-dev, libmemcache-dev, libreadline-dev, liblua5.1-0-dev, python-dev, libgeoip-dev
Standards-Version: 3.8.0
Homepage: http://www.kamailio.org/
@@ -98,17 +98,19 @@ Description: SIMPLE presence modules for Kamailio
server and presence user agent for RICH presence, registrar-based presence,
external triggered presence and XCAP support.
-Package: kamailio-xmlrpc-modules
+Package: kamailio-xml-modules
Architecture: any
Depends: ${shlibs:Depends}, kamailio (= ${binary:Version})
-Replaces: kamailio-xmlrpc-module
-Description: XMLRPC support for Kamailio's Management Interface
+Replaces: kamailio-xml-module
+Description: XML based extensions for Kamailio's Management Interface
Kamailio is a very fast and flexible SIP (RFC3261)
proxy server. Written entirely in C, Kamailio can handle thousands calls
per second even on low-budget hardware.
.
- This package provides the XMLRPC transport implementations for Kamailio's
+ This package provides:
+ - the XMLRPC transport implementations for Kamailio's
Management and Control Interface.
+ - xmlops module for XPath operations in configuration file
Package: kamailio-perl-modules
Architecture: any
@@ -226,6 +228,39 @@ Description: contains the TLS kamailio transport module
This has been split out of the main kamailio package, so that kamailio will not
depend on openssl. This module will enable you to use the TLS transport.
+Package: kamailio-lua-modules
+Architecture: any
+Depends: ${shlibs:Depends}, kamailio (= ${Source-Version})
+Description: contains the app_lua module
+ Kamailio is a very fast and flexible SIP (RFC3261)
+ proxy server. Written entirely in C, Kamailio can handle thousands calls
+ per second even on low-budget hardware.
+ .
+ This package provides the app_lua module, an extension allowing to
+ execute embedded Lua applications within configuration file.
+
+Package: kamailio-python-modules
+Architecture: any
+Depends: ${shlibs:Depends}, kamailio (= ${Source-Version})
+Description: contains the app_python module
+ Kamailio is a very fast and flexible SIP (RFC3261)
+ proxy server. Written entirely in C, Kamailio can handle thousands calls
+ per second even on low-budget hardware.
+ .
+ This package provides the app_python module, an extension allowing to
+ execute embedded Python applications within configuration file.
+
+Package: kamailio-geoip-modules
+Architecture: any
+Depends: ${shlibs:Depends}, kamailio (= ${Source-Version})
+Description: contains the geoip module
+ Kamailio is a very fast and flexible SIP (RFC3261)
+ proxy server. Written entirely in C, Kamailio can handle thousands calls
+ per second even on low-budget hardware.
+ .
+ This package provides the geoip module, an extension allowing to
+ use GeoIP API within configuration file.
+
Package: kamailio-nth
Architecture: any
Depends: screen, gdb, binutils, gcc, bison, flex, ngrep, tcpdump, iftop, lsof, psmisc, vim, bvi, most, mc, sipsak
diff --git a/pkg/kamailio/debian/rules b/pkg/kamailio/debian/rules
index 7952a59..b3b5600 100755
--- a/pkg/kamailio/debian/rules
+++ b/pkg/kamailio/debian/rules
@@ -25,7 +25,7 @@ EXCLUDED_MODULES=
# extra modules to skip, because they are not compilable now
# - regardless if they go to the main kamailio package or to some module package,
# they will be excluded from compile and install of all
-EXTRA_EXCLUDED_MODULES=seas bdb dbtext oracle pa rls iptrtpproxy
+EXTRA_EXCLUDED_MODULES=bdb dbtext oracle pa rls iptrtpproxy
#EXTRA_EXCLUDED_MODULES=
# possible module directories that can appear in MODULES_SP
@@ -41,8 +41,9 @@ MODULES_SP=
# Note: the order is important (should be in dependency order, the one
# on which other depend first)
PACKAGE_GROUPS=mysql postgres berkeley unixodbc radius presence \
- ldap xmlrpc perl utils purple memcached tls \
- snmpstats carrierroute xmpp cpl
+ ldap xml perl utils purple memcached tls \
+ snmpstats carrierroute xmpp cpl lua python \
+ geoip
# directories with possible duplicate libraries (that should be deleted
# from current module* packages)
i tried to register sip-communication over tls, but sr complained about
wrong tls version:
Oct 3 19:29:58 sip /usr/sbin/sip-proxy[31340]: ERROR: tls [tls_server.c:1174]: tls_read_f(): TLS accept:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
rfc3261 refers to
T. Dierks and C. Allen, “The TLS protocol version 1.0,” RFC 2246,
Internet Engineering Task Force, Jan. 1999.
which is 11 years old and also to
P. Chown, “Advanced encryption standard (AES) ciphersuites for transport
layer security (TLS),” RFC 3268, Internet Engineering Task Force, June
2002.
which is 8 years old. also there is statement
The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [26] MUST be supported at a
minimum by implementers when TLS is used in a SIP application. For
purposes of backwards compatibility, proxy servers,
redirect servers, and registrars SHOULD support
TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any other
ciphersuite.
how is it possible that sip-communicator that is much newer than those
rfcs, does not support them, but proposes in its client hello SSLv2?
nowhere in rf3261 was i able to find any references to these:
* SSLv3 - only SSLv3 connections are accepted
* SSLv2 - only SSLv2 connections, for old clients. Note: you
shouldn't use SSLv2 for anything which should be highly secure.
how is it possible that they would be ever needed? why don't we have
these kind of problems when accessing web sites? has rfc3261 somehow
got it wrong or what?
also, it was not clear from tls/README that if i set
modparam("tls", "tls_method", "SSLv23")
will it mean that TLSv1 connections (as required by rfc3261) are not
accepted if UA only support TLSv1 and proposes in client hello?
-- juha
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Juha Heinanen (jh)
Attached to Project - sip-router
Summary - new tls_method that only accepts TLSv1, but allows SSLv2 client hello
Task Type - Improvement
Category - tls
Status - Assigned
Assigned To - Andrei Pelinescu-Onciul
Operating System - All
Severity - Medium
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - some SIP UAs send SSLv2 initial client hello, but negotiation finally results in TLSv1. currently there is no tls_method that would allow SSLv2 initial hello, but that would require TLSv1 as the result of the negotiation. proposal is to add such a new tls_method value, e.g., TLSv1N or something else.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=90
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A user has added themself to the list of users assigned to this task.
FS#90 - new tls_method that only accepts TLSv1, but allows SSLv2 client hello
User who did this - Juha Heinanen (jh)
http://sip-router.org/tracker/index.php?do=details&task_id=90
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Module: sip-router
Branch: tirpi/cfg_framework_multivalue
Commit: 778ecd4f3c40124c019edd74fe0d70b3d86d4c1c
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=778ecd4…
Author: Miklos Tirpak <miklos(a)iptel.org>
Committer: Miklos Tirpak <miklos(a)iptel.org>
Date: Mon Oct 4 17:18:31 2010 +0200
cfg framework: multiple group instances is documented
---
doc/cfg.txt | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 60 insertions(+), 1 deletions(-)
diff --git a/doc/cfg.txt b/doc/cfg.txt
index df1209c..dd9e959 100644
--- a/doc/cfg.txt
+++ b/doc/cfg.txt
@@ -26,6 +26,15 @@ without the need of commit. That means a kind of transaction support,
the framework can keep track of the changes (per driver) until they
are committed or rolled-back.
+The framework also supports multiple versions of the core or module
+configurations. Every SIP message processing or timer function starts with
+the default version which can be changed runtime in the script. Hence, even if
+the core/module implements a variable with a single value, it may have multiple
+instances with different values in memory, and the configuration instances can be
+swapped runtime. New instances of a configuration group can be added and deleted
+runtime by the drivers, and all the variables in the group instances take
+the default value unless their value has been explicitely set.
+
2. Using the framework in a module
===============================================================================
@@ -130,6 +139,8 @@ Each row consists of the following items:
of the cfg framework. By default this callback is
called by all the child processes separately,
this can be changed with this flag.
+ Multiple values are not supported together with
+ the CFG_CB_ONLY_ONCE flag.
- minimum value for integers (optional)
- maximum value for integers (optional)
@@ -323,10 +334,11 @@ void *h;
str gname, vname;
void *old_val, *new_val;
unsigned int val_type;
+unsigned int *group_id;
if (cfg_diff_init(ctx, &h)) return -1;
while(cfg_diff_next(&h,
- &gname, &vname,
+ &gname, &group_id, &vname,
&old_val, &new_val,
&val_type)
) {
@@ -334,6 +346,11 @@ while(cfg_diff_next(&h,
}
cfg_diff_release(ctx);
+-------------------------------------------------------------------------------
+9. Add/delete an instance of an existing group:
+
+cfg_add_group_inst()
+cfg_del_group_inst()
5. Refreshing the configuration
===============================================================================
@@ -424,3 +441,45 @@ New configuration values can be declared in the script, the syntax is:
The values can be accessed via select calls:
@cfg_get.<group_name>.<var_name>
+
+
+Use the following syntax to set an additional instance of a configuration value:
+
+<group_name>[id].<var_name> = <value>
+
+id is an unsigned integer starting from 0, it does not have to be continuous.
+Note, that not the variables but the entire configuration group can have multiple
+instances, and it is possible to swap the configuration of the entire group at once
+with cfg_select("group_name", id), see the example below:
+
+custom.var1 = 1;
+custom.var2 = "default string";
+
+custom[1].var1 = 15;
+custom[1].var2 = "More specific string";
+
+custom[2].var1 = 3;
+# custom[2].var2 is not set, hence, it will inherit the value of custom.var2.
+# When custom.var2 changes, custom[2].var1 will be also updated.
+
+
+route {
+ # Actual values: var1:1, var2:"default string"
+
+ cfg_select("custom", 1);
+ # Actual values: var1:15, var2:"More specific string"
+
+ cfg_select("custom", 2");
+ # Actual values: var1:3, var2:"default string"
+
+ cfg_reset("custom")
+ # Actual values: var1:1, var2:"default string"
+}
+
+cfg_reset("group_name") can be used to reset the configuration back to the original values.
+The values are automatically reseted before each SIP message is started to be processed, or after
+each timer function execution.
+The above example with custom variables is supported also with module and core configuration
+groups. The only restriction is that variables with CFG_CB_ONLY_ONCE flag cannot have
+multiple values.
+