sr-dev October 2014

sr-dev@lists.kamailio.org

34 participants
381 discussions

Outbound flow failure handling merged to master
by Hugh Waite 23 Nov '16

23 Nov '16

Hello, As you will see I have merged my branch back into master. These changes add a new event route [tm:branch-failure] to the tm module which is run when any failure response is received on a transaction. The event_route uses a new route type BRANCH_ROUTE which limits the functions that can be run in the route. The functions t_check_status(), t_next_contact_flow(), t_relay() and unregister() can be used in this route. A new pv $T_reply_ruid is accessible in this route which can be used to unregister a single contact entry. The following example route can be used on a registrar to handle failed or invalid flows: event_route[tm:branch-failure] { xlog("L_INFO", "event_route[tm:branch-failure]\n"); if (t_check_status("430|403")) { if (!unregister("location", "$tu", "$T_reply_ruid")) { xlog("L_WARN", "failed to unregister $tu with ruid $T_reply_ruid\n"); } if (!t_next_contact_flow()) { xlog("L_INFO", "No more flows\n"); } else { xlog("L_INFO", "Next flow\n"); t_relay(); } } } Any bugs, memory leaks etc. let me know! Hugh -- Hugh Waite Principal Design Engineer Crocodile RCS Ltd.

4 11

TM possible deadlock
by Jason Penton 09 Apr '15

09 Apr '15

Hi All, I have been experiencing a deadlock when a timeout occurs on a t_relayed() INVITE. Going through the code I have noticed a possible chance of deadlock (without re-entrant enabled). Here is my thinking: t_should_relay_response() is called with REPLY_LOCK when the timer process fires on the fr_inv_timer (no response from the INVITE that was relayed, other than 100 provisional) and a 408 is generated. However, from within that function there are calls to run_failure_handlers() which in turn *could* try and lock the reply (viz. somebody having a t_reply() call in the cfg file - in failure route block). This would result in another lock on the same transaction's REPLY_LOCK.... Has anybody else experienced something like this? this is on master btw. Cheers Jason

2 16

[tracker] Comment added: dialplan: allow match/subst rules with variables
by sip-router 09 Dec '14

09 Dec '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#429 - dialplan: allow match/subst rules with variables User who did this - Daniel-Constantin Mierla (miconda) ---------- I pushed to master branch an alternative implementation. It took a while to analyze the patch, being quite big -- there are couple of issues that could have been fixed (such as: module might be used by workers with negative rank, like timer or rpc -- there is a mi/rpc command for translation; return at first pv detected in a string to mark it as a string with vars; handling ending $ and allowing $$ in values), but the main issue is that cloning data in private memory is not really feasible always, because can be tons of dialplan db records. It would mean to have each process with a lot of pkg memory. Only parsing of values can be cached (to have the broken down list of static strings and variables). But given that parsed values have to be searched anyhow in a hash table, I expected to be no real performance difference than parsing every time. Evaluating the value at runtime, compiling and freeing PCRE have to be done for each attempt to match in dialplan rules. Considering the complexity of managing a private cache of parsed values, my patch is parsing the values at runtime, if they are detected to have variables at load time. In summary, the way it was done: - detection stops at first variable found in a value -- the function has been added in dialplan to cope properly with $ at the end of values - each value for match and subst is marked with a flag during load if there is a var inside it - when it is a var in a value that ends with a single $, in memory it is stored with $$ at the end (one more $ is added at the end), so at runtime the evaluation results in a single $. It avoids keeping other flags and doing more conditions at runtime to cope with single $ parsing - parsing of values to tokenize variables is done at runtime, with compile of PCRE and afferent freeing afterwards - there is a module parameter 'match_dynamic' that has to be set to 1 in order to enable this feature Let me know if anyone has comments on this approach, if not, I will close this item. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=429#comment1661 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.

2 1

New module DMQ_SYNC and patch for DMQ
by Андрей Рыбкин 13 Nov '14

13 Nov '14

Hi all! Module DMQ_SYNC: The module add replication between multiple servers via DMQ module. Currently only usrloc replications. TODO: 1. dialog replications. 2. bugfixes. Patch fo DMQ: 1. add find_dmq_node_uri function to API dmq_node_t* find_dmq_node_uri(str* uri) 2. add init_callback to dmq_peer int init_callback() ______________________________ Andrey Rybkin JID: rybkin.a(a)bks.tv E-Mail: rybkin.a(a)bks.tv

5 11

dispatcher sending socket
by Federico Cabiddu 12 Nov '14

