sr-dev November 2009

sr-dev@lists.kamailio.org

30 participants
177 discussions

git:sr_3.0: make: db_flatstore moved in the standard package
by Andrei Pelinescu-Onciul 11 Nov '09

11 Nov '09

Module: sip-router Branch: sr_3.0 Commit: efaf2651e318574289579730c93d6a73d4734de4 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=efaf265… Author: Klaus Darilion <klaus.mailinglists(a)pernau.at> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Wed Nov 11 19:47:28 2009 +0100 make: db_flatstore moved in the standard package db_flatstore was in db_modules package and ser standard package. I think it should be removed from db_modules packages as it does not have any dependencies on db-libraries. Signed-off-by: Andrei Pelinescu-Onciul <andrei(a)iptel.org> --- Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/Makefile b/Makefile index e7b83d7..b482402 100644 --- a/Makefile +++ b/Makefile @@ -156,7 +156,7 @@ module_group_standard_dep=acc_db acc_radius auth_db auth_radius avp_db \ presence_b2b rls speeddial uri_db xcap xmlrpc # For db use (db modules, excluding drivers) -module_group_db=acc_db auth_db avp_db db_ops db_flatstore db_text \ +module_group_db=acc_db auth_db avp_db db_ops db_text \ uri_db domain lcr msilo speeddial #dbtext (s) not migrated yet to the new db interface

1 0

[ openser-Bugs-2826540 ] Presence DB save fails after one failure
by SourceForge.net 10 Nov '09

10 Nov '09

Bugs item #2826540, was opened at 2009-07-24 12:22 Message generated for change (Comment added) made by nobody You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2826540&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: ver 1.5.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Hermann (axlh) Assigned to: Nobody/Anonymous (nobody) Summary: Presence DB save fails after one failure Initial Comment: After one record has failed to insert/update into the database, remaining records aren't tried. The attached patch tries to insert/update the remaining records in the hashtable after a failure. This patch surfaced bug #2824350 which led to a lot of failures due to duplicate keys. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-11-10 16:27 Message: You can commit the patch - I was waiting for you to test if svn access works ok. Daniel ---------------------------------------------------------------------- Comment By: Alex Hermann (axlh) Date: 2009-11-10 16:13 Message: just let the DB update fail in some way. I got a duplicate key error somehow. The patch makes sure the remaining entries in the hash table are committed to the DB even after one record failed. ---------------------------------------------------------------------- Comment By: sathiyapriyan m (sathiyapriyanm) Date: 2009-10-05 05:08 Message: How to Repeat or Check the Error? Kindly explain the situation. I have tried in may ways it works fine in the version 1.5.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2826540&group_…

1 0

git:kamailio_3.0: cannot compile deb and bin packages
by van Stijn, Mike 10 Nov '09

10 Nov '09

Hello, i'm trying to compile the kamailio .deb installation packages for my test enviroment and encounter multiple problems. The patches 10_no_lib64_on_64_bits and 11_always_smp can't be applied. Now I deactivaded them because the compiler system is a 32bit multicore system with debian lenny. After that make deb exits with following error make[2]: Entering directory `/usr/local/src/kamailio-3.0.0/kamailio' make[2]: *** No rule to make target `modules-docbook-man'. Stop. make[2]: Leaving directory `/usr/local/src/kamailio-3.0.0/kamailio' make[1]: *** [build-stamp] Error 2 make[1]: Leaving directory `/usr/local/src/kamailio-3.0.0/kamailio' dpkg-buildpackage: failure: debian/rules build gave error exit status 2 make: [deb] Error 2 (ignored) then I tried make bin to get the binarys and and copy them manually to the target systems but got this error: make[2]: Entering directory `/usr/local/src/kamailio-3.0.0/kamailio/utils/kamctl' make[2]: *** No rule to make target `tmp/kamailio/usr/local/etc/kamailio', needed by `install-cfg'. Stop. make[2]: Leaving directory `/usr/local/src/kamailio-3.0.0/kamailio/utils/kamctl' ERROR: make -C utils/kamctl install-if-newer failed make[1]: *** [install-utils] Error 1 make[1]: Leaving directory `/usr/local/src/kamailio-3.0.0/kamailio' make: *** [bin] Error 2 This happens with the RC1 source code package and the current git source codes. Think before you print. Gesetzliche Pflichtangaben: Schoenland Online GmbH, Sitz der Gesellschaft ist Köln, Amtsgericht Köln HRB 59449, WEEE-Reg.-Nr.: DE57403598; Geschäftsführer: Daniel Schoenland, Henning Keil; Zuständige Aufsichtsbehörde: Bundesnetzagentur für Elektrizität, Gas, Telekommunikation, Post und Eisenbahnen Tulpenfeld 4, 53113 Bonn Wie Sie wissen, können über das Internet versandte E-Mails leicht unter fremden Namen erstellt oder manipuliert werden. Aus diesem Grunde bitten wir um Verständnis dafür, dass wir zu Ihrem und unserem Schutz die rechtliche Verbindlichkeit der vorstehenden Erklärungen und Äußerungen ausschließen, soweit wir mit Ihnen keine anders lautenden Vereinbarungen getroffen haben. Die für die Schoenland Online GmbH geltenden Regelungen über die Verbindlichkeit von Willenserklärungen bleiben unberührt.

