sr-dev

sr-dev@lists.kamailio.org

44307 discussions

git:master: tls: minor DBG() fix for the servername extension

by Andrei Pelinescu-Onciul

Module: sip-router Branch: master Commit: 28b53c804b4853c31c8cb14227f207c9f085fb53 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=28b53c8… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Fri Mar 19 13:21:32 2010 +0100 tls: minor DBG() fix for the servername extension --- modules/tls/tls_select.c | 11 +++++------ 1 files changed, 5 insertions(+), 6 deletions(-) diff --git a/modules/tls/tls_select.c b/modules/tls/tls_select.c index ac14cdb..dba9a6e 100644 --- a/modules/tls/tls_select.c +++ b/modules/tls/tls_select.c @@ -24,11 +24,10 @@ * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ -/*! - * \file - * \brief SIP-router TLS support :: Select interface - * \ingroup tls - * Module: \ref tls +/** SIP-router TLS support :: Select interface. + * @file + * @ingroup tls + * Module: @ref tls */ @@ -962,9 +961,9 @@ static int get_tlsext_sn(str* res, sip_msg_t* msg) server_name.s = (char*)SSL_get_servername(ssl, TLSEXT_NAMETYPE_host_name); if (server_name.s) { + server_name.len = strlen(server_name.s); DBG("received server_name (TLS extension): '%.*s'\n", STR_FMT(&server_name)); - server_name.len = strlen(server_name.s); } else { DBG("SSL_get_servername returned NULL\n"); goto error;

14 years, 10 months

git:master: core: cfg parser: allow negative numbers in modparams

by Andrei Pelinescu-Onciul

Module: sip-router Branch: master Commit: d4b2eee2e4f0e5a1fe4b5ea17d78d51a6fab70c7 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=d4b2eee… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Fri Mar 19 14:47:46 2010 +0100 core: cfg parser: allow negative numbers in modparams --- cfg.y | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/cfg.y b/cfg.y index 8bda2fc..a9350ec 100644 --- a/cfg.y +++ b/cfg.y @@ -1631,7 +1631,7 @@ module_stm: yyerror("Can't set module parameter"); } } - | MODPARAM LPAREN STRING COMMA STRING COMMA NUMBER RPAREN { + | MODPARAM LPAREN STRING COMMA STRING COMMA intno RPAREN { #ifdef SHM_MEM if (!shm_initialized() && init_shm()<0) { yyerror("Can't initialize shared memory");

14 years, 10 months

git:master: tls: new parameters for advanced openssl options

by Andrei Pelinescu-Onciul

Module: sip-router Branch: master Commit: 0c5b835259ab27216a9f34ddf445a49604a6c70c URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=0c5b835… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Fri Mar 19 15:11:49 2010 +0100 tls: new parameters for advanced openssl options - ssl_release_buffers: release internal openssl read or write buffers when they are no longer used (complete read or write that does not have to buffer anything). Should be used together with tls_free_list_max_len. Might have some performance impact (and extra *malloc pressure), but has also the potential of saving a lot of memory (at least 32k/idle connection in the default config, or ~16k+tls_max_send_fragment)). Works only with openssl >= 1.0.0. - ssl_freelist_max_len: maximum length of free/unused memory buffers/chunks per connection. Setting it to 0 would cause any unused buffers to be immediately freed and hence a lower memory footprint (at the cost of a possible performance hit and more *malloc pressure). Too large value would result in extra memory consumption. The default is 32 in openssl. For lowest memory usage set it to 0 and tls_mode_release_buffers to 1. Works / makes sense only for openssl >= 1.0.0. - ssl_max_send_fragment: maximum number of bytes (clear text) sent into one record. The default and maximum value are ~16k. Lower values would lead to a lower memory footprint. Values lower then the typical app. write size might decrease performance, so it should be kept ~2k+ for normal SIP traffic. Too low values (e.g. <1024) might cause the initial handshake to fail, so use with care. Works only for openssl >= 0.9.9. - ssl_read_ahead: enable read ahead. Should increase performance (1 less syscall when enabled, else openssl makes 1 read() for each record header and another or the content), but might interact with SSL_pending() (not used right now). Default: 1 (enabled). --- modules/tls/tls_domain.c | 244 ++++++++++++++++++++++++++++++++++++++++++++- modules/tls/tls_mod.c | 49 ++++++++-- modules/tls/tls_mod.h | 13 ++- 3 files changed, 288 insertions(+), 18 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=0c5…

14 years, 10 months

Core dump not generated

by Min Wang

Hi: Running ser with root under debian lenny, And tried: kill -SIGABRT <pid_of_ser> core was not generated Any reason for that? Mar 18 14:16:39 im1 /usr/sbin/ser[5315]: ALERT: <core> [main.c:730]: child process 5319 exited by a signal 6 Mar 18 14:16:39 im1 /usr/sbin/ser[5336]: : <core> [pass_fd.c:293]: ERROR: receive_fd: EOF on 13 Mar 18 14:16:39 im1 /usr/sbin/ser[5315]: ALERT: <core> [main.c:733]: core was not generated Mar 18 14:16:39 im1 /usr/sbin/ser[5336]: DEBUG: <core> [tcp_main.c:3034]: DBG: handle_ser_child: dead child 4, pid 5319 (shutting down?) Mar 18 14:16:39 im1 /usr/sbin/ser[5315]: INFO: <core> [main.c:745]: INFO: terminating due to SIGCHLD Mar 18 14:16:39 im1 /usr/sbin/ser[5336]: DEBUG: <core> [io_wait.h:588]: DBG: io_watch_del (0x821a0a0, 13, -1, 0x0) fd_no=24 called Mar 18 14:16:39 im1 /usr/sbin/ser[5332]: INFO: <core> [main.c:796]: INFO: signal 15 received Mar 18 14:16:39 im1 /usr/sbin/ser[5333]: INFO: <core> [main.c:796]: INFO: signal 15 received Mar 18 14:16:39 im1 /usr/sbin/ser[5324]: INFO: <core> [main.c:796]: INFO: signal 15 received Mar 18 14:16:39 im1 /usr/sbin/ser[5317]: INFO: <core> [main.c:796]: INFO: signal 15 received Thanks. Kind Regards Min Wang

14 years, 10 months

Reminder: VUC Today, SIP Router Project

by Daniel-Constantin Mierla

Hello, a kind reminder for today's audio conference scheduled for 16:00GMT. Check the start time for your zone at: http://vuc.me/next After presenting the achievements so far within SIP Router, with what is new in 3.0.0 release and development version, you have an unique opportunity to ask questions to: - Andrei Pelinescu-Onciul, the creator of SIP Express Router (SER), the architect behind the core (transport layers, memory management, asynchronous processing, timers, etc), who will be also able to answer anything from project's history started in 2001 - Alex Balashov, Kamailio management team member, experienced consultant in building large SIP platforms - myself, as co-founder of Kamailio (OpenSER) You can join via irc on #vuc (note that some of us started to hang out on #sip-router) channel at irc.freenode.net. Dialing to VUC is possible via sip, skype, pstn, web page and more, see: http://vuc.me Five hours to go right now, hear you then! Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/

14 years, 10 months

Kamailio - SIP Router on GSoC 2010

by Daniel-Constantin Mierla

Hello, I have the pleasure to announce that our project has an accepted application for Google Summer of Code 2010. The proposed application was done within SIP Communicator Organization and is related to extending the presence server for conference calls notifications. See more: http://www.sip-communicator.org/index.php/GSOC2010/Kamailio4575 http://www.sip-communicator.org/index.php/Development/Gsoc2010 The friends from SEMS project will be part as well, with separate application, implementing the audio mixer part. More details will be published soon. Start thinking about good candidates (they must be students (college or university)), we need them to get the project accepted for implementation. Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/

14 years, 10 months

SF.net SVN: openser:[5996] branches/1.3/modules/carrierroute/doc/ carrierroute_user.sgml

by Marius Zbihlei

Revision: 5996 http://openser.svn.sourceforge.net/openser/?rev=5996&view=rev Author: mariuszbihlei Date: 2010-03-19 10:35:11 +0000 (Fri, 19 Mar 2010) Log Message: ----------- modules/carrierroute Documentation for cr_reload_routes in case of carrier mapping is changed. We do not allow cr_reload_routes when a carrier name has changed, so documentation states now that a restart of the server is to be done. (Server craches in some cases when carrier name has changed and cr_reload_routes is issued This affects only 1.3 version of carrierroute) Modified Paths: -------------- branches/1.3/modules/carrierroute/doc/carrierroute_user.sgml This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

14 years, 10 months

Re: [sr-dev] improving the dialog module

by Timo Reimann

Hey Iñaki, Iñaki Baz Castillo wrote: > 2010/3/12 Timo Reimann <timo.reimann(a)1und1.de>: > >> If so, my major concern with this approach is that it will break dialog >> callback functionality. If a dialog user, upon creation of an >> unconfirmed dialog (initial request received), registers for further >> callbacks associated with that dialog (for instance, DLGCB_CONFIRMED), >> it won't get any further callbacks in the scenario outlined above. The >> reason for this is that when the dialog is terminated due to the 5xx >> response, all associated callbacks will be swept out too, and the >> re-created dialog's structure will not contain any callbacks yet. > > A suggestion to cover all the cases: > > There could be two kinds of dialog entries in the module: > > - dialog-in: It's a *single* dialog entry generated upon receipt of > the INVITE. No info about To-tag is stored with it. It has a status > field (none, early, confirmed, terminated), but this status is handled > carefully (see below). This entry exists until the dialog or > early-dialog is terminated. Callbacks are inserted *here*. > > - dialog-out: It's a single or multiple entries pointing to a single > dialog-in entry. It contains a To-tag and status fields. A dialog-out > is generated when a response for same Call-ID and From-tag is received > and contains a new To-tag. Status for each dialog-out is updated > according to the status of the response (early, confirmed, > terminated). No callbacks are inserted here. > > When a dialog-out is generated (provisional response received) it > updates the dialog-in status to "early" (so callback is raised), but > just in case the dialog-in status was "none". > > When a dialog-out receives a (200 it also updates the dialog-in status > to "confirmed" (so callback is raised), just in case it was in "none" > or "early" status. > > When a dialog-out is terminated ([3456]XX response received) it *just* > updates the dialog-in status to "terminated" in case there are no more > alive dialog-outs (for parallel forking cases) and *also* in case the > INVITE transaction has terminated (for serial forking cases in which > still there is no new branches). > > > I think that with this approach all the cases are covered. Opinions? Interesting idea. Let me ask two questions: (1) I re-checked when dialog state is modified exactly for responses (and believe I have to doubt what I initially claimed to be true): According to dlg_handlers.c, dlg_onreply() is called right before a response is forwarded, after it was forwarded, and when the associated transaction is terminated. (tm callbacks TMCB_RESPONSE_PRE_OUT, TMCB_RESPONSE_FWDED, and TMCB_TRANS_DELETED, respectively, in Kamailio 1.5. The 3.x branch seems to have renamed TMCB_RESPONSE_PRE_OUT to TMCB_RESPONSE_READY and TMCB_TRANS_DELETED to TMCB_DESTROY. Correct me if this wasn't just for the looks.) So, taking into account that (serial and parallel) forking proxies will *forward* responses only when all forking attempts have finally failed or one succeeded, wouldn't that automatically implement your "dialog-outs will properly adjust dialog-in's state" approach and render dialog-outs unnecessary? Or am I wrong on the assumption how forking works? (2) How would your approach deal with unconfirmed requests traversing the same proxy multiple times, i.e., what has been denoted as "spiraling" in this thread, as in this example: UA1 --> P1 --> P2 --> P1 --> UA2 Will that result in the creation of two dialog(-in)s? Cheers, --Timo

14 years, 10 months

building flavours

by Daniel-Constantin Mierla

Hello, I was thinking to get an easy way to build flavours completely out of the same source tree, one of the benefits is to have only one branch for future releases. make FLAVOUR=abc cfg does most of the job. The missing pieces are manual pages and some doc files (e.g., INSTALL). My idea is to restructure a bit the pkg content: pkg: | +--- default -+-- docs (Install, man pages, etc) | | | +-- debian | +-- rpm | +-- ... | +--- abc -----+-- docs (Install, man pages, etc) | | +-- debian | +-- rpm | +-- ... | make FLAVOUR=... cfg will copy the docs files from pkg/flavour/docs in source tree root. 'default' can be 'sip-router' to match the flavours values right now. In source tree root plan have README.first where to mention to run make cfg (which is called anyhow by simple 'make') first to get INSTALL, etc ... Other opinions? Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/

14 years, 10 months

Re: [sr-dev] improving the dialog module

by Klaus Darilion

Hi! I have not followed the whole discussion. I just had an idea which might be useful: Why not hook up dialog module with tm module? Tm module already knows the state of forked INVITE transaction, which ones are in early states, and which branch is the winner. regards klaus Am 15.03.2010 14:00, schrieb Iñaki Baz Castillo: > 2010/3/12 Timo Reimann<timo.reimann(a)1und1.de>: > >> If so, my major concern with this approach is that it will break dialog >> callback functionality. If a dialog user, upon creation of an >> unconfirmed dialog (initial request received), registers for further >> callbacks associated with that dialog (for instance, DLGCB_CONFIRMED), >> it won't get any further callbacks in the scenario outlined above. The >> reason for this is that when the dialog is terminated due to the 5xx >> response, all associated callbacks will be swept out too, and the >> re-created dialog's structure will not contain any callbacks yet. > > A suggestion to cover all the cases: > > There could be two kinds of dialog entries in the module: > > - dialog-in: It's a *single* dialog entry generated upon receipt of > the INVITE. No info about To-tag is stored with it. It has a status > field (none, early, confirmed, terminated), but this status is handled > carefully (see below). This entry exists until the dialog or > early-dialog is terminated. Callbacks are inserted *here*. > > - dialog-out: It's a single or multiple entries pointing to a single > dialog-in entry. It contains a To-tag and status fields. A dialog-out > is generated when a response for same Call-ID and From-tag is received > and contains a new To-tag. Status for each dialog-out is updated > according to the status of the response (early, confirmed, > terminated). No callbacks are inserted here. > > When a dialog-out is generated (provisional response received) it > updates the dialog-in status to "early" (so callback is raised), but > just in case the dialog-in status was "none". > > When a dialog-out receives a (200 it also updates the dialog-in status > to "confirmed" (so callback is raised), just in case it was in "none" > or "early" status. > > When a dialog-out is terminated ([3456]XX response received) it *just* > updates the dialog-in status to "terminated" in case there are no more > alive dialog-outs (for parallel forking cases) and *also* in case the > INVITE transaction has terminated (for serial forking cases in which > still there is no new branches). > > > I think that with this approach all the cases are covered. Opinions? > >

14 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev