sr-dev October 2014

sr-dev@lists.kamailio.org

34 participants
382 discussions

[tracker] Comment added: CRASH: segmentation fault on module db_cluster with postgres
by sip-router 07 Oct '14

07 Oct '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#476 - CRASH: segmentation fault on module db_cluster with postgres User who did this - Daniel-Constantin Mierla (miconda) ---------- I assume you have: modparam("siptrace", "trace_delayed", 1) Postgress does not support that, use: modparam("siptrace", "trace_delayed", 0) I will look at db_cluster and see how to avoid the crash. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=476#comment1655 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 opened: CRASH: segmentation fault on module db_cluster with postgres (Attachment added)
by sip-router 07 Oct '14

07 Oct '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Nuno Miguel Reis (nmreis) Attached to Project - sip-router Summary - CRASH: segmentation fault on module db_cluster with postgres Task Type - Bug Report Category - Module Status - Unconfirmed Assigned To - Operating System - Linux Severity - High Priority - Normal Reported Version - 4.1 Due in Version - Undecided Due Date - Undecided Details - kamailio segfaults when using db_cluster/postgres and sip_trace. It appears to work fine with some other lighter queries. Please find attached the usual required data with the full backtrace. Let me know if anything else is needed. One or more files have been attached. More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=476 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 opened: Documentation Incorrect
by sip-router 07 Oct '14

07 Oct '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Fred Posner (qxork) Attached to Project - sip-router Summary - Documentation Incorrect Task Type - Bug Report Category - dialog Status - Unconfirmed Assigned To - Operating System - All Severity - Low Priority - Normal Reported Version - 4.1 Due in Version - Undecided Due Date - Undecided Details - Documentation in Dialog module lists items, such as: 5.24. caller_contact_column (string) The column name in the database to store the caller's contact uri. Default value is “from_contact”. Example 1.24. Set caller_contact_column parameter ... modparam("dialog", "caller_contact_column", "column_name") ... In the database, the default column appears to be "caller_contact" User on irc reports the following: " [modparam.c:152]: set_mod_param_regex(): set_mod_param_regex: parameter <caller_contact_column> of type <1> not found in module <dialog>" More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=475 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

Infinite loop in xavp linked list
by Waite, Hugh 07 Oct '14

07 Oct '14

