sr-dev October 2014

sr-dev@lists.kamailio.org

34 participants
382 discussions

Fw: query related to NOTIFY message size
by Piyush.Bansal＠relianceada.com 17 Oct '14

17 Oct '14

please help ----- Forwarded by Piyush Bansal/RCOM/RelianceADA on 10/10/2013 10:51 AM ----- From: Piyush Bansal/RCOM/RelianceADA To: serusers(a)iptel.org, serdev(a)iptel.org Date: 10/09/2013 12:14 PM Subject: query related to NOTIFY message size Hi there, I have certain queries regarding batch SUBSCRIBE and NOTIFY. I have a user who has 100 buddies in his buddy list. If any of his buddy changes his/her presence status, that user gets a NOTIFY message with presence status of all the 100 buddies. In that case, the message size is exceeding 500 KB. Thats quite a higher value for a UDP packet. Can anybody suggest- 1. If there is any way to restrict the size of the packet. 2. How to ensure that the packet is received correctly by the client. Thanks and Regards, --Piyush Bansal The information contained in this electronic message (email) and any attachments to this email are intended for the exclusive use of the addressee(s) and access to this email by any one else is unauthorised. The email may contain proprietary, confidential or privileged information or information relating to Reliance Group. If you are not the intended recipient, please notify the sender by telephone, fax, or return email and delete this communication and any attachments thereto, immediately from your computer. Any dissemination, distribution, or copying of this communication and the attachments thereto (in whole or part), in any manner, is strictly prohibited and actionable at law. The recipient acknowledges that emails are susceptible to alteration and their integrity can not be guaranteed and that Company does not guarantee that any e-mail is virus-free and accept no liability for any damage caused by any virus transmitted by this email.

4 10

Kamailio v4.2.0 RPMs and updates to rpm.kamailio.org
by Daniel-Constantin Mierla 17 Oct '14

17 Oct '14

Hello, the RPMs for Kamailio v4.2.0 were generated for Centos (5, 6, 7), Fedora (18, 19, 20), OpenSuse (12.3, 13.1, 13.2) and RedHat (5, 6, 7). Packages are made with OpenSuse build service, but as different build project -- see the details at: - http://www.kamailio.org/wiki/packages/rpms The change was made to have a build project for each release series from now on, making easier to manage and mirror. Given this, the mirror at rpm.kamailio.org has been updated as well. If you used it for 4.1.x or older releases, you have to upgrade the repo path, see: - http://rpm.kamailio.org And again a call for people using RPMs: join the efforts in packaging and managing there repos, we have the infrastructure now, but we are short in time/human resources. If you want to keep the packages up to date, come on board and help a bit. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

1 0

[tracker] Comment added: deadlock if calling t_check_trans() from failure route
by sip-router 17 Oct '14

17 Oct '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#482 - deadlock if calling t_check_trans() from failure route User who did this - Daniel-Constantin Mierla (miconda) ---------- The function t_check_trans() is not allowed in failure_route by exports flags. Calling it via sub-route is skipping that restriction. You can use t_is_failure_route() like in your last comment to protect from config. Perhaps the condition on failure_route execution can be included inside the function for better safety. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=482#comment1679 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.

1 0

[tracker] Comment added: deadlock if calling t_check_trans() from failure route
by sip-router 17 Oct '14

17 Oct '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#482 - deadlock if calling t_check_trans() from failure route User who did this - Andrew Pogrebennyk (marduk) ---------- Actually the proper work-around would be if(!t_is_failure_route() && !t_check_trans()) ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=482#comment1678 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.

1 0

[tracker] Task changed: deadlock if calling t_check_trans() from failure route
by sip-router 17 Oct '14

17 Oct '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has been changed. The changes are listed below. For full information about what has changed, visit the URL and click the History tab. FS#482 - deadlock if calling t_check_trans() from failure route User who did this: Daniel-Constantin Mierla (miconda) Task details edited: ------- Hello, i have a route that i use for rejecting the call with an option to play announcement. This is called from the request or from failure_route: <code> route[ROUTE_EARLY_REJECT] { if(!t_check_trans()) { t_newtran(); } if($var(announce_set) == 0) { route(ROUTE_ADD_CALLINFO_REPLY); t_reply("$avp(s:announce_code)", "$avp(s:announce_reason)"); exit; } else { # play announcement ... } </code> Now If I call it from the failure_route I get some kind of deadlock, where kamailio (4.1.6) is eating 100% cpu. If I kill it with SIGABRT I get this backtrace: <code> Program terminated with signal 6, Aborted. #0 0x00007fcac3283fb7 in sched_yield () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007fcac3283fb7 in sched_yield () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007fcabefe9275 in get_lock (lock=0x7fcaaf039c88) at ../../parser/../mem/../fastlock.h:307 #2 _lock (s=0x7fcaaf039c88) at lock.h:99 #3 t_retransmit_reply (t=0x7fcaaf0386f0) at t_reply.c:1600 #4 0x00007fcabf00798b in t_check_trans (msg=0x7fcabf22b3c0) at tm.c:2139 #5 0x0000000000420ba0 in do_action (h=h@entry=0x7fff090c1210, a=a@entry=0x7fcac18fdc70, msg=msg@entry=0x7fcabf22b3c0) at action.c:1105 #6 0x000000000041fb70 in run_actions (h=h@entry=0x7fff090c1210, a=0x7fcac18fdc70, msg=0x7fcabf22b3c0) at action.c:1599 #7 0x0000000000428bf4 in run_actions_safe (h=h@entry=0x7fff090c21f0, a=<optimized out>, msg=<optimized out>) at action.c:1664 #8 0x00000000004dc730 in rval_get_int (h=0x7fff090c21f0, msg=<optimized out>, i=0x7fff090c15c0, rv=rv@entry=0x7fcac18fddb8, cache=cache@entry=0x0) at rvalue.c:924 #9 0x00000000004e1ad4 in rval_expr_eval_int (h=0x7fff090c21f0, msg=0x7fcabf22b3c0, res=res@entry=0x7fff090c15c0, rve=0x7fcac18fddb0) at rvalue.c:1918 #10 0x00000000004e1bae in rval_expr_eval_int (h=h@entry=0x7fff090c21f0, msg=msg@entry=0x7fcabf22b3c0, res=res@entry=0x7fff090c17c0, rve=rve@entry=0x7fcac18fe4d0) at rvalue.c:1926 #11 0x0000000000420f56 in do_action (h=h@entry=0x7fff090c21f0, a=a@entry=0x7fcac18fee10, msg=msg@entry=0x7fcabf22b3c0) at action.c:1075 #12 0x000000000041fb70 in run_actions (h=h@entry=0x7fff090c21f0, a=0x7fcac18fee10, msg=msg@entry=0x7fcabf22b3c0) at action.c:1599 #13 0x0000000000421128 in do_action (h=h@entry=0x7fff090c21f0, a=a@entry=0x7fcac1cb09f0, msg=msg@entry=0x7fcabf22b3c0) at action.c:715 #14 0x000000000041fb70 in run_actions (h=h@entry=0x7fff090c21f0, a=a@entry=0x7fcac1c33d98, msg=msg@entry=0x7fcabf22b3c0) at action.c:1599 #15 0x0000000000428c80 in run_top_route (a=0x7fcac1c33d98, msg=msg@entry=0x7fcabf22b3c0, c=c@entry=0x0) at action.c:1685 #16 0x00007fcabefe703a in run_failure_handlers (t=t@entry=0x7fcaaf0386f0, rpl=0x7fcac1fc2f88, code=500, extra_flags=extra_flags@entry=0) at t_reply.c:1061 #17 0x00007fcabefe8617 in t_should_relay_response (Trans=Trans@entry=0x7fcaaf0386f0, new_code=new_code@entry=500, branch=branch@entry=0, should_store=should_store@entry=0x7fff090c24d0, should_relay=should_relay@entry=0x7fff090c24c0, cancel_data=cancel_data@entry=0x7fff090c26c0, reply=reply@entry=0x7fcac1fc2f88) at t_reply.c:1416 #18 0x00007fcabefeab79 in relay_reply (t=t@entry=0x7fcaaf0386f0, p_msg=p_msg@entry=0x7fcac1fc2f88, branch=0, msg_status=msg_status@entry=500, cancel_data=cancel_data@entry=0x7fff090c26c0, do_put_on_wait=do_put_on_wait@entry=1) at t_reply.c:1819 #19 0x00007fcabefee3f4 in reply_received (p_msg=0x7fcac1fc2f88) at t_reply.c:2499 #20 0x000000000046d486 in do_forward_reply (msg=msg@entry=0x7fcac1fc2f88, mode=mode@entry=0) at forward.c:777 #21 0x000000000046dec7 in forward_reply (msg=msg@entry=0x7fcac1fc2f88) at forward.c:860 #22 0x00000000004b7f7e in receive_msg (buf=<optimized out>, len=<optimized out>, rcv_info=<optimized out>) at receive.c:273 ---Type <return> to continue, or q <return> to quit--- #23 0x00000000005538e1 in udp_rcv_loop () at udp_server.c:536 #24 0x000000000047b672 in main_loop () at main.c:1619 #25 0x000000000041f585 in main (argc=<optimized out>, argv=<optimized out>) at main.c:2547 </code> I need t_newtran() in case I'm calling this from request route, because I'm using t_reply() so I can workaround this by doing: <code> if(!t_check_trans() && !t_is_failure_route()) { t_newtran(); } </code> Is this expected to have a deadlock if calling t_check_trans() from failure route? ------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=482 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.

1 0

git:master: core: new parameter - max_branches
by Daniel-Constantin Mierla 17 Oct '14

17 Oct '14

Module: sip-router Branch: master Commit: e008edb9772c08bb0a34dd719516f2a9b7b46115 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=e008edb… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Fri Oct 17 11:04:23 2014 +0200 core: new parameter - max_branches - the maximum number of uac branches can be set via config - default value is 12 (old static value for MAX_BRNACHES) - the upper limit is 31, it has to be at least 1 - example: max_branches=16 --- cfg.lex | 2 ++ cfg.y | 2 ++ config.h | 3 ++- dns_cache.h | 6 ++---- dset.c | 24 +++++++++++++++++++++--- dset.h | 2 ++ globals.h | 2 ++ main.c | 7 +++++++ 8 files changed, 40 insertions(+), 8 deletions(-) diff --git a/cfg.lex b/cfg.lex index 1d5e40a..15cd19d 100644 --- a/cfg.lex +++ b/cfg.lex @@ -489,6 +489,7 @@ VERSION_TABLE_CFG "version_table" SERVER_ID "server_id" MAX_RECURSIVE_LEVEL "max_recursive_level" +MAX_BRANCHES_PARAM "max_branches"|"max_branches" LATENCY_LOG latency_log LATENCY_LIMIT_DB latency_limit_db @@ -936,6 +937,7 @@ IMPORTFILE "import_file" <INITIAL>{VERSION_TABLE_CFG} { count(); yylval.strval=yytext; return VERSION_TABLE_CFG;} <INITIAL>{SERVER_ID} { count(); yylval.strval=yytext; return SERVER_ID;} <INITIAL>{MAX_RECURSIVE_LEVEL} { count(); yylval.strval=yytext; return MAX_RECURSIVE_LEVEL;} +<INITIAL>{MAX_BRANCHES_PARAM} { count(); yylval.strval=yytext; return MAX_BRANCHES_PARAM;} <INITIAL>{LATENCY_LOG} { count(); yylval.strval=yytext; return LATENCY_LOG;} <INITIAL>{MSG_TIME} { count(); yylval.strval=yytext; return MSG_TIME;} <INITIAL>{ONSEND_RT_REPLY} { count(); yylval.strval=yytext; return ONSEND_RT_REPLY; } diff --git a/cfg.y b/cfg.y index 6a85292..7184191 100644 --- a/cfg.y +++ b/cfg.y @@ -543,6 +543,7 @@ extern char *default_routename; %token CFG_DESCRIPTION %token SERVER_ID %token MAX_RECURSIVE_LEVEL +%token MAX_BRANCHES_PARAM %token LATENCY_LOG %token LATENCY_LIMIT_DB %token LATENCY_LIMIT_ACTION @@ -1572,6 +1573,7 @@ assign_stm: | HTTP_REPLY_PARSE EQUAL error { yyerror("boolean value expected"); } | SERVER_ID EQUAL NUMBER { server_id=$3; } | MAX_RECURSIVE_LEVEL EQUAL NUMBER { set_max_recursive_level($3); } + | MAX_BRANCHES_PARAM EQUAL NUMBER { sr_dst_max_branches = $3; } | LATENCY_LOG EQUAL NUMBER { default_core_cfg.latency_log=$3; } | LATENCY_LOG EQUAL error { yyerror("number expected"); } | LATENCY_LIMIT_DB EQUAL NUMBER { default_core_cfg.latency_limit_db=$3; } diff --git a/config.h b/config.h index 172ee7d..23880a0 100644 --- a/config.h +++ b/config.h @@ -169,7 +169,8 @@ #define MAX_RECEIVED_SIZE 59 /*!< forwarding -- Via buffer dimensioning - Received header */ #define MAX_RPORT_SIZE 13 /*!< forwarding -- Via buffer dimensioning - Rport */ -#define MAX_BRANCHES 12 /*!< maximum number of branches per transaction */ +#define MAX_BRANCHES_DEFAULT 12 /*!< default maximum number of branches per transaction */ +#define MAX_BRANCHES_LIMIT 32 /*!< limit of maximum number of branches per transaction */ #define MAX_PRINT_TEXT 256 /*!< max length of the text of fifo 'print' command */ diff --git a/dns_cache.h b/dns_cache.h index e93b59b..b697b7c 100644 --- a/dns_cache.h +++ b/dns_cache.h @@ -166,10 +166,8 @@ struct dns_hash_entry{ }; -#if MAX_BRANCHES < 16 -/* forking is limited by tm to 12 by default */ -typedef unsigned short srv_flags_t; -#elif MAX_BRANCHES < 32 +/* to fit in the limit of MAX_BRANCHES */ +#if MAX_BRANCHES_LIMIT < 32 typedef unsigned int srv_flags_t; #else typedef unsigned long long srv_flags_t; diff --git a/dset.c b/dset.c index 8e7410e..43e28db 100644 --- a/dset.c +++ b/dset.c @@ -39,6 +39,7 @@ #include "parser/parser_f.h" #include "parser/parse_uri.h" #include "parser/msg_parser.h" +#include "globals.h" #include "ut.h" #include "hash_func.h" #include "error.h" @@ -58,9 +59,9 @@ /* * Where we store URIs of additional transaction branches - * (-1 because of the default branch, #0) + * (sr_dst_max_branches - 1 : because of the default branch for r-uri, #0 in tm) */ -static struct branch branches[MAX_BRANCHES - 1]; +static struct branch *branches = NULL; /* how many of them we have */ unsigned int nr_branches = 0; @@ -78,6 +79,23 @@ static qvalue_t ruri_q = Q_UNSPECIFIED; static flag_t ruri_bflags; +int init_dst_set(void) +{ + if(sr_dst_max_branches<=0 || sr_dst_max_branches>=MAX_BRANCHES_LIMIT) { + LM_ERR("invalid value for max branches parameter: %u\n", + sr_dst_max_branches); + return -1; + } + /* sr_dst_max_branches - 1 : because of the default branch for r-uri, #0 in tm */ + branches = (branch_t*)pkg_malloc((sr_dst_max_branches-1)*sizeof(branch_t)); + if(branches==NULL) { + LM_ERR("not enough memory to initialize destination branches\n"); + return -1; + } + memset(branches, 0, (sr_dst_max_branches-1)*sizeof(branch_t)); + return 0; +} + /*! \brief * Return pointer to branch[idx] structure * @param idx - branch index @@ -333,7 +351,7 @@ int append_branch(struct sip_msg* msg, str* uri, str* dst_uri, str* path, /* if we have already set up the maximum number * of branches, don't try new ones */ - if (unlikely(nr_branches == MAX_BRANCHES - 1)) { + if (unlikely(nr_branches == sr_dst_max_branches - 1)) { LM_ERR("max nr of branches exceeded\n"); ser_error = E_TOO_MANY_BRANCHES; return -1; diff --git a/dset.h b/dset.h index ff7e838..d90ce61 100644 --- a/dset.h +++ b/dset.h @@ -258,4 +258,6 @@ int setbflagsval(unsigned int branch, flag_t val); int uri_add_rcv_alias(sip_msg_t *msg, str *uri, str *nuri); int uri_restore_rcv_alias(str *uri, str *nuri, str *suri); +int init_dst_set(void); + #endif /* _DSET_H */ diff --git a/globals.h b/globals.h index 0a62d3e..1dc4194 100644 --- a/globals.h +++ b/globals.h @@ -50,6 +50,8 @@ extern int config_check; extern char* stat_file; extern unsigned short port_no; +extern unsigned int sr_dst_max_branches; /* max number of branches per transaction */ + extern time_t up_since; extern pid_t creator_pid; /* pid of first process before daemonization */ extern int uid; diff --git a/main.c b/main.c index 5aebc79..2e9d9fc 100644 --- a/main.c +++ b/main.c @@ -424,6 +424,9 @@ int sock_mode= S_IRUSR| S_IWUSR| S_IRGRP| S_IWGRP; /* rw-rw---- */ int server_id = 0; /* Configurable unique ID of the server */ +/* maximum number of branches for transaction */ +unsigned int sr_dst_max_branches = MAX_BRANCHES_DEFAULT; + /* set timeval for each received sip message */ int sr_msg_time = 1; @@ -2119,6 +2122,10 @@ try_again: pp_ifdef_level_check(); print_rls(); + if(init_dst_set()<0) { + LM_ERR("failed to initialize destination set structure\n"); + goto error; + } /* options with higher priority than cfg file */ optind = 1; /* reset getopt */ while((c=getopt(argc,argv,options))!=-1) {

2 2

[tracker] Task opened: deadlock if calling t_check_trans() from failure route
by sip-router 17 Oct '14

17 Oct '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Andrew Pogrebennyk (marduk) Attached to Project - sip-router Summary - deadlock if calling t_check_trans() from failure route Task Type - Bug Report Category - tm Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Normal Reported Version - Development Due in Version - Undecided Due Date - Undecided Details - Hello, i have a route that i use for rejecting the call with an option to play announcement. This is called from the request or from failure_route: route[ROUTE_EARLY_REJECT] { if(!t_check_trans()) { t_newtran(); } if($var(announce_set) == 0) { route(ROUTE_ADD_CALLINFO_REPLY); t_reply("$avp(s:announce_code)", "$avp(s:announce_reason)"); exit; } else { # play announcement ... } Now If I call it from the failure_route I get some kind of deadlock, where kamailio (4.1.6) is eating 100% cpu. If I kill it with SIGABRT I get this backtrace: Program terminated with signal 6, Aborted. #0 0x00007fcac3283fb7 in sched_yield () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007fcac3283fb7 in sched_yield () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007fcabefe9275 in get_lock (lock=0x7fcaaf039c88) at ../../parser/../mem/../fastlock.h:307 #2 _lock (s=0x7fcaaf039c88) at lock.h:99 #3 t_retransmit_reply (t=0x7fcaaf0386f0) at t_reply.c:1600 #4 0x00007fcabf00798b in t_check_trans (msg=0x7fcabf22b3c0) at tm.c:2139 #5 0x0000000000420ba0 in do_action (h=h@entry=0x7fff090c1210, a=a@entry=0x7fcac18fdc70, msg=msg@entry=0x7fcabf22b3c0) at action.c:1105 #6 0x000000000041fb70 in run_actions (h=h@entry=0x7fff090c1210, a=0x7fcac18fdc70, msg=0x7fcabf22b3c0) at action.c:1599 #7 0x0000000000428bf4 in run_actions_safe (h=h@entry=0x7fff090c21f0, a=<optimized out>, msg=<optimized out>) at action.c:1664 #8 0x00000000004dc730 in rval_get_int (h=0x7fff090c21f0, msg=<optimized out>, i=0x7fff090c15c0, rv=rv@entry=0x7fcac18fddb8, cache=cache@entry=0x0) at rvalue.c:924 #9 0x00000000004e1ad4 in rval_expr_eval_int (h=0x7fff090c21f0, msg=0x7fcabf22b3c0, res=res@entry=0x7fff090c15c0, rve=0x7fcac18fddb0) at rvalue.c:1918 #10 0x00000000004e1bae in rval_expr_eval_int (h=h@entry=0x7fff090c21f0, msg=msg@entry=0x7fcabf22b3c0, res=res@entry=0x7fff090c17c0, rve=rve@entry=0x7fcac18fe4d0) at rvalue.c:1926 #11 0x0000000000420f56 in do_action (h=h@entry=0x7fff090c21f0, a=a@entry=0x7fcac18fee10, msg=msg@entry=0x7fcabf22b3c0) at action.c:1075 #12 0x000000000041fb70 in run_actions (h=h@entry=0x7fff090c21f0, a=0x7fcac18fee10, msg=msg@entry=0x7fcabf22b3c0) at action.c:1599 #13 0x0000000000421128 in do_action (h=h@entry=0x7fff090c21f0, a=a@entry=0x7fcac1cb09f0, msg=msg@entry=0x7fcabf22b3c0) at action.c:715 #14 0x000000000041fb70 in run_actions (h=h@entry=0x7fff090c21f0, a=a@entry=0x7fcac1c33d98, msg=msg@entry=0x7fcabf22b3c0) at action.c:1599 #15 0x0000000000428c80 in run_top_route (a=0x7fcac1c33d98, msg=msg@entry=0x7fcabf22b3c0, c=c@entry=0x0) at action.c:1685 #16 0x00007fcabefe703a in run_failure_handlers (t=t@entry=0x7fcaaf0386f0, rpl=0x7fcac1fc2f88, code=500, extra_flags=extra_flags@entry=0) at t_reply.c:1061 #17 0x00007fcabefe8617 in t_should_relay_response (Trans=Trans@entry=0x7fcaaf0386f0, new_code=new_code@entry=500, branch=branch@entry=0, should_store=should_store@entry=0x7fff090c24d0, should_relay=should_relay@entry=0x7fff090c24c0, cancel_data=cancel_data@entry=0x7fff090c26c0, reply=reply@entry=0x7fcac1fc2f88) at t_reply.c:1416 #18 0x00007fcabefeab79 in relay_reply (t=t@entry=0x7fcaaf0386f0, p_msg=p_msg@entry=0x7fcac1fc2f88, branch=0, msg_status=msg_status@entry=500, cancel_data=cancel_data@entry=0x7fff090c26c0, do_put_on_wait=do_put_on_wait@entry=1) at t_reply.c:1819 #19 0x00007fcabefee3f4 in reply_received (p_msg=0x7fcac1fc2f88) at t_reply.c:2499 #20 0x000000000046d486 in do_forward_reply (msg=msg@entry=0x7fcac1fc2f88, mode=mode@entry=0) at forward.c:777 #21 0x000000000046dec7 in forward_reply (msg=msg@entry=0x7fcac1fc2f88) at forward.c:860 #22 0x00000000004b7f7e in receive_msg (buf=<optimized out>, len=<optimized out>, rcv_info=<optimized out>) at receive.c:273 ---Type <return> to continue, or q <return> to quit--- #23 0x00000000005538e1 in udp_rcv_loop () at udp_server.c:536 #24 0x000000000047b672 in main_loop () at main.c:1619 #25 0x000000000041f585 in main (argc=<optimized out>, argv=<optimized out>) at main.c:2547 I need t_newtran() in case I'm calling this from request route, because I'm using t_reply() so I can workaround this by doing: if(!t_check_trans() && !t_is_failure_route()) { t_newtran(); } Is this expected to have a deadlock if calling t_check_trans() from failure route? More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=482 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.

