sr-dev February 2014

sr-dev@lists.kamailio.org

38 participants
235 discussions

Re: [sr-dev] dialog module with DB Backend

by jay binks

So poking round the code for the dialog module.... Im not sure what im missing here. get_profile_size dosnt care bout the state of a dialog... so you get ALL dialogs that are in the hash table. ( which is interesting if you want to use dialog module to enforce channel limits etc ) So you go... OK... kamailio only expects to have "ACTIVE" dialogs in the hash table... kewl.. lets assume that to be the case. but then in dlg_db_handler.c , load_dialog_info_from_db loads all dialogs from the DB, regardless of state. so all dialogs in the DB ( ones that didnt get deleted yet... but were in state 5 ) get re-created in kamailio upon startup. what this means is... ( assume starting with empty DB ) I start kamailio, make some calls... they get synced to the DB. I end the calls, kamailio removes from dialogs module internal hash, but the sync to DB hasnt happened yet. I kill kamailio ( or crash .. whatever ).... restart kamailio and it re-loads all those dialogs and thinks they are still active calls. Im SURE Im missing something here, because it seems to be VERY common to use dialogs for channel limiting.. maybe not so much using cassandra db behind the scenes, but as of yet ... Im still yet to find anything that makes me thing this is db_cassandra mis-behaving. if im wrong, please point me in the right direction. Jay On 24 February 2014 17:54, jay binks <jaybinks(a)gmail.com> wrote: > Am I REALLY the only person who has ever run into this !? > > > On 19 February 2014 14:08, jay binks <jaybinks(a)gmail.com> wrote: > >> Hi all, im using the dialog module with db_cassandra backend.. >> I dont believe this issue is related to cassandra, but its worth >> mentioning anyways. >> >> so... I run kamailio, make calls, see dialogs in the DB.. >> and I Can use "kamctl mi dlg_list" and see that dialogs go away when I >> hangup a call.. >> >> When I query the DB Backend, I still see the queries, but they have a >> state of 5. >> I Initially thought this was a bug, but it seems dialogs in state 5 get >> cleaned up after a period. >> so I moved on. >> >> now , lets restart kamailio.. >> kamailio loads all dialogs on startup, after kamailio starts I call >> "kamctl mi dlg_list" again, and it shows all my dialogs from the DB. they >> DO show as "State 5" >> but for some reason, these dialogs appear to stick around for a long >> time, and the bigger issue it causes me is that my channel limiting ( >> using get_profile_size ) seems to consider these dialogs ( in state 5 ) as >> being active calls. >> >> Please someone point me in the right direction... :) >> >> what am I doing wrong ? >> ( or is this a bug somewhere ) >> >> Sincerely >> >> Jay >> > > > > -- > Sincerely > > Jay > -- Sincerely Jay

10 years, 9 months

git:master: registrar: allow randomization of expire value coming from UA

by Daniel-Constantin Mierla

Module: sip-router Branch: master Commit: 806e967e2e39e0140b992719e10693b9c768d758 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=806e967… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Fri Feb 21 21:07:43 2014 +0100 registrar: allow randomization of expire value coming from UA - new parameter expire_range - requested in FS#249 --- modules/registrar/config.c | 3 +++ modules/registrar/config.h | 2 ++ modules/registrar/reg_mod.c | 7 +++++++ modules/registrar/sip_msg.c | 7 ++++++- 4 files changed, 18 insertions(+), 1 deletions(-) diff --git a/modules/registrar/config.c b/modules/registrar/config.c index f183511..c52b9a4 100644 --- a/modules/registrar/config.c +++ b/modules/registrar/config.c @@ -34,6 +34,7 @@ struct cfg_group_registrar default_registrar_cfg = { STR_NULL, /* realm_pref */ 3600, /* default_expires */ 0, /* default_expires_range */ + 0, /* expires_range */ 60, /* min_expires */ 0, /* max_expires */ 0, /* max_contacts */ @@ -52,6 +53,8 @@ cfg_def_t registrar_cfg_def[] = { "Contains number of second to expire if no expire hf or contact expire present" }, {"default_expires_range", CFG_VAR_INT | CFG_CB_ONLY_ONCE, 0, 100, 0, default_expires_range_update, "Percent from default_expires that will be used in generating the range for the expire interval"}, + {"expires_range", CFG_VAR_INT | CFG_CB_ONLY_ONCE, 0, 100, 0, expires_range_update, + "Percent from incoming expires that will be used in generating the range for the expire interval"}, {"min_expires", CFG_VAR_INT | CFG_CB_ONLY_ONCE, 0, 0, 0, 0, "The minimum expires value of a Contact. Value 0 disables the checking. "}, {"max_expires", CFG_VAR_INT | CFG_CB_ONLY_ONCE, 0, 0, 0, max_expires_stats_update, diff --git a/modules/registrar/config.h b/modules/registrar/config.h index 496a14b..022b14d 100644 --- a/modules/registrar/config.h +++ b/modules/registrar/config.h @@ -30,6 +30,7 @@ struct cfg_group_registrar { str realm_pref; unsigned int default_expires; unsigned int default_expires_range; + unsigned int expires_range; unsigned int min_expires; unsigned int max_expires; unsigned int max_contacts; @@ -45,6 +46,7 @@ extern cfg_def_t registrar_cfg_def[]; extern void default_expires_stats_update(str*, str*); extern void default_expires_range_update(str*, str*); +extern void expires_range_update(str*, str*); extern void max_expires_stats_update(str*, str*); #endif diff --git a/modules/registrar/reg_mod.c b/modules/registrar/reg_mod.c index 4539f67..0b32ce4 100644 --- a/modules/registrar/reg_mod.c +++ b/modules/registrar/reg_mod.c @@ -153,6 +153,7 @@ stat_var *max_expires_stat; stat_var *max_contacts_stat; stat_var *default_expire_stat; stat_var *default_expire_range_stat; +stat_var *expire_range_stat; /** SL API structure */ sl_api_t slb; @@ -210,6 +211,7 @@ static cmd_export_t cmds[] = { static param_export_t params[] = { {"default_expires", INT_PARAM, &default_registrar_cfg.default_expires }, {"default_expires_range", INT_PARAM, &default_registrar_cfg.default_expires_range }, + {"expires_range", INT_PARAM, &default_registrar_cfg.expires_range }, {"default_q", INT_PARAM, &default_registrar_cfg.default_q }, {"append_branches", INT_PARAM, &default_registrar_cfg.append_branches }, {"case_sensitive", INT_PARAM, &default_registrar_cfg.case_sensitive }, @@ -244,6 +246,7 @@ stat_export_t mod_stats[] = { {"max_contacts", STAT_NO_RESET, &max_contacts_stat }, {"default_expire", STAT_NO_RESET, &default_expire_stat }, {"default_expires_range", STAT_NO_RESET, &default_expire_range_stat }, + {"expires_range", STAT_NO_RESET, &expire_range_stat }, {"accepted_regs", 0, &accepted_registrations }, {"rejected_regs", 0, &rejected_registrations }, {0, 0, 0} @@ -709,3 +712,7 @@ void max_expires_stats_update(str* gname, str* name){ void default_expires_range_update(str* gname, str* name){ update_stat(default_expire_range_stat, cfg_get(registrar, registrar_cfg, default_expires_range)); } + +void expires_range_update(str* gname, str* name){ + update_stat(expire_range_stat, cfg_get(registrar, registrar_cfg, expires_range)); +} diff --git a/modules/registrar/sip_msg.c b/modules/registrar/sip_msg.c index a02b050..7ce9c59 100644 --- a/modules/registrar/sip_msg.c +++ b/modules/registrar/sip_msg.c @@ -67,11 +67,16 @@ static inline int get_expire_val(void) static inline int get_expires_hf(struct sip_msg* _m) { exp_body_t* p; + int range; if (_m->expires) { p = (exp_body_t*)_m->expires->parsed; if (p->valid) { if (p->val != 0) { - return p->val + act_time; + range = cfg_get(registrar, registrar_cfg, default_expires_range); + if(likely(range==0)) + return p->val + act_time; + return p->val + act_time - (float)range/100 * p->val + + ((float)(rand()%100)/100) * ((float)range/100 * p->val); } else return 0; } else { return act_time + get_expire_val();

10 years, 9 months

