sr-users July 2016

sr-users@lists.kamailio.org

82 participants
125 discussions

by Infinicalls Infinicalls

Hi, I am trying to implement a prepaid system and get this error " ERROR: <core> [modparam.c:150]: set_mod_param_regex(): No module matching <call_control> found " while adding modparam("call_control", "disable", 1). I have already included pv and dialog in the modules list. Any idea? regards Ganesh Kumar

8 years, 4 months

t_check_trans() exits route execution if transaction is found

by Sebastian Damm

Hi, on one of our systems we are checking a few times whether a transaction already exists. We noticed that route execution stops if the transaction is found. And after looking into the code, we found that it seems to be intended like this. >From tm.c: int t_check_trans(struct sip_msg* msg) { if (msg->first_line.type==SIP_REPLY) { [..] } else { switch(t_check_msg(msg, 0)){ [..] case 1: /* found */ [..] return 0; /* exit from the script */ } } } Can anybody explain, why script execution should stop when a running transaction is found? I would expect that then the function returns 1 so I can use it in my if statement and continue with my routing script. Thanks already for an explanation, Sebastian

8 years, 4 months

Kamailio compact headers ?!

by Anonim Stefan

Hi, Is there a parameter to be enabled such that Kamailio will append headers in compacted form? (I'm thinking of Via: and Record-Route:) Thanks, Stefan

8 years, 4 months

Kamailio and Mongodb

by C.

Hi, I am still trying to get Kamailio to work with MongoDB. Followed instructions here https://www.kamailio.org/wiki/tutorials/kamailio-and-mongodb <https://www.kamailio.org/wiki/tutorials/kamailio-and-mongodb>, but I cannot get things to install. Are there any instructions on the exact configuration changes that need to be made to support Mongodb? For example, kamctl points to MySQL, etc Thanks! Chuks.

8 years, 4 months

Locally originated BYE dialog database handle

by Dirk Teurlings - Signet B.V.

Hi, There's something going on with a locally originated BYE and the dialog module running with a database backend. Here's the scenario. Call gets setup, and is being monitored by outside processes (non-Kamailio). After a while these processes determine the call is taking too long (or too expensive), so it has to be killed. To do this we're using the kamcmd dlg.end_dlg with h_entry and h_id as parameter. This works to end the call, but is throws some weird issues into the routing. First off, the event_route[dialog:end] is not thrown 99% of the time, though I would expect it to. Second, This error pops up in the log /usr/sbin/kamailio[25094]: ERROR: dialog [dlg_db_handler.c:199]: use_dialog_table(): invalid database handle As if the command issued by kamcmd isn't able to get connected to the dialog database. In any case, this error results in the dialog entry for this call not being removed from the database. So this piles up after a while. Anybody any thoughts on this? Cheers, Dirk

8 years, 4 months

(no subject)

by John Petrini

Hello, I'm trying to append a branch, assign it a q value so it has priority and serialize the new branch and the main branch. The goal is to send the new branch off to our CNAM provider, capture the CNAM in their reply to an $avp then drop the branch, stick the cnam in the main branch and allow the call to continue as normal. We do this currently using OpenSIPS with serialize_branches(1) but the of load_contacts() behavior seems to be different than serialize_branches. route[CNAM_DIPS] t_on_branch("CNAM_DIPS"); t_on_reply("CNAM_DIPS"); t_on_failure("CNAM_DIPS"); t_load_contacts(); t_next_contacts(); append_branch("sip:2223334444@22.33.444.55:5600;trans-type=5", "0.5"); relay(); break; Two problems. First when t_next_contacts is called I get the following error: ERROR: pv [pv_branch.c:58]: pv_get_branchx(): error accessing branch [0] So it looks like the branches aren't actually being loaded? Second problem is that despite the first error my call goes out on the branch I appended and I get a reply from the CNAM provider but Kamailio forwards that reply back to the phone causing the phone to send a second invite. In OpenSIPs we just called drop, to drop the branch and let the main branch continue but this doesn't seem to work in Kamailio. I've read and reread the documentaion but it doesn't seem to behave the way the documentation says it should. Is there something I'm missing? Is there a better way to accomplish this in Kamailio? Thank You, ___ John Petrini

8 years, 4 months

Issue with userblacklist module after 4.4.2 upgrade

by Tim Balmer

Hello, We are running Kamailio version 4.4 and have our sipproxy servers configured to do auto updates within te same major version based on a 4 weekly schedule (we have 4 sipproxy / Kamailio servers). So this morning as expected the first of our sipproxy servers automatically upgraded from 4.4.1 to 4.4.2, unfortunately after this update we have issues with the userblacklist module. The problem is that with the 4.4.2 release every number is now matching our userblacklists although it is not really blacklisted. After some digging in the logs I found this is probably because the userblacklist module is looking for the wrong database table. With every check_user_blacklist call I see errors like this appearing in the logs: Jul 5 13:24:03 tel-dev-01 [err] /usr/sbin/kamailio[2834]: ERROR: db_mysql [km_dbase.c:128]: db_mysql_submit_query(): driver error on query: Table 'kamailio.<number>' doesn't exist (1146) Jul 5 13:24:03 tel-dev-01 [err] /usr/sbin/kamailio[2834]: ERROR: <core> [db_query.c:132]: db_do_query_internal(): error while submitting query Jul 5 13:24:03 tel-dev-01 [err] /usr/sbin/kamailio[2834]: ERROR: userblacklist [db.c:68]: db_build_userbl_tree(): error while executing query. Jul 5 13:24:03 tel-dev-01 [err] /usr/sbin/kamailio[2834]: ERROR: userblacklist [userblacklist.c:277]: check_user_list(): cannot build d-tree I replaced the real number with <number> in the log output but it seems like the userblacklist module is now looking for a database table with the name of the number to check against. On our development server I tested setting the global userblacklist_table parameter and also passing the table parameter within the check_user_blacklist call but both are not making any difference. After downgrading the sipproxy back to 4.4.1 everything is working as expected again so it looks to me like a bug in the 4.4.2 release. Is anyone else experiencing the same issues after the 4.4.2 upgrade or is it just me doing something wrong? Best Regards, Tim Balmer

8 years, 4 months

Kamailio summer-of-documentation - join the effort

by Olle E. Johansson

Hi! Looking for a summer-of-documentation project? Which README is the best? Which one is so full of Swedish that you totally fail to parse it? Check our documentation pages, suggest improvements on the mailing lists (or here on Facebook) and give us feedback! This is something you can spend your lazy summer days on - a nice cool drink, cool sunshades and Kamailio documentation! We constantly work to update our README files for every module and the cookbooks for the Kamailio core, the transformations and pseudovariables. But we’re developers, not casual administrators and propably fail to see some obvious things missing. Please tell us (feel free to use the mailing lists). And if you can - but not required at all - you can suggest rewrites in the XML source and upload to github. Let’s keep our docs up to date and make sure they really assist our users! http://kamailio.org/docs/modules/devel/ Have a great summer! Regards, /O

8 years, 4 months

Re: [SR-Users] [SR-USERS] Kamailio issues with Asterisk Voicemail

by tegamjg

El 05/07/2016 11:36, Daniel Tryba <d.tryba(a)pocos.nl> escribió: > > Please keep the mailinglist in the loop, so everybody might benefit from > our ramblings :) > > > Still there are few things i dont understand, i am not using asterisk > > just as a voicemail server since they are actually handling also the > > calls passing first from kamailio and being load balanced to those > > asterisk boxes. May i still use call forwarding as you are using it? > > (Both asterisk have a shared storage with a clustered filesystem, so > > both will be able to see voice messages) > > Yes I think so. I use a seperate machine for voicemail but I see no > problem with other uses (I used to use it for playback of messages and > transcoding ebtween incompatible endpoints). > > By using the prefixes in kamailio to the username in $ru I have in the > extensions.conf: > > exten => _tovm-.,1,NoOp(leave voicemail) > exten => _tovm-.,n,Answer() > exten => _tovm-.,n,Set(CHANNEL(language)=nl) > exten => _tovm-.,n,Voicemail(${EXTEN:5},us) > exten => _tovm-.,n,Playback(Goodbye) > exten => _tovm-.,n,Hangup() > > exten => _getvm-.,1,NoOp(read voicemail) > exten => _getvm-.,n,Set(CHANNEL(language)=nl) > exten => _getvm-.,n,VoicemailMain(${EXTEN:6}) > exten => _getvm-.,n,Hangup() > > > The other question is that i actually though that you need asterisk to > > have users configured in sipusers realtime table to associate their > > mailboxes, which i dont have since those users are stored in the > > subscriber table of kamailio. So am i still able to configure > > voicemail like you are doing it by syncing with the voicemail table?, > > i really hope so haha > > I forgot that fact. So yes I have a realtime sip users list (with > host=dynamic,type=friend,insecure=port,invite, name/mailbox the kamailio > username, no password (this machine is not directly accessible from > outside)) Sorry, I think i rushed the last answer but if you could answer that one would be nice How are you handling the calls? Just with kamailio/rtpproxy? Because i am also using asterisk for calls with dial application and for nat issues (with kamailio behind nat) i am using also kamailio/rtpproxy for outside. All this with just handling users (registration and location) in the subscribe and location table of kamailio. That is why i am not using sipusers table of asterisk because of nat was behaving weird using it that way. Could it be possible to use both tables without expecting a different behaviour? Or is not, in the end, a good idea and i need to keep users in sipusers table? > > You might not be able to have endpoints able to subscribe to > notifications due to this. I baked something inspired by: > http://saevolgo.blogspot.nl/2012/07/asterisk-behind-kamailio-voicemail-mwi.… > that appears to work for me. > > _______________________________________________ > SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list > sr-users(a)lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

8 years, 4 months

Kamailio out-of-mem

by José Seabra

I'm running burning tests against kamailio and after some time ~ 2 days I see kamailio out of mem: ERROR: tm [t_lookup.c:1271]: new_t(): ERROR: new_t: out of mem: ERROR: tm [t_lookup.c:1411]: t_newtran(): ERROR: t_newtran: new_t failed The result of command kamcmd mod.stats all is: Module: core { sip_msg_shm_clone(494): 10653392 build_req_buf_from_sip_req(2149): 2565480 msg_lump_cloner(978): 2943584 create_avp(175): 969736 xavp_new_value(94): 858469320 counters_prefork_init(207): 16896 cfg_clone_str(130): 88 cfg_shmize(217): 744 init_pt(110): 8 init_pt(105): 8 init_pt(104): 3080 dtrie_insert(157): 240 dtrie_insert(148): 48 dtrie_init(60): 160 dtrie_init(51): 32 register_timer(1011): 360 cfg_register_ctx(47): 32 init_tcp(4635): 8192 init_tcp(4629): 32768 init_tcp(4621): 8 init_tcp(4614): 8 init_tcp(4607): 8 init_tcp(4601): 8 init_tcp(4589): 8 init_avps(90): 8 init_avps(89): 8 init_dst_blacklist(437): 16384 init_dst_blacklist(430): 8 timer_alloc(514): 96 init_dns_cache(366): 8 init_dns_cache(358): 16384 init_dns_cache(351): 16 init_dns_cache(345): 8 init_timer(283): 8 init_timer(282): 16384 init_timer(281): 8 init_timer(280): 8 init_timer(269): 8 init_timer(237): 8 init_timer(220): 278544 init_timer(219): 8 init_timer(206): 8 cfg_child_cb_new(830): 64 sr_cfg_init(361): 8 sr_cfg_init(354): 8 sr_cfg_init(347): 8 sr_cfg_init(335): 8 sr_cfg_init(323): 8 shm_core_lock_init(153): 8 Total: 875992224 } Module: dmq { alloc_job_queue(229): 128 shm_str_dup(723): 24 build_dmq_node(156): 448 add_peer(67): 168 mod_init(243): 8 mod_init(237): 96 init_dmq_node_list(66): 24 init_peer_list(33): 24 Total: 920 } Module: auth_db { Total: 0 } Module: dialog { init_dlg_table(284): 131088 init_dlg_table(276): 8 init_dlg_table(269): 8 init_dlg_table(264): 8 init_dlg_timer(57): 8 init_dlg_timer(48): 32 new_dlg_profile(187): 624 Total: 131776 } Module: rr { Total: 0 } Module: xlog { Total: 0 } Module: kex { pkg_proc_stats_init(79): 1056 Total: 1056 } Module: db_postgres { lock_set_alloc(70): 80 Total: 80 } Module: pv { Total: 0 } Module: textops { Total: 0 } Module: htable { ht_cell_new(183): 1104 ht_init_tables(381): 8388608 ht_add_table(278): 928 Total: 8390640 } Module: sqlops { Total: 0 } Module: tm { build_uac_req(1543): 848 prepare_new_uac(479): 28880 _reply_light(542): 751504 build_local_reparse(341): 1168568 relay_reply(1884): 643088 build_cell(317): 9826624 prepare_new_uac(524): 8112 prepare_new_uac(509): 10192 init_tm_stats_child(60): 5632 insert_tmcb(137): 136 init_tmcb_lists(74): 16 init_tmcb_lists(72): 16 init_hash_table(467): 2097152 Total: 14540768 } Module: usrloc { new_urecord(65): 136 new_ucontact(98): 1096 new_urecord(58): 288 shm_str_dup(723): 1200 build_stat_name(51): 64 new_udomain(93): 40960 new_udomain(86): 48 new_dlist(573): 16 new_dlist(565): 32 register_ulcb(94): 32 init_ulcb_list(45): 16 lock_set_alloc(70): 4112 Total: 48000 } Module: tmx { tmx_check_pretran(250): 864 tmx_check_pretran(271): 1216 tmx_init_pretran_table(90): 256 Total: 2336 } Module: sl { init_sl_stats_child(125): 4224 sl_startup(83): 8 init_sl_stats(110): 8 Total: 4240 } Module: carrierroute { rule_fixup_recursor(584): 8 shm_str_dup(723): 56 add_route_rule(74): 152 add_route_flags(225): 48 create_domain_data(83): 32 create_carrier_data(59): 8 create_carrier_data(50): 64 load_route_data_db(295): 8 load_domain_map(182): 48 load_domain_map(171): 24 load_carrier_map(126): 48 load_carrier_map(115): 24 reload_route_data(172): 64 init_route_data(74): 8 Total: 592 } Module: dispatcher { reindex_dests(600): 1008 add_dest2list(350): 168 add_dest2list(324): 4200 init_data(204): 16 init_data(195): 16 mod_init(309): 8 mod_init(307): 8 ds_ping_active_init(102): 8 Total: 5432 } Module: db_text { dbt_init_cache(81): 256 dbt_init_cache(69): 8 dbt_init_cache(54): 8 Total: 272 } The result of command kamctl shmem is: shmem:fragments = 6353 shmem:free_size = 406208 shmem:max_used_size = 8464105472 shmem:real_used_size = 8463699264 shmem:total_size = 8464105472 shmem:used_size = 5190698208 The server has 8G of shared memory allocated, and the issue happens more or less after 2 days running tests. I'm using sipp to generate traffic, it is sending 500CAPS. There is any possibility of memory leak on Kamailio 4.4.0? Best Regards -- José Seabra

8 years, 4 months

← Newer
1
...
7
8
9
10
11
12
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users July 2016