1 0

[ openser-Bugs-2797928 ] Segfaults in dialog_update_db
by SourceForge.net 10 Nov '09

10 Nov '09

Bugs item #2797928, was opened at 2009-05-28 15:54 Message generated for change (Comment added) made by axlh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2797928&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: ver 1.5.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Hermann (axlh) Assigned to: Nobody/Anonymous (nobody) Summary: Segfaults in dialog_update_db Initial Comment: dialog_update_db() is very crashy. It doesn't do any sanity checks on pointers and as a consequence crashes a lot. I've seen at least 2 occasions at which is crashes: 1) Calling dlg_manage() on a non-invite message 2) Worse, on an invalid message. When a 200 OK is missing a contact header, I get error messages from populate_leg_info(): ERROR:dialog:populate_leg_info: bad sip message or missing Contact hdr ERROR:dialog:dlg_onreply: could not add further info to the dialog But afterwards dialog_update_db segfaults on an invalid bind_addr, from the backtrace: (gdb) bt #0 0xb783c41a in dialog_update_db (ticks=771000, param=0x0) at dlg_db_handler.c:629 #1 0x080a9726 in start_timer_processes () at timer.c:282 #2 0x08069b38 in main (argc=10, argv=0xbfc6f2d4) at main.c:816 Line 629 is for my version: SET_STR_VALUE(values+8, cell->bind_addr[DLG_CALLEE_LEG]->sock_str); (gdb) bt full <snip> {type = DB_STR, nul = 0, free = -1282894544, val = {int_val = 178, ll_val = -5201380350948802382, double_val = -7.7990737395388139e-40, time_val = 178, string_val = 0xb2 "", str_val = {s = 0xb2 "", len = -1211040735}, blob_val = {s = 0xb2 "", len = -1211040735}, bitmap_val = 178}} <snip> ---------------------------------------------------------------------- >Comment By: Alex Hermann (axlh) Date: 2009-11-10 17:18 Message: I haven't had any crashes recently, so it seems fixed. I haven't, however, tried calling dlg_manage() on an INVITE anymore. ---------------------------------------------------------------------- Comment By: Daniel-Constantin Mierla (miconda) Date: 2009-06-01 12:18 Message: Can you check latest svn? I added some safety checks ... still code to review, though... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2797928&group_…

1 0

[ openser-Bugs-2822344 ] Branch route has wrong ruri or missing headers
by SourceForge.net 10 Nov '09

10 Nov '09