12 Nov '14

Hi all, after fighting in the last days with dispatcher and the socket used to send pings and dispatch requests, I'm thinking in adding to the module the support for configuring the sending socket. Specifically what I'm thinking is: 1) add the sending socket as a gateways' parameter 2) add an avp to store the gateways' send socket, to be used for load balancing failover 3) add a module parameter "ds_send_socket" to define a global socket The logic to select the sending socket would be: 1) if the gateway has send socket configured, use it 2) else, if configured, use the socket specified in ds_send_socket 3 else use the socket corresponding to the first listen directive (current behaviour) What do you think about? Do you find that this would be generally useful? About adding the send socket per gateway: how do you think it should be configured? In a dedicated column (db or file) or in the attrs parameter (just adding another attributes)? Looking forward to your feedback. Cheers, Federico

2 4

kamailio 4.1.6 (x86_64/linux) 010d57 Crash
by Kristian Kielhofner 07 Nov '14

07 Nov '14

Hello, We recently upgraded several of our Kamailio instances to 4.1.6 and have experienced this crash on several of them (full backtrace attached). #0 0x00000031e9e30265 in raise () from /lib64/libc.so.6 #1 0x00000031e9e31d10 in abort () from /lib64/libc.so.6 #2 0x00000000004687de in sig_alarm_abort (signo=14) at main.c:687 #3 <signal handler called> #4 0x00000031e9ed07c9 in syscall () from /lib64/libc.so.6 #5 0x00002acddbc4ff24 in futex_get (lock=0x2acdddcad6d8) at ../../mem/../futexlock.h:110 #6 0x00002acddbc50555 in remove_dialog_timer (tl=0x2acde2bcb708) at dlg_timer.c:168 #7 0x00002acddbc3edb8 in destroy_dlg (dlg=0x2acde2bcb6b0) at dlg_hash.c:357 #8 0x00002acddbc3f70a in destroy_dlg_table () at dlg_hash.c:438 #9 0x00002acddbc25c21 in mod_destroy () at dialog.c:776 #10 0x00000000004f7ebb in destroy_modules () at sr_module.c:817 #11 0x00000000004672c4 in cleanup (show_status=1) at main.c:562 #12 0x0000000000468952 in shutdown_children (sig=15, show_status=1) at main.c:704 #13 0x000000000046a012 in handle_sigs () at main.c:795 #14 0x000000000046e33c in main_loop () at main.c:1748 #15 0x0000000000470ac9 in main (argc=7, argv=0x7fff100e4068) at main.c:2547 Any thoughts? Thanks! -- Kristian Kielhofner

3 5

json-c and rabbitmq-c
by Luis Azedo 07 Nov '14

07 Nov '14

Hi List, there has been some problems trying to create builds for module kazoo due to the dependency of libraries (subject). i think that one possible (tested successfully) solution is to integrate these libraries in lib folder and distribute them as part of kamailio. i created them with "kamailio-" prefix and changed kazoo makefile to refer to these. if we proceed with this change, other modules dependent of json could also benefit from this inclusion. Thoughts ?

3 26

any reason why pua publ_info does not include outbound_proxy?
by Juha Heinanen 04 Nov '14

04 Nov '14

pua subs_info has str* outbound_proxy; /* the outbound_proxy to use when sending the Subscribe request*/ but publ_info for publish requests does not have it? is there some good reason or just that no-one has needed it? -- juha

2 7

Re: [sr-dev] Is there a sense in calling run_onsend() after the msg_send() function?
by Lucian Balaceanu 04 Nov '14

04 Nov '14

