sr-dev March 2010

sr-dev@lists.kamailio.org

24 participants
359 discussions

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, 3 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, 3 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, 3 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, 3 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, 3 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, 3 months

SIP Router Project of VUC, March 19

by Daniel-Constantin Mierla

Hello, this Friday, March 19, late afternoon, the weekly VoIP User Conference is hosting a session about SIP Router project. My goals are to present the achievements so far within SIP Router projects, what is new in Kamailio 3.0 release and plans for the future. More details can be found at: http://www.kamailio.org/w/vuc-the-sip-router-project/ You can join the audio conference via sip, skype, pstn line or other several options presented on http://vuc.me site. There is a irc channel available for it: #vuc on irc.freenode.net. Cheers, Daniel -- Daniel-Constantin Mierla Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010 * http://www.asipto.com/index.php/sip-router-masterclass/

14 years, 3 months

Re: [sr-dev] [Kamailio-Users] Kamailio 3.0.0 Install Error

by Daniel-Constantin Mierla

Hello, On Thu, Mar 11, 2010 at 3:32 AM, Nathaniel L Keeling <keeling(a)akan-tech.com>wrote: > I am trying to install the new release of Kamailio 3.0.0 on Solaris 10. > When I perform the install, I am getting this error. Here is the command > that I am entering for the install: > > make prefix=/usr/local/kamailio-3.0.0 INSTALL=install > group_include="standard standard-dep postgres" CPU=ultrasparc install > > install mode > make[2]: Entering directory `/usr/local/src/kamailio-3.0.0/lib/kcore' > make[2]: Nothing to be done for `install-if-newer'. > make[2]: Leaving directory `/usr/local/src/kamailio-3.0.0/lib/kcore' > touch > /usr/local/kamailio-3.0.0/lib/kamailio/modules_k/speeddial.so > install -m 755 speeddial.so > /usr/local/kamailio-3.0.0/lib/kamailio/modules_k > make[1]: Leaving directory > `/usr/local/src/kamailio-3.0.0/modules_k/speeddial' > mkdir -p /usr/local/kamailio-3.0.0/etc/kamailio/ > # other configs > /bin/sh: syntax error at line 1: `;' unexpected > make: *** [install-cfg] Error 2 > > I am new to Kamailio and would appreciate any help. > are you using gmake? Cheers, Daniel -- Daniel-Constantin Mierla http://www.asipto.com

14 years, 3 months

git:kamailio_3.0: tls: doc: fix low_mem_treshold* name in examples

by Andrei Pelinescu-Onciul

Module: sip-router Branch: kamailio_3.0 Commit: 2f900c77ba09f57217cffda8ff4ea882fbaa21e2 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=2f900c7… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Tue Mar 16 11:13:19 2010 +0100 tls: doc: fix low_mem_treshold* name in examples The tls examples used low_memory_threshold[12] instead of low_mem_treshold[12]. Reported-by: Jan Janak <jan(a)iptel.org> (cherry picked from commit 915a0052092be70630f76a91c19c9a540da038df) --- modules/tls/README | 8 ++++---- modules/tls/doc/params.xml | 8 ++++---- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/modules/tls/README b/modules/tls/README index c30c1c7..fcdc5d9 100644 --- a/modules/tls/README +++ b/modules/tls/README @@ -444,9 +444,9 @@ low_mem_threshold1 (integer) See also low_mem_threshold2. - Example 15. Set low_memory_threshold1 parameter + Example 15. Set low_mem_threshold1 parameter ... -modparam("tls", "low_memory_threshold1", -1) +modparam("tls", "low_mem_threshold1", -1) ... low_mem_threshold2 (integer) @@ -470,9 +470,9 @@ low_mem_threshold2 (integer) See also low_mem_threshold1. - Example 16. Set low_memory_threshold2 parameter + Example 16. Set low_mem_threshold2 parameter ... -modparam("tls", "low_memory_threshold2", -1) +modparam("tls", "low_mem_threshold2", -1) ... tls_force_run (boolean) diff --git a/modules/tls/doc/params.xml b/modules/tls/doc/params.xml index f5bcd50..03748a5 100644 --- a/modules/tls/doc/params.xml +++ b/modules/tls/doc/params.xml @@ -322,10 +322,10 @@ modparam("tls", "tls_log", 10) See also <varname>low_mem_threshold2</varname>. </para> <example> - <title>Set <varname>low_memory_threshold1</varname> parameter</title> + <title>Set <varname>low_mem_threshold1</varname> parameter</title> <programlisting> ... -modparam("tls", "low_memory_threshold1", -1) +modparam("tls", "low_mem_threshold1", -1) ... </programlisting> </example> @@ -361,10 +361,10 @@ modparam("tls", "low_memory_threshold1", -1) See also <varname>low_mem_threshold1</varname>. </para> <example> - <title>Set <varname>low_memory_threshold2</varname> parameter</title> + <title>Set <varname>low_mem_threshold2</varname> parameter</title> <programlisting> ... -modparam("tls", "low_memory_threshold2", -1) +modparam("tls", "low_mem_threshold2", -1) ... </programlisting> </example>

14 years, 3 months

git:kamailio_3.0: makefile: fix install-cfg & install-utils on solaris

by Andrei Pelinescu-Onciul

Module: sip-router Branch: kamailio_3.0 Commit: cea15a4b04720154a7495a87e4d97ceaf1b8312f URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=cea15a4… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Tue Mar 16 18:15:56 2010 +0100 makefile: fix install-cfg & install-utils on solaris Reported-by: Nathaniel L Keeling keeling akan-tech com (cherry picked from commit ad57482b7d05417f7f0058cef8c698f18d6d9a39) (cherry picked from commit d4028e0df24a97ccaacf867ab6bfe92f270b92e0) --- Makefile | 10 ++++++---- 1 files changed, 6 insertions(+), 4 deletions(-) diff --git a/Makefile b/Makefile index 1be6f4a..38b0b96 100644 --- a/Makefile +++ b/Makefile @@ -917,8 +917,8 @@ install-cfg: $(cfg_prefix)/$(cfg_dir) $(cfg_prefix)/$(cfg_dir)$(MAIN_NAME)-advanced.cfg; \ fi; \ fi - # other configs - @for r in $(C_INSTALL_CFGS) ; do \ + @# other configs + @for r in $(C_INSTALL_CFGS) ""; do \ if [ -n "$$r" ]; then \ if [ -f "$$r" ]; then \ n=`basename "$$r"` ; \ @@ -1005,8 +1005,10 @@ install-utils: utils $(bin_prefix)/$(bin_dir) fi ;\ fi ; \ done; true - @for ut in $(C_INSTALL_UTILS) ; do \ - $(call try_err, $(MAKE) -C "$${ut}" install-if-newer ) ;\ + @for ut in $(C_INSTALL_UTILS) "" ; do \ + if [ -n "$$r" ]; then \ + $(call try_err, $(MAKE) -C "$${ut}" install-if-newer ) ;\ + fi ; \ done; true

14 years, 3 months

← Newer
1
...
13
14
15
16
17
18
19
...
36
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev March 2010