1 0

git:master: tm: transaction uses number of branches specified by max_branches global parameter
by Daniel-Constantin Mierla 17 Oct '14

17 Oct '14

Module: sip-router Branch: master Commit: a85e18b152f841e35d790f74164ce7d8deb22a57 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a85e18b… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Fri Oct 17 11:06:41 2014 +0200 tm: transaction uses number of branches specified by max_branches global parameter - the number of UACs per transaction is based on max_branches global parameter --- modules/tm/h_table.c | 18 +++++++++++++----- modules/tm/h_table.h | 4 ++-- modules/tm/t_fwd.c | 8 ++++---- modules/tm/t_lookup.c | 2 +- modules/tm/timer.c | 2 +- modules/tm/tm.c | 4 ++-- 6 files changed, 23 insertions(+), 15 deletions(-) diff --git a/modules/tm/h_table.c b/modules/tm/h_table.c index 051c326..d0d2d5b 100644 --- a/modules/tm/h_table.c +++ b/modules/tm/h_table.c @@ -290,7 +290,7 @@ static void inline init_branches(struct cell *t) unsigned int i; struct ua_client *uac; - for(i=0;i<MAX_BRANCHES;i++) + for(i=0;i<sr_dst_max_branches;i++) { uac=&t->uac[i]; uac->request.my_T = t; @@ -313,21 +313,29 @@ struct cell* build_cell( struct sip_msg* p_msg ) #ifdef WITH_XAVP sr_xavp_t** xold; #endif + unsigned int cell_size; - /* allocs a new cell, add space for md5 (MD5_LEN - sizeof(struct cell.md5)) */ - new_cell = (struct cell*)shm_malloc( sizeof( struct cell )+ - MD5_LEN-sizeof(((struct cell*)0)->md5) ); + /* allocs a new cell, add space for: + * md5 (MD5_LEN - sizeof(struct cell.md5)) + * uac (sr_dst_max_banches * sizeof(struct ua_client) ) */ + cell_size = sizeof( struct cell ) + MD5_LEN - sizeof(((struct cell*)0)->md5) + + (sr_dst_max_branches * sizeof(struct ua_client)); + + new_cell = (struct cell*)shm_malloc( cell_size ); if ( !new_cell ) { ser_error=E_OUT_OF_MEM; return NULL; } /* filling with 0 */ - memset( new_cell, 0, sizeof( struct cell ) ); + memset( new_cell, 0, cell_size ); /* UAS */ new_cell->uas.response.my_T=new_cell; init_rb_timers(&new_cell->uas.response); + /* UAC */ + new_cell->uac = (struct ua_client*)((char*)new_cell + sizeof(struct cell) + + MD5_LEN - sizeof(((struct cell*)0)->md5)); /* timers */ init_cell_timers(new_cell); diff --git a/modules/tm/h_table.h b/modules/tm/h_table.h index 42551bb..23d005f 100644 --- a/modules/tm/h_table.h +++ b/modules/tm/h_table.h @@ -427,7 +427,7 @@ typedef struct cell /* UA Server */ struct ua_server uas; /* UA Clients */ - struct ua_client uac[ MAX_BRANCHES ]; + struct ua_client *uac; /* store transaction state to be used for async transactions */ struct async_state async_backup; @@ -461,7 +461,7 @@ typedef struct cell #endif ticks_t end_of_life; /* maximum lifetime */ - /* nr of replied branch; 0..MAX_BRANCHES=branch value, + /* nr of replied branch; 0..sr_dst_max_branches=branch value, * -1 no reply, -2 local reply */ short relayed_reply_branch; diff --git a/modules/tm/t_fwd.c b/modules/tm/t_fwd.c index 61b6e6a..1e61183 100644 --- a/modules/tm/t_fwd.c +++ b/modules/tm/t_fwd.c @@ -746,7 +746,7 @@ int add_blind_uac( /*struct cell *t*/ ) } branch=t->nr_of_outgoings; - if (branch==MAX_BRANCHES) { + if (branch==sr_dst_max_branches) { LOG(L_ERR, "ERROR: add_blind_uac: " "maximum number of branches exceeded\n"); return -1; @@ -811,7 +811,7 @@ int add_uac( struct cell *t, struct sip_msg *request, str *uri, #endif /* TM_UAC_FLAGS */ branch=t->nr_of_outgoings; - if (branch==MAX_BRANCHES) { + if (branch==sr_dst_max_branches) { LOG(L_ERR, "ERROR: add_uac: maximum number of branches exceeded\n"); ret=ser_error=E_TOO_MANY_BRANCHES; goto error; @@ -898,7 +898,7 @@ static int add_uac_from_buf( struct cell *t, struct sip_msg *request, unsigned int len; branch=t->nr_of_outgoings; - if (branch==MAX_BRANCHES) { + if (branch==sr_dst_max_branches) { LOG(L_ERR, "ERROR: add_uac_from_buf: maximum number of branches" " exceeded\n"); ret=ser_error=E_TOO_MANY_BRANCHES; @@ -1060,7 +1060,7 @@ int add_uac_dns_fallback(struct cell *t, struct sip_msg* msg, return ret; } } - if (t->nr_of_outgoings >= MAX_BRANCHES){ + if (t->nr_of_outgoings >= sr_dst_max_branches){ LOG(L_ERR, "ERROR: add_uac_dns_fallback: maximum number of " "branches exceeded\n"); if (lock_replies) diff --git a/modules/tm/t_lookup.c b/modules/tm/t_lookup.c index cb3a720..79b1083 100644 --- a/modules/tm/t_lookup.c +++ b/modules/tm/t_lookup.c @@ -936,7 +936,7 @@ int t_reply_matching( struct sip_msg *p_msg , int *p_branch ) if (unlikely(reverse_hex2int(hashi, hashl, &hash_index)<0 ||hash_index>=TABLE_ENTRIES || reverse_hex2int(branchi, branchl, &branch_id)<0 - ||branch_id>=MAX_BRANCHES + || branch_id>=sr_dst_max_branches || loopl!=MD5_LEN) ) { DBG("DEBUG: t_reply_matching: poor reply labels %d label %d " diff --git a/modules/tm/timer.c b/modules/tm/timer.c index 6f1a597..7856570 100644 --- a/modules/tm/timer.c +++ b/modules/tm/timer.c @@ -491,7 +491,7 @@ inline static void final_response_handler( struct retr_buf* r_buf, #ifdef EXTRA_DEBUG DBG("DEBUG: final_response_handler:stop retr. and send CANCEL (%p)\n", t); #endif - if ((r_buf->branch < MAX_BRANCHES) && /* r_buf->branch is always >=0 */ + if ((r_buf->branch < sr_dst_max_branches) && /* r_buf->branch is always >=0 */ (t->uac[r_buf->branch].last_received==0) && (t->uac[r_buf->branch].request.buffer!=NULL) /* not a blind UAC */ ){ diff --git a/modules/tm/tm.c b/modules/tm/tm.c index 54bcc78..f3568c1 100644 --- a/modules/tm/tm.c +++ b/modules/tm/tm.c @@ -801,9 +801,9 @@ static int mod_init(void) /* checking if we have sufficient bitmap capacity for given maximum number of branches */ - if (MAX_BRANCHES+1>31) { + if (sr_dst_max_branches+1>31) { LOG(L_CRIT, "Too many max UACs for UAC branch_bm_t bitmap: %d\n", - MAX_BRANCHES ); + sr_dst_max_branches ); return -1; }

1 0

git:4.2: pipelimit: enhanced docs for pl_check() function
by Daniel-Constantin Mierla 17 Oct '14

17 Oct '14

Module: sip-router Branch: 4.2 Commit: 6d89d2328a375a6660e46a5031d66b16e05d0efb URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=6d89d23… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Fri Oct 17 09:42:13 2014 +0200 pipelimit: enhanced docs for pl_check() function - documented the algorithm and limit parameters (cherry picked from commit 24e76b1932fa8c4e1136ad82cb582a97c50244c4) --- modules/pipelimit/README | 13 ++++++++++++- 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/modules/pipelimit/README b/modules/pipelimit/README index 094622b..9f4caf1 100644 --- a/modules/pipelimit/README +++ b/modules/pipelimit/README @@ -308,7 +308,11 @@ kamcmd cfg.set_now_string pipelimit reply_reason "Limiting" * 2 if pipe has NOP algorithm Meaning of the parameters is as follows: - * name - the pseudovariable holding the pipe name. + * name - the string or pseudovariable with the pipe name. + * algorithm - the string or pseudovariable with the algorithm. The + values can be: taildrop, red, network or feedback - see readme of + ratelimit module for details on each algorithm. + * limit - the integer or pseudovariable with the limit value. This function can be used from REQUEST_ROUTE. @@ -347,6 +351,13 @@ with unexpected retcode=$var(check_result)\n"); exit; } ... + # perform pipe match for authenticated user + $var(limit) = 20; + if (!pl_check("$au", "traildrop", "$var(limit)")) { + pl_drop(); + exit; + } +... 4.2. pl_drop([ [min ], max ])

1 0

git:4.2: pipelimit: fix dynamic pipe limit check
by Daniel-Constantin Mierla 17 Oct '14

17 Oct '14

Module: sip-router Branch: 4.2 Commit: f78361d777c20436641bf16a024f12e6a8f3ed7f URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=f78361d… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Fri Oct 17 09:40:33 2014 +0200 pipelimit: fix dynamic pipe limit check - proper add and check at the same time (cherry picked from commit b76afe7c0699b936bec3d7bb1c3a740bf08fdb1c) --- modules/pipelimit/doc/pipelimit_admin.xml | 18 +++++++++++++++++- modules/pipelimit/pipelimit.c | 6 +++--- modules/pipelimit/pl_ht.c | 2 +- 3 files changed, 21 insertions(+), 5 deletions(-) diff --git a/modules/pipelimit/doc/pipelimit_admin.xml b/modules/pipelimit/doc/pipelimit_admin.xml index d2ae537..0983f60 100644 --- a/modules/pipelimit/doc/pipelimit_admin.xml +++ b/modules/pipelimit/doc/pipelimit_admin.xml @@ -302,7 +302,15 @@ modparam("pipelimit", "reply_reason", "Limiting") <para>Meaning of the parameters is as follows:</para> <itemizedlist> <listitem><para> - <emphasis>name</emphasis> - the pseudovariable holding the pipe name. + <emphasis>name</emphasis> - the string or pseudovariable with the pipe name. + </para></listitem> + <listitem><para> + <emphasis>algorithm</emphasis> - the string or pseudovariable with the + algorithm. The values can be: taildrop, red, network or feedback - see + readme of ratelimit module for details on each algorithm. + </para></listitem> + <listitem><para> + <emphasis>limit</emphasis> - the integer or pseudovariable with the limit value. </para></listitem> </itemizedlist> <para> @@ -345,6 +353,14 @@ with unexpected retcode=$var(check_result)\n"); exit; } ... + # perform pipe match for authenticated user + $var(limit) = 20; + if (!pl_check("$au", "traildrop", "$var(limit)")) { + pl_drop(); + exit; + } +... + </programlisting> </example> </section> diff --git a/modules/pipelimit/pipelimit.c b/modules/pipelimit/pipelimit.c index b76ba0d..3e6b918 100644 --- a/modules/pipelimit/pipelimit.c +++ b/modules/pipelimit/pipelimit.c @@ -645,7 +645,7 @@ static int w_pl_check3(struct sip_msg* msg, char *p1pipe, char *p2alg, return -1; } - pipe = pl_pipe_get(&pipeid, 1); + pipe = pl_pipe_get(&pipeid, 0); if(pipe==NULL) { LM_DBG("pipe not found [%.*s] - trying to add it\n", @@ -656,7 +656,7 @@ static int w_pl_check3(struct sip_msg* msg, char *p1pipe, char *p2alg, pipeid.len, pipeid.s); return -2; } - pipe = pl_pipe_get(&pipeid, 1); + pipe = pl_pipe_get(&pipeid, 0); if(pipe==NULL) { LM_ERR("failed to retrieve pipe [%.*s]\n", @@ -665,7 +665,7 @@ static int w_pl_check3(struct sip_msg* msg, char *p1pipe, char *p2alg, } } - return 1; + return pl_check(msg, &pipeid); } static int fixup_pl_check3(void** param, int param_no) diff --git a/modules/pipelimit/pl_ht.c b/modules/pipelimit/pl_ht.c index 3b4a3bd..6e48bb4 100644 --- a/modules/pipelimit/pl_ht.c +++ b/modules/pipelimit/pl_ht.c @@ -240,7 +240,7 @@ pl_pipe_t* pl_pipe_get(str *pipeid, int mode) if(pipeid->len==it->name.len && strncmp(pipeid->s, it->name.s, pipeid->len)==0) { - /* lock_release(&_pl_pipes_ht->slots[idx].lock);*/ + if(mode==0) lock_release(&_pl_pipes_ht->slots[idx].lock); return it; } it = it->next;

1 0

← Newer
1
...
9
10
11
12
13
14
15
...
39
Older →

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