Hello, I believe I have found a bug in the xavp code (or a module that manipulates them - most likely the usrloc "ulattrs" feature), but I don't understand some bits of the xavp structure. FYI the code I am running isn't master, it's from branch 4.1 plus a backport of my ulattrs from DB patch (http://git.sip-router.org/cgi-bin/gitweb.cgi?p=kamailio;a=commit;h=22b559cb…). Basically the linked list of xavp values links back to the top and creates an infinite loop when searching/inserting/deleting etc. (gdb) bt #0 0x0000000000544235 in xavp_get_internal (name=0x7fbac95d11f8, list=0x7fbaae036248, idx=0, prv=0x0) at xavp.c:267 #1 0x0000000000544325 in xavp_get_by_index (name=0x7fbac95d11f8, idx=0, start=0x7fbaae036248) at xavp.c:288 #2 0x00007fbac3316074 in pv_get_xavp (msg=0x7fbac961f958, param=0x7fbac95d1638, res=0x7fff99ae69d0) at pv_xavp.c:133 #3 0x00000000004995c8 in pv_get_spec_value (msg=0x7fbac961f958, sp=0x7fbac95d1620, value=0x7fff99ae69d0) at pvapi.c:1266 #4 0x00000000004c8c68 in rv_defined (h=0x7fff99ae72d0, msg=0x7fbac961f958, res=0x7fff99ae6fe8, rv=0x7fbac95d1618, cache=0x0) at rvalue.c:1859 #5 0x00000000004c8d1b in int_rve_defined (h=0x7fff99ae72d0, msg=0x7fbac961f958, res=0x7fff99ae6fe8, rve=0x7fbac95d1610) at rvalue.c:1895 #6 0x00000000004c9ace in rval_expr_eval_int (h=0x7fff99ae72d0, msg=0x7fbac961f958, res=0x7fff99ae6fe8, rve=0x7fbac95d2538) at rvalue.c:2117 ... (gdb) p avp $12 = (sr_xavp_t *) 0x7fbaae0360d0 (gdb) p *avp $13 = {id = 2085639187, name = {s = 0x7fbaae036108 "ulattrs", len = 7}, val = {type = SR_XTYPE_XAVP, v = {i = -1375510160, s = {s = 0x7fbaae036170 "\305\345om", len = 0}, t = 140439760101744, l = 140439760101744, ll = 140439760101744, xavp = 0x7fbaae036170, data = 0x7fbaae036170}}, next = 0x7fbaae036228} (gdb) p *avp->next $14 = {id = 2085639187, name = {s = 0x7fbaae036260 "ulattrs", len = 7}, val = {type = SR_XTYPE_NULL, v = {i = 0, s = {s = 0x0, len = 0}, t = 0, l = 0, ll = 0, xavp = 0x0, data = 0x0}}, next = 0x7fbaae0360d0} (gdb) frame 0 #0 0x0000000000544235 in xavp_get_internal (name=0x7fbac95d11f8, list=0x7fbaae036248, idx=0, prv=0x0) at xavp.c:267 267 if(avp->id==id && avp->name.len==name->len (gdb) list 262 avp = *list; 263 else 264 avp = *_xavp_list_crt; 265 while(avp) 266 { 267 if(avp->id==id && avp->name.len==name->len 268 && strncmp(avp->name.s, name->s, name->len)==0) 269 { 270 if(idx==n) 271 return avp; (gdb) 272 n++; 273 } 274 if(prv) 275 *prv = avp; 276 avp = avp->next; 277 } 278 return NULL; 279 } 280 281 sr_xavp_t *xavp_get(str *name, sr_xavp_t *start) I assume these linked lists should be NULL terminated (i.e. avp->next == NULL) and therefore it is a bug that my list above is a loop. My server has got stuck because it is searching for the name of an item that is inside the nested 'ulattrs' xavp. Can someone explain the purpose of the SR_XTYPE_NULL entry? Can anyone else see a problem either with my patch or the xavp add/insert code that it calls? I based my patch on the code in uldb_preload_attrs(), also in udomain.c. Regards, Hugh ________________________________ This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.

1 0

rtpengine add itself only as relay candidate?
by Peter Villeneuve 07 Oct '14

07 Oct '14

Hi, I believe this has been discussed before but I can't find a definitive answer. Using kamailio 4.2 with rtpengine. My clients don't have natively any ICE relay candidates, just host and server reflexive from STUN. What is the correct syntax to have rtpengine only add itself as relay candidate with lowest priority? The current basic kamailio config I'm testing has rtpengine_manage empty of flags, which is almost working except that rtpengine's default behaviour in my circumstance is to add itself as a host candidate. Reading through http://kamailio.org/docs/modules/devel/modules/rtpengine.html I believe what I want (ie. rtpengine adding itself as relay candidate only with lowest priority - not touching the rest of the SDP or any other ICE candidates sent by the clients) is not an option. Is my interpretaion correct or am I missing something glaringly obvious? Thanks, Peter >From the module's documentation: "The default (if no “ICE=...” is given at all), new ICE data will only be generated if no ICE was present in the SDP originally; otherwise the RTP proxy will only insert itself as *additional* ICE candidate." Relevant kamailio config snippet: route[NATMANAGE] { #!ifdef WITH_NAT if (is_request()) { if(has_totag()) { if(check_route_param("nat=yes")) { setbflag(FLB_NATB); } } } if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) return; rtpengine_manage(""); if (is_request()) { if (!has_totag()) { if(t_is_branch_route()) { add_rr_param(";nat=yes"); } } } if (is_reply()) { if(isbflagset(FLB_NATB)) { if(is_first_hop()) set_contact_alias(); } } #!endif return; }

2 6