Bugs item #2822344, was opened at 2009-07-16 11:06 Message generated for change (Comment added) made by axlh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2822344&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: ver 1.4.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Hermann (axlh) Assigned to: Nobody/Anonymous (nobody) Summary: Branch route has wrong ruri or missing headers Initial Comment: The scenario: In branch route, I rewrite the ruri and add an additional header. When the destination fails and DNS-based failover takes place, the branch route is called again. For this second branch, the ruri is not the same as the ruri at t_relay time. Also the extra header is missing. So this bug could be either: - The ruri and rest of variables/packet for each branch should be the same as the ruri at t_relay time or - The header added in the first branch route should also be present for the second branch (in the case of DNS-based failover) I would either expect the ruri and all other variables and headers to be exactly the same as at t_relay time for each branch, or (for DNS-based failover ONLY) the packet sent to a failover destination to be exactly the same as the first branch (including any added headers / from replacement, etc.) Not a mix of both. Before t_relay: $rU = "*1234567890" t_relay("0x03"); my branch route: xlog("L_NOTICE", "Branch: <$ru> via <$du>\n"); if (is_method("INVITE") and $(rU{s.substr,0,3}) == "*12") { strip(3); append_hf("X-Test: 12\r\n"); } The log: Jul 15 09:14:38 Branch: <sip:*1234567890@test.domain;transport=udp> via <<null>> Jul 15 09:14:38 Reply Status: 503 Service Unavailable Jul 15 09:14:38 Branch: <sip:234567890@test.domain;transport=udp> via <<null>> Jul 15 09:14:38 Reply Status: 100 Trying ---------------------------------------------------------------------- >Comment By: Alex Hermann (axlh) Date: 2009-11-10 17:15 Message: It does, but the inconsistency stays. The ruri in branch_route after DNS failover is different from the ruri in the branch_route of the initial t_relay if in that branch_route, the ruri is rewritten. ---------------------------------------------------------------------- Comment By: Daniel-Constantin Mierla (miconda) Date: 2009-10-05 08:57 Message: Have you said on the mailing list that calling t_on_branch() from branch_route gets what you need? ---------------------------------------------------------------------- Comment By: Alex Hermann (axlh) Date: 2009-09-04 17:03 Message: And when there is no response at all from th destination, resulting in a local generated 408, the behaviour is even different. Then branch route isn't called at all, but the packet headed for the failover host is different from the original as it misses any headers added in the branch route. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2822344&group_…

1 0

[ openser-Bugs-2824350 ] Presence DB support completely broken
by SourceForge.net 10 Nov '09

10 Nov '09

Bugs item #2824350, was opened at 2009-07-20 17:49 Message generated for change (Settings changed) made by axlh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2824350&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: ver 1.5.x >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Alex Hermann (axlh) Assigned to: Nobody/Anonymous (nobody) Summary: Presence DB support completely broken Initial Comment: As subject. commit 5840 did the damage ---------------------------------------------------------------------- >Comment By: Alex Hermann (axlh) Date: 2009-11-10 17:14 Message: Yes, as far as I remember it is fixed. ---------------------------------------------------------------------- Comment By: Daniel-Constantin Mierla (miconda) Date: 2009-10-05 09:07 Message: IIRC, this was fixed, so item can be closed, right? ---------------------------------------------------------------------- Comment By: Alex Hermann (axlh) Date: 2009-07-24 14:43 Message: I agree that choice is better, but it requires a major rewrite. Maybe a common library can be created for all modules using DB and cache. Maybe even throw in a memcached cache as a choice. And prepared statements in case the DB is used during runtime..... Just missing my favorite mode: =4: cache only at runtime, DB save/restore at shutdown/init time. ---------------------------------------------------------------------- Comment By: Klaus Darilion (klaus_darilion) Date: 2009-07-21 15:43 Message: What about having a new parameter like userloc? db_mode= =0: no DB =1: read from cache, write/update to cache and DB =2: read from cache, write to cache and delayed write/update to DB =3: db_only, no cache ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-07-21 14:00 Message: Patch is ok, cleaner with new parameter rather than playing with falback2db value. I will apply it. Updating on timer is good for the cases of sudden crash, maybe a new mode to skip timer updates and store only at shutdown is more appropriate. ---------------------------------------------------------------------- Comment By: Alex Hermann (axlh) Date: 2009-07-21 13:11 Message: I decided to dive into the code some more. It's a bit messy. There are 2 modes of operation determined by fallback2db. Both modes don't work correctly, the documentation for the modes contradict the code it contradicts ITSELF. So the first thing to do to fix this is to get the desired behavior for both modes documented. >From the code I deduced the following behavior: fallback mode: init: load from database, keep data in tables runtime: insert/update records in table on timer event shutdown: flush cache to db non-fallback mode: init: load from database, empty table runtime: no inserts but try to update table (won't work because table is emptied) shutdown: flush cache to db (fails, because all entries are marked NO_UPDATEDB_FLAG du to the (failed) updates at runtime). Result is an empty table after shutdown. The documentation says in fallback mode the cache isn't used. This is impossible in the current code. Later in the docs it is said only on cache misses, the db is used. This seems reasonable behavior. The main question is: should the db be updated during runtime or only on shutdown when in non-fallback mode? Attached patch creates the following behavior: for both modes: init: load from database, keep table contents runtime: update/insert into table on timer event shutdown: update/insert final time The only difference in the modes is on lookup (as documentation says) and is untouched by this patch. The non-fallback mode should be optimized by not updating the table if the answer to the above question says so, but that is not as trivial as this patch. ps. I found some nice descriptive function names: update_db_subs() and update_subs_db().... ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-07-20 19:52 Message: fallback to db is in presence and the insert function is used by rls module as well. I had no time to check the impact now. With this idea, to be safe, fallback2db param has to be directed to another variable, fallback2db initialized to 0 and set to param value in each child, via child_init. Otherwise can be a conflict of loading order. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-07-20 18:37 Message: I don't know if changing the API and ABI is appropriate for the stable series. What about setting the fallback2db variable only AFTER loading the DB contents? ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-07-20 18:22 Message: The function is used in presence and rls modules. Does not look like big changes to add a new param to specify the mode. Do you think of something else? ---------------------------------------------------------------------- Comment By: Alex Hermann (axlh) Date: 2009-07-20 18:07 Message: New subscriptions don't get stored in the DB because the test for 'fallback2db' was wrong. I just noticed the insert_shtable() function is also used to load from DB initially, so my patch is wrong. Fix is a bit more non-trivial. The problem is that the function is used for both DB-load at startup and new subscriptions during runtime. The db_flag in the hash table record needs to be INSERTDB_FLAG during runtime, and NO_UPDATEDB_FLAG for initial load. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-07-20 17:53 Message: Please provide a bit more details of what got broken. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2824350&group_…

1 0

[ openser-Bugs-2826540 ] Presence DB save fails after one failure
by SourceForge.net 10 Nov '09

10 Nov '09

Bugs item #2826540, was opened at 2009-07-24 14:22 Message generated for change (Comment added) made by axlh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2826540&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: ver 1.5.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Alex Hermann (axlh) Assigned to: Nobody/Anonymous (nobody) Summary: Presence DB save fails after one failure Initial Comment: After one record has failed to insert/update into the database, remaining records aren't tried. The attached patch tries to insert/update the remaining records in the hashtable after a failure. This patch surfaced bug #2824350 which led to a lot of failures due to duplicate keys. ---------------------------------------------------------------------- >Comment By: Alex Hermann (axlh) Date: 2009-11-10 17:13 Message: just let the DB update fail in some way. I got a duplicate key error somehow. The patch makes sure the remaining entries in the hash table are committed to the DB even after one record failed. ---------------------------------------------------------------------- Comment By: sathiyapriyan m (sathiyapriyanm) Date: 2009-10-05 07:08 Message: How to Repeat or Check the Error? Kindly explain the situation. I have tried in may ways it works fine in the version 1.5.2. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=743020&aid=2826540&group_…

1 0

alias_contact()/handle_alias() ready for testing
by jh＠tutpro.com 10 Nov '09

10 Nov '09

i now have alias_contact()/handle_alias() ready for testing. a new modules_k/nathelper/nathelper.c for sr_3.0 that includes those functions is available for limited time as: http://box.tutpro.com/tmp/nathelper.c /* * Adds ;alias=ip:port param to cotact uri containing received ip:port * if contact uri ip:port does not match received ip:port. */ static int alias_contact_f(struct sip_msg* msg, char* str1, char* str2) /* * Checks if r-uri has alias param and if so, removes it and sets $du * based on its value. */ static int handle_alias_f(struct sip_msg* msg, char* str1, char* str2) usage instructions: - call alias_contact() for all other incoming requests except register and for all incoming replies, for example: route [OTHER_REQUESTS] { # handle other than REGISTER requests if (!alias_contact()) { xlog("L_ERR", "Error in aliasing contact <$ct>\n"); send_reply("400", "Bad request"); exit; }; ... onreply_route [REPLY] { # handle all replies if (!alias_contact()) { xlog("L_ERR", "Error in aliasing contact <$ct>\n"); send_reply("400", "Bad reply"); exit; }; ... - call handle_alias() for all in-dialog requests before t_relaying them, for example: route [IN_DIALOG_REQUESTS] { # handle all in-dialog requests ... handle_alias(); switch ($rc) { case -1: xlog("L_ERR", "Failed to handle alias of R-URI <$ru>\n"); send_reply("400", "Bad request"); exit; case 1: xlog("L_INFO", "Routing in-dialog $rm from <$fu> to <$du>\n"); break; case 2: xlog("L_INFO", "Routing in-dialog $rm from <$fu> to <$ru>\n"); break; } if (!t_relay()) { ... - do NOT call fix_nated_contact() on anything. - call fix_nated_register() on register requests, if registering ua is behind nat OR is using tcp, for example: if (isflagset(FROM_NATED) || (proto == TCP)) { fix_nated_register(); if (isflagset(FROM_NATED)) { setbflag("TO_NATED"); }; }; save("location"); that is it. my config got much simper than what is was before. i'm on the road and have been able to test this only using twinkle and sems. so more testing with different UAs is very welcome. i consider these two functions a bug fix and would like to include them into sr3.0. but fix, because using current means, some in-dialog requests will have wrong contact uri, i.e., not the one the ua advertised. -- juha

3 29

how to assign value to a pvar?
by jh＠tutpro.com 10 Nov '09

10 Nov '09

it was easy to write the code that counts the number of record routes in a message. first i though that i can return the count as result of the script function, but that didn't work out because if script function returns 0, it will terminate execution of the script. so i though to give the function a pvar argument to which the count is stored, e.g., rr_count("$var(count)"); so far i have not been able to assign the count to the pvar argument and have already spent three hours on such a simple assignment statement. in pvar.h there is function int pv_set_spec_value(struct sip_msg* msg, pv_spec_p sp, int op, pv_value_t *value); that sounds like it might do the trick, but there is no documentation on op argument and i have not yet found in sr sources any place there that function is really used. also i have not found in any of sr modules any script function that would assign something to a pvar argument? is there one so that i could take a look or it that an impossible thing to do? i have tried various versions, such as pv_val.ri = count; pv_val.flags = PV_VAL_INT; if (_count) { if (pv_set_spec_value(msg, (pv_spec_t *)_count, EQ_T, &pv_val) == 0) { where _count is pvar fixed up argument of rr_count function, but no luck so far. i just get Nov 10 05:42:51 localhost /usr/sbin/sip-proxy[27707]: ERROR: pv [pv_svar.c:117]: out of pkg mem! Nov 10 05:42:51 localhost /usr/sbin/sip-proxy[27707]: ERROR: pv [pv_core.c:1620]: error - cannot set svar [tmp] can anyone help here? if not, i'll have to make rr_count to return the actual count + 1 so that i can return it as result of the rr_count function. -- juha

2 3

question on sip_msg struct hdr_field* h_via2
by jh＠tutpro.com 09 Nov '09

09 Nov '09

daniel, andrei, or any parser expert, i see that in typedef struct sip_msg there is these: struct via_body* via1; /* The first via */ struct via_body* via2; /* The second via */ why two? if i call parse_headers(msg, HDR_EOH_F, 0) and via2 is not set, does it mean that message had only one via? -- juha

2 1

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev November 2009