[tracker] Comment added: mtree mt_summary display incorrectly, or memory leak?

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#398 - mtree mt_summary display incorrectly, or memory leak? User who did this - Josh (JoshE) ---------- The parameters are as follows: modparam("mtree", "mtree", "name=fc_did;dbtable=dids;type=0;multi=0") modparam("mtree", "mtree", "name=fc_tenant;dbtable=dids_tenants;type=0;multi=0") modparam("mtree", "fetch_rows", 2000) # count of DIDs in a single fetch modparam("mtree", "char_list", "0123456789") # characters in prefix modparam("mtree", "pv_value", "$avp(dispatch_group)") modparam("mtree", "tname_column", "name") # name search column modparam("mtree", "tprefix_column", "did") modparam("mtree", "tvalue_column", "dispatchgroup") The values are all in the same database table, technically, although to make this work, I created a view for the "second" table, which references the first database. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=398#comment1317 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.

10 years, 9 months

[tracker] Comment added: Coredump on using jsonrpc_request (Attachment added)

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#404 - Coredump on using jsonrpc_request User who did this - davy van de moere (davyvdm) ---------- sorry about that ;) added the backtraces. If you need remote access, I can set smth up for you tomorrow. Grtz, Davy ---------- 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=404#comment1316 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.

10 years, 9 months

[tracker] Comment added: Coredump on using jsonrpc_request (Attachment added)

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#404 - Coredump on using jsonrpc_request User who did this - davy van de moere (davyvdm) ---------- sorry about that ;) added the backtraces. If you need remote access, I can set smth up for you tomorrow. Grtz, Davy ---------- 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=404#comment1315 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.

10 years, 9 months

[tracker] User took ownership: Crash in asynchronous processing

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. Jason Penton has taken ownership of the following task: FS#400 - Crash in asynchronous processing More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=400 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.

10 years, 9 months

git:4.0: registar: proper unlinking deleted contact to avoid invalid memory access

by Daniel-Constantin Mierla

Module: sip-router Branch: 4.0 Commit: 977cbc8a78caa50cf822bd39c39e7838e97fa511 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=977cbc8… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: Thu Feb 27 23:47:06 2014 +0100 registar: proper unlinking deleted contact to avoid invalid memory access - based on a report and patch by Dragos Oancea --- modules/registrar/save.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/modules/registrar/save.c b/modules/registrar/save.c index 8aaf912..48c214d 100644 --- a/modules/registrar/save.c +++ b/modules/registrar/save.c @@ -695,10 +695,10 @@ static inline int update_contacts(struct sip_msg* _m, urecord_t* _r, ptr=_r->contacts; while(ptr) { - ptr0 = ptr; + ptr0 = ptr->next; if(ptr!=c) ul.delete_ucontact(_r, ptr); - ptr=ptr0->next; + ptr=ptr0; } updated=1; } @@ -725,10 +725,10 @@ static inline int update_contacts(struct sip_msg* _m, urecord_t* _r, ptr=_r->contacts; while(ptr) { - ptr0 = ptr; + ptr0 = ptr->next; if(ptr!=c) ul.delete_ucontact(_r, ptr); - ptr=ptr0->next; + ptr=ptr0; } updated=1; }

10 years, 9 months

[tracker] Comment added: Coredump on using jsonrpc_request (Attachment added)

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#404 - Coredump on using jsonrpc_request User who did this - davy van de moere (davyvdm) ---------- sorry about that ;) added the backtraces. If you need remote access, I can set smth up for you tomorrow. Grtz, Davy ---------- 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=404#comment1314 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.

10 years, 9 months

[tracker] Comment added: Coredump on using jsonrpc_request

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#404 - Coredump on using jsonrpc_request User who did this - Daniel-Constantin Mierla (miconda) ---------- I cannot use the corefile, I need only the backtrace. You can get it with: gdb /path/to/kamailio /path/to/corefile bt full Do it for both corefiles. Hopefully I can catch it from logs and backtraces, if not, then we may get to some interactive session with remote access. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=404#comment1313 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.

10 years, 9 months

[tracker] Comment added: Coredump on using jsonrpc_request (Attachment added)

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#404 - Coredump on using jsonrpc_request User who did this - davy van de moere (davyvdm) ---------- I can reproduce it with no effort ;) Enclosed corefiles, and the relevant logs (debug=3) I have it running in an openvz, if you need me to, I can setup a clone for you and give you root on it. ---------- 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=404#comment1312 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.

10 years, 9 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev February 2014