git:master: acc: option to work on a cloned sip msg request for getting acc attributes
by Daniel-Constantin Mierla 07 Oct '14

07 Oct '14

Module: sip-router Branch: master Commit: 15fc8b9c59aaf31f005e38f54d363f1e9d0a068e URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=15fc8b9… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Tue Oct 7 08:48:31 2014 +0200 acc: option to work on a cloned sip msg request for getting acc attributes - it applies for callback done in tm on reply received - avoids working on the shm stored request that can be concurently accessed and some header shortcuts can become set - clone_msg - new parameter to control this behavior, default is 1 (use a cloned structure) --- modules/acc/acc_logic.c | 40 +++++++++++++++++++++++++--------------- modules/acc/acc_mod.c | 20 +++++++++++--------- 2 files changed, 36 insertions(+), 24 deletions(-) diff --git a/modules/acc/acc_logic.c b/modules/acc/acc_logic.c index 975c0f9..bd3f1cc 100644 --- a/modules/acc/acc_logic.c +++ b/modules/acc/acc_logic.c @@ -482,6 +482,7 @@ static inline void on_missed(struct cell *t, struct sip_msg *req, } +extern int _acc_clone_msg; /* initiate a report if we previously enabled accounting for this t */ static inline void acc_onreply( struct cell* t, struct sip_msg *req, @@ -490,6 +491,8 @@ static inline void acc_onreply( struct cell* t, struct sip_msg *req, str new_uri_bk; int br = -1; hdr_field_t *hdr; + sip_msg_t tmsg; + sip_msg_t *preq; /* acc_onreply is bound to TMCB_REPLY which may be called from _reply, like when FR hits; we should not miss this @@ -500,6 +503,13 @@ static inline void acc_onreply( struct cell* t, struct sip_msg *req, if (!should_acc_reply(req, reply, code)) return; + if(_acc_clone_msg==1) { + memcpy(&tmsg, req, sizeof(sip_msg_t)); + preq = &tmsg; + } else { + preq = req; + } + /* get winning branch index, if set */ if (t->relayed_reply_branch>=0) { br = t->relayed_reply_branch; @@ -511,9 +521,9 @@ static inline void acc_onreply( struct cell* t, struct sip_msg *req, /* for reply processing, set as new_uri the one from selected branch */ if (br>=0) { - new_uri_bk = req->new_uri; - req->new_uri = t->uac[br].uri; - req->parsed_uri_ok = 0; + new_uri_bk = preq->new_uri; + preq->new_uri = t->uac[br].uri; + preq->parsed_uri_ok = 0; } else { new_uri_bk.len = -1; new_uri_bk.s = 0; @@ -522,31 +532,31 @@ static inline void acc_onreply( struct cell* t, struct sip_msg *req, env_set_to( get_rpl_to(t,reply) ); env_set_code_status( code, reply); - if ( is_log_acc_on(req) ) { + if ( is_log_acc_on(preq) ) { env_set_text( ACC_ANSWERED, ACC_ANSWERED_LEN); - acc_log_request(req); + acc_log_request(preq); } #ifdef SQL_ACC - if (is_db_acc_on(req)) { - if(acc_db_set_table_name(req, db_table_acc_data, &db_table_acc)<0) { + if (is_db_acc_on(preq)) { + if(acc_db_set_table_name(preq, db_table_acc_data, &db_table_acc)<0) { LM_ERR("cannot set acc db table name\n"); } else { - acc_db_request(req); + acc_db_request(preq); } } #endif #ifdef RAD_ACC - if (is_rad_acc_on(req)) - acc_rad_request(req); + if (is_rad_acc_on(preq)) + acc_rad_request(preq); #endif /* DIAMETER */ #ifdef DIAM_ACC - if (is_diam_acc_on(req)) - acc_diam_request(req); + if (is_diam_acc_on(preq)) + acc_diam_request(preq); #endif /* run extra acc engines */ - acc_run_engines(req, 0, NULL); + acc_run_engines(preq, 0, NULL); if (new_uri_bk.len>=0) { req->new_uri = new_uri_bk; @@ -556,8 +566,8 @@ static inline void acc_onreply( struct cell* t, struct sip_msg *req, /* free header's parsed structures that were added by resolving acc attributes */ for( hdr=req->headers ; hdr ; hdr=hdr->next ) { if ( hdr->parsed && hdr_allocs_parse(hdr) && - (hdr->parsed<(void*)t->uas.request || - hdr->parsed>=(void*)t->uas.end_request)) { + (hdr->parsed<(void*)t->uas.request || + hdr->parsed>=(void*)t->uas.end_request)) { /* header parsed filed doesn't point inside uas.request memory * chunck -> it was added by resolving acc attributes -> free it as pkg */ DBG("removing hdr->parsed %d\n", hdr->type); diff --git a/modules/acc/acc_mod.c b/modules/acc/acc_mod.c index 831a137..2939cd3 100644 --- a/modules/acc/acc_mod.c +++ b/modules/acc/acc_mod.c @@ -119,6 +119,7 @@ int reason_from_hf = 0; /*!< assign reason from reason hf if present */ int acc_time_mode = 0; str acc_time_attr = str_init("time_attr"); str acc_time_exten = str_init("time_exten"); +int _acc_clone_msg = 1; /*@}*/ @@ -275,14 +276,14 @@ static param_export_t params[] = { {"cdr_extra", PARAM_STRING, &cdr_log_extra_str }, {"cdr_start_id", PARAM_STR, &cdr_start_str }, {"cdr_end_id", PARAM_STR, &cdr_end_str }, - {"cdr_duration_id", PARAM_STR, &cdr_duration_str }, + {"cdr_duration_id", PARAM_STR, &cdr_duration_str }, {"cdr_expired_dlg_enable", INT_PARAM, &cdr_expired_dlg_enable }, #ifdef RAD_ACC - {"radius_config", PARAM_STRING, &radius_config }, + {"radius_config", PARAM_STRING, &radius_config }, {"radius_flag", INT_PARAM, &radius_flag }, {"radius_missed_flag", INT_PARAM, &radius_missed_flag }, {"service_type", INT_PARAM, &service_type }, - {"radius_extra", PARAM_STRING, &rad_extra_str }, + {"radius_extra", PARAM_STRING, &rad_extra_str }, #endif /* DIAMETER specific */ #ifdef DIAM_ACC @@ -290,13 +291,13 @@ static param_export_t params[] = { {"diameter_missed_flag", INT_PARAM, &diameter_missed_flag }, {"diameter_client_host", PARAM_STRING, &diameter_client_host }, {"diameter_client_port", INT_PARAM, &diameter_client_port }, - {"diameter_extra", PARAM_STRING, &dia_extra_str }, + {"diameter_extra", PARAM_STRING, &dia_extra_str }, #endif /* db-specific */ #ifdef SQL_ACC - {"db_flag", INT_PARAM, &db_flag }, - {"db_missed_flag", INT_PARAM, &db_missed_flag }, - {"db_extra", PARAM_STRING, &db_extra_str }, + {"db_flag", INT_PARAM, &db_flag }, + {"db_missed_flag", INT_PARAM, &db_missed_flag }, + {"db_extra", PARAM_STRING, &db_extra_str }, {"db_url", PARAM_STR, &db_url }, {"db_table_acc", PARAM_STR, &db_table_acc }, {"db_table_missed_calls",PARAM_STR, &db_table_mc }, @@ -307,14 +308,15 @@ static param_export_t params[] = { {"acc_sip_code_column", PARAM_STR, &acc_sipcode_col }, {"acc_sip_reason_column",PARAM_STR, &acc_sipreason_col }, {"acc_time_column", PARAM_STR, &acc_time_col }, - {"db_insert_mode", INT_PARAM, &acc_db_insert_mode }, + {"db_insert_mode", INT_PARAM, &acc_db_insert_mode }, #endif /* time-mode-specific */ {"time_mode", INT_PARAM, &acc_time_mode }, {"time_attr", PARAM_STR, &acc_time_attr }, {"time_exten", PARAM_STR, &acc_time_exten }, {"cdrs_table", PARAM_STR, &acc_cdrs_table }, - {"time_format", PARAM_STRING, &acc_time_format }, + {"time_format", PARAM_STRING, &acc_time_format }, + {"clone_msg", PARAM_INT, &_acc_clone_msg }, {0,0,0} };

1 0

git:master: acc: docs for clone_msg parameter
by Daniel-Constantin Mierla 07 Oct '14

07 Oct '14

Module: sip-router Branch: master Commit: 941de2f0c8bfeb81f138ef03ce55e9da6534e82a URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=941de2f… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Tue Oct 7 08:55:26 2014 +0200 acc: docs for clone_msg parameter --- modules/acc/README | 292 +++++++++++++++++++++++----------------- modules/acc/doc/acc_admin.xml | 22 +++ 2 files changed, 190 insertions(+), 124 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=941…

1 0

[tracker] Comment added: Segfault in dialog.so
by sip-router 06 Oct '14

06 Oct '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#474 - Segfault in dialog.so User who did this - Daniel-Constantin Mierla (miconda) ---------- If you installed at the release date or used debian packages for the release, then upgrade to latest branch 4.1 or use nightly builds for 4.1.x. There was a fix in dialog module regarding clean up of unestablished dialogs lasting too long. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=474#comment1654 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 opened: Segfault in dialog.so (Attachment added)
by sip-router 06 Oct '14

06 Oct '14

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. A new Flyspray task has been opened. Details are below. User who did this - Dmitry Davletbaev (ddomgn) Attached to Project - sip-router Summary - Segfault in dialog.so Task Type - Bug Report Category - dialog Status - Unconfirmed Assigned To - Operating System - Linux Severity - High Priority - Normal Reported Version - 4.1 Due in Version - Undecided Due Date - Undecided Details - Operating system: Debian Wheezy 7.6 Kamailio version: 4.1.6 Unpredictable crashes of Kamailio due to segfault in dialog.so. The process can run all day long without any crash, but the next day it can crush every hour or so. Syslog: Oct 2 14:25:35 tel kernel: [5978975.159531] kamailio[16869]: segfault at 40 ip b6a8c0fe sp bfb598c0 error 4 in dialog.so[b6a58000+4d0 00] Two files containing logs are attached: pid-16858.log is main Kamailio process logs and pid-16869.log is crashed child logs. The segfault in these logs took place at Oct 2 14:25:35. I can provide more logs if it is necessary. I downgraded to 4.1.5 and no segfaults occurred since then. One or more files have been attached. More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=474 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: kamctl: refreshed the sql scripts from schema xml files
by Daniel-Constantin Mierla 05 Oct '14

05 Oct '14

Module: sip-router Branch: master Commit: bb493249566f5572eae23df90a383f0f3112d365 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=bb49324… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Sun Oct 5 22:48:39 2014 +0200 kamctl: refreshed the sql scripts from schema xml files --- utils/kamctl/db_berkeley/kamailio/version | 6 +++--- utils/kamctl/db_sqlite/acc-create.sql | 8 ++++---- utils/kamctl/db_sqlite/dialplan-create.sql | 6 +++--- utils/kamctl/dbtext/kamailio/version | 6 +++--- utils/kamctl/mysql/acc-create.sql | 8 ++++---- utils/kamctl/mysql/dialplan-create.sql | 6 +++--- utils/kamctl/oracle/acc-create.sql | 8 ++++---- utils/kamctl/oracle/dialplan-create.sql | 6 +++--- utils/kamctl/postgres/acc-create.sql | 8 ++++---- utils/kamctl/postgres/dialplan-create.sql | 6 +++--- utils/kamctl/xhttp_pi/pi_framework.xml | 22 +++++++++++----------- 11 files changed, 45 insertions(+), 45 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=bb4…

1 0

← Newer
1
...
25
26
27
28
29
30
31
...
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