Hello Daniel, I must admit I only saw your mail last Friday. Until the 10th of October I was also on vacation. I know that you actually committed some of the changes together with your comments on the 12th this month. I don't know if we can consider the topic of the patch closed. As far as I understand, the state-full replies have not been addressed, right? (There should be a change in the t_reply.c) I followed the code to the relay_reply but I did not yet come to find the send function. Should I pursue further? Thank you, Lucian Balaceanu > Hi Lucian, > > somehow I forgot to follow up on this. But we need to get sorted out > soon, before we release, so it works as expected with the new version. > See more comments inline. > > > On 17/09/14 18:09, Lucian Balaceanu wrote: >> Hi Daniel, >> >> Please forgive me for my delay in responding to your mail. >> Please find attached a second version of the onsend_route_reply patch >> (which again has some problems). As per your previous indications I >> did the following: >> >> *Issue1* >>> From performances point of view, there can be added a config >>> parameter to enable running of onsend_route for replies: >>> >>> onsend_route_reply = 0|1 >> >> Following >> http://www.asipto.com/pub/kamailio-devel-guide/#c08add_parameters I >> have tried to add onsend_route_reply parameter. The code compiles, >> but when trying to start kamailio with this parameter inside, the >> parsing fails with syntax errors signaling: >> >> / 0(1321) :<core> [cfg.y:3423]: yyerror_at(): parse error in config >> file kamailio-basic.cfg.4.1, from line 107, column 1 to line 108, >> column 0: syntax error >> 0(1321) : <core> [cfg.y:3423]: yyerror_at(): parse error in config >> file kamailio-basic.cfg.4.1, from line 107, column 1 to line 108, >> column 0: >> ERROR: bad config file (2 errors)/ > > The issue is: > > +<INITIAL>{ONSEND_RT_REPLY} { yylval.intval=atoi(yytext); > + yy_number_str=yytext; return NUMBER; } > > It should be: > > +<INITIAL>{ONSEND_RT_REPLY} { yylval.intval=atoi(yytext); > + yy_number_str=yytext; return ONSEND_RT_REPLY; } > >> >> *Issue2* >>> #define onsend_enabled(rtype) >>> (onsend_rt.rlist[DEFAULT_RT]?((rtype==SIP_REPLY)?onsend_route_reply:1):0) >> That is to say you see it best to take the chek for >> onsend_rt.list[DEFAULT_RT] from inside run_onsend() function and call >> this onsend_enabled(...) before the run_onsend()? > > This is to detect whether the onsend_route should be executed for SIP > replies. The condition being: > > - if is a sip reply and onsend_route is set and the onsend_route_reply > parameter is 1 >> >> *Issue3* >>> On the other hand, is onsend_route also executed for local requests? >>> I had in mind it is only for received requests that are forwarded >>> ... Iirc, on onsend_route, the sip message is the one received, the >>> outgoing content being accessible via $snd(buf). >>> >> I agree with you with taking out the locally generated requests and >> only left the run_onsend call in do_forward_reply function (inside >> forward.c). >> Could you point me to the reply relaying function that is called for >> state-full processing? > Stateful processing for replies is mainly done in t_reply.c from tm > module. At some point there should be a send buffer function call. > > Cheers, > Daniel >> >> Thank you and sorry again for my late answer, >> Lucian > > -- > Daniel-Constantin Mierla > http://twitter.com/#!/miconda -http://www.linkedin.com/in/miconda > >

2 2

git:master: pipelimit: update the limit of pipe for pl_check(pipeid, alg, limit)
by Daniel-Constantin Mierla 03 Nov '14

03 Nov '14

Module: sip-router Branch: master Commit: 280f947eac5c66bfa6151c75983ffa9e533dd709 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=280f947… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Thu Oct 30 22:29:01 2014 +0100 pipelimit: update the limit of pipe for pl_check(pipeid, alg, limit) - affects the dynamic pipes that could have been created by same function on a previous execution, allowing to be on-the-fly updated - reported by Alex Balashov --- modules/pipelimit/pipelimit.c | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/modules/pipelimit/pipelimit.c b/modules/pipelimit/pipelimit.c index 3e6b918..a060df7 100644 --- a/modules/pipelimit/pipelimit.c +++ b/modules/pipelimit/pipelimit.c @@ -625,9 +625,9 @@ static int w_pl_check3(struct sip_msg* msg, char *p1pipe, char *p2alg, if(msg==NULL) return -1; - if(fixup_get_ivalue(msg, (gparam_t*)p3limit, &limit)!=0 || limit<=0) + if(fixup_get_ivalue(msg, (gparam_t*)p3limit, &limit)!=0 || limit<0) { - LM_ERR("invalid limit value\n"); + LM_ERR("invalid limit value: %d\n", limit); return -1; } @@ -645,7 +645,7 @@ static int w_pl_check3(struct sip_msg* msg, char *p1pipe, char *p2alg, return -1; } - pipe = pl_pipe_get(&pipeid, 0); + pipe = pl_pipe_get(&pipeid, 1); if(pipe==NULL) { LM_DBG("pipe not found [%.*s] - trying to add it\n", @@ -663,6 +663,9 @@ static int w_pl_check3(struct sip_msg* msg, char *p1pipe, char *p2alg, pipeid.len, pipeid.s); return -2; } + } else { + if(limit>0) pipe->limit = limit; + pl_pipe_release(&pipe->name); } return pl_check(msg, &pipeid);

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev October 2014