sr-dev

sr-dev@lists.kamailio.org

44307 discussions

by Andrei Pelinescu-Onciul

Module: sip-router Branch: master Commit: a14aaf3f2fe11cdc0d56e1a12cb60ae0cd53b8f5 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=a14aaf3… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Sun Mar 14 17:13:40 2010 +0100 perl(k): fix mk_action call The mk_action() call used the old openser format, instead of the sip_router one. --- modules_k/perl/openserxs.xs | 17 ++++++----------- 1 files changed, 6 insertions(+), 11 deletions(-) diff --git a/modules_k/perl/openserxs.xs b/modules_k/perl/openserxs.xs index 418f1e3..4ee86b6 100644 --- a/modules_k/perl/openserxs.xs +++ b/modules_k/perl/openserxs.xs @@ -220,7 +220,6 @@ int moduleFunc(struct sip_msg *m, char *func, unsigned mod_ver; char *argv[2]; int argc = 0; - action_u_t elems[MAX_ACTIONS]; struct run_act_ctx ra_ctx; if (!func) { @@ -260,16 +259,12 @@ int moduleFunc(struct sip_msg *m, char *func, return -1; } - elems[0].type = MODULE_T; - elems[0].u.data = exp_func_struct; - elems[1].type = STRING_ST; - elems[1].u.data = argv[0]; - elems[2].type = STRING_ST; - elems[2].u.data = argv[1]; - act = mk_action( MODULE_T, - 3, - elems, - 0); + act = mk_action(MODULE_T, 4 /* number of (type, value) pairs */, + MODEXP_ST, exp_func_struct, /* function */ + NUMBER_ST, 2, /* parameter number */ + STRING_ST, argv[0], /* param. 1 */ + STRING_ST, argv[1] /* param. 2 */ + ); if (!act) {

14 years, 10 months

Re: [sr-dev] [Kamailio-Users] kamailio crashes

by Daniel-Constantin Mierla

Hello, what version do you have? If it is for 3.0, please register a bug at: http://sip-router.org/tracker/ In 3.0 the crash is at: 186 case HDR_REFER_TO_T: 187 free_to(hf->parsed); 188 break; I am out of the office without my linux box these days to be able to check more. Maybe some other devel can look a bit at it. Thanks, Daniel On Wed, Mar 10, 2010 at 9:17 AM, Panagiotis Skoulikaritis <pskoul(a)algonet.gr > wrote: > Dear fellow kaimailio users > > We have a kamailio server which crashes. > below is the backtrace from the core files > any idea why the kamailio is crashing > > Regards > > Panagiotis > > core.29568 Mar 10 09:27 > > #0 fm_status (qm=0x73a040) at mem/f_malloc.c:609 > #1 0x0000000000423d5c in sig_usr (signo=15) at main.c:563 > #2 <signal handler called> > #3 0x00000037e3cd4711 in __recvfrom_nocancel () from /lib64/libc.so.6 > #4 0x00000000004790cc in udp_rcv_loop () at udp_server.c:408 > #5 0x000000000042760e in main (argc=3, argv=0x7fff8bf6abc8) at main.c:774 > > > > > > core.19350 Mar 10 09:05 > > (gdb) backtrace > #0 free_to (tb=0x775c00) at parser/parse_to.c:79 > #1 0x000000000047fd42 in clean_hdr_field (hf=0x2ad2432de100) at > parser/hf.c:187 > #2 0x00002ad23fe3e525 in run_trans_callbacks (type=<value optimized out>, > trans=<value optimized out>, req=0x2ad2432dcf58, > rpl=0x772d28, code=<value optimized out>) at sip_msg.h:54 > #3 0x00002ad23fe47b46 in t_reply_matching (p_msg=0x772d28, p_branch=<value > optimized out>) at t_lookup.c:888 > #4 0x00002ad23fe47fa2 in t_check (p_msg=0x772d28, > param_branch=0x7ffff9c016bc) at t_lookup.c:964 > #5 0x00002ad23fe58ac2 in reply_received (p_msg=0x73a040) at t_reply.c:1395 > #6 0x000000000041eebc in forward_reply (msg=0x772d28) at forward.c:521 > #7 0x0000000000445313 in receive_msg ( > buf=0x718dc0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP > 77.247.97.11;branch=z9hG4bK45f7.70f91294.0;received=77.247.97.11\r\nV", > len=920, rcv_info=0x7ffff9c017a0) at receive.c:212 > #8 0x00000000004794ae in udp_rcv_loop () at udp_server.c:449 > #9 0x000000000042760e in main (argc=3, argv=0x7ffff9c019b8) at main.c:774 > (gdb) > > > > > core.29567 Mar 10 09:27 > > gdb) backtrace > #0 free_to (tb=0x776460) at parser/parse_to.c:79 > #1 0x000000000047fd42 in clean_hdr_field (hf=0x2ad1805fa100) at > parser/hf.c:187 > #2 0x00002ad17d15a525 in run_trans_callbacks (type=<value optimized out>, > trans=<value optimized out>, req=0x2ad1805f8f58, > rpl=0x771920, code=<value optimized out>) at sip_msg.h:54 > #3 0x00002ad17d163b46 in t_reply_matching (p_msg=0x771920, p_branch=<value > optimized out>) at t_lookup.c:888 > #4 0x00002ad17d163fa2 in t_check (p_msg=0x771920, > param_branch=0x7fff8bf6a8cc) at t_lookup.c:964 > #5 0x00002ad17d174ac2 in reply_received (p_msg=0x73a040) at t_reply.c:1395 > #6 0x000000000041eebc in forward_reply (msg=0x771920) at forward.c:521 > #7 0x0000000000445313 in receive_msg ( > buf=0x718dc0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP > 77.247.97.11;branch=z9hG4bKddc9.fa58f7e.0;received=77.247.97.11\r\nVia: > SIP/2.0/UDP 213.170.194.47:5060;branch=z9hG4bKb973f6a69c9bea270e9db867dd7cc90f\r\nRecord-Route: > <si"..., len=919, rcv_info=0x7fff8bf6a9b0) > at receive.c:212 > #8 0x00000000004794ae in udp_rcv_loop () at udp_server.c:449 > #9 0x000000000042760e in main (argc=3, argv=0x7fff8bf6abc8) at main.c:774 > (gdb) > > > core.5326 Mar 10 09:02 > > (gdb) backtrace > #0 free_to (tb=0x772c48) at parser/parse_to.c:79 > #1 0x000000000047fd42 in clean_hdr_field (hf=0x2b2578e22560) at > parser/hf.c:187 > #2 0x00002b257597b525 in run_trans_callbacks (type=<value optimized out>, > trans=<value optimized out>, req=0x2b2578e213b8, > rpl=0x771b50, code=<value optimized out>) at sip_msg.h:54 > #3 0x00002b2575984b46 in t_reply_matching (p_msg=0x771b50, p_branch=<value > optimized out>) at t_lookup.c:888 > #4 0x00002b2575984fa2 in t_check (p_msg=0x771b50, > param_branch=0x7fff7cdc63ac) at t_lookup.c:964 > #5 0x00002b2575995ac2 in reply_received (p_msg=0x772c48) at t_reply.c:1395 > #6 0x000000000041eebc in forward_reply (msg=0x771b50) at forward.c:521 > #7 0x0000000000445313 in receive_msg ( > buf=0x718dc0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP > 77.247.97.11;branch=z9hG4bKec2f.dc3d97a7.0;received=77.247.97.11\r\nVia: > SIP/2.0/UDP 213.170.194.47:5060;branch=z9hG4bK47703457194f5be415efc231f6b3e923\r\nRecord-Route: > <s"..., len=918, rcv_info=0x7fff7cdc6490) > at receive.c:212 > #8 0x00000000004794ae in udp_rcv_loop () at udp_server.c:449 > #9 0x000000000042760e in main (argc=5, argv=0x7fff7cdc66a8) at main.c:774 > (gdb) quit > > _______________________________________________ > Kamailio (OpenSER) - Users mailing list > Users(a)lists.kamailio.org > http://lists.kamailio.org/cgi-bin/mailman/listinfo/users > http://lists.openser-project.org/cgi-bin/mailman/listinfo/users > -- Daniel-Constantin Mierla http://www.asipto.com

14 years, 10 months

[tracker] Comment added: kamailio registrar module / usrloc should be able to recover from temporary data loss

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#41 - kamailio registrar module / usrloc should be able to recover from temporary data loss User who did this - Ronald Voermans (voermans) ---------- Other thing: with the current database setup: the username isn't part of the primary key any more. So an insert always works, and there is never going to be an update. Just tried it, and the table is full of duplicates! If that patch makes it into Kamailio, the database structure for the location-table needs to be adjusted! ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=41#comment37 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.

14 years, 10 months

[tracker] Comment added: kamailio registrar module / usrloc should be able to recover from temporary data loss

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#41 - kamailio registrar module / usrloc should be able to recover from temporary data loss User who did this - Ronald Voermans (voermans) ---------- When restarting Kamailio, I thought it retreived the registrations from the location-table. Correct? If so, all should be consistent. But for some reason, it is/was not. Is the memory location preserved when restarting Kamailio? To be honest: i don't really know what the expected behaviour should be. When using db_mode("1"), what exactly is the use of the location-table? I do expect the memory location to be available when the database is not. On the other hand: when an update isn't possible, I do think it the location-entry should be inserted (or, as you state it the other way around: first INSERT, if that fails, UPDATE). ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=41#comment36 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.

14 years, 10 months

loading of registrar fails (master)

by jh＠tutpro.com

i build sip-router from master branch and when i try to start it, loading of registrar module fails like this: 0(9437) ERROR: <core> [sr_module.c:396]: ERROR: load_module: could not open module </usr/lib/sip-proxy/modules_k/registrar.so>: /usr/lib/sip-proxy/modules_k/registrar.so: undefined symbol: default_expires_stat i this a bug or am i missing something that was not needed in version 3.0? -- juha

14 years, 10 months

git:master: malloc_test: realloc testing support

by Andrei Pelinescu-Onciul

Module: sip-router Branch: master Commit: c05afff1bc452d55536c2277f39c52c17cb29ff0 URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=c05afff… Author: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Committer: Andrei Pelinescu-Onciul <andrei(a)iptel.org> Date: Fri Mar 12 19:38:42 2010 +0100 malloc_test: realloc testing support Support for stress testing realloc: - new config variable realloc_p for enabling realloc() usage instead of malloc() for mem tests and mem_rnd_alloc. Its value is the percent of realloc()s from the total calls to alloc functions (0-90%). - new RPC: mt.mem_realloc size [unit] for manually triggering a realloc. --- modules/malloc_test/malloc_test.c | 172 +++++++++++++++++++++++++++++++++---- 1 files changed, 155 insertions(+), 17 deletions(-) Diff: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commitdiff;h=c05…

14 years, 10 months

[tracker] Task changed: kamailio registrar module / usrloc should be able to recover from temporary data loss

by sip-router

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#41 - kamailio registrar module / usrloc should be able to recover from temporary data loss User who did this: Henning Westerholt (henningw) Task Type: Feature Request -> Bug Report More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=41 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.

14 years, 10 months

[tracker] Comment added: kamailio registrar module / usrloc should be able to recover from temporary data loss

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#41 - kamailio registrar module / usrloc should be able to recover from temporary data loss User who did this - Henning Westerholt (henningw) ---------- Hm.. the inconsistency you reported in the internal memory cache is of course more a bug then a missing feature. Perhaps you can add more details about your expected behaviour in this case, should kamailio discard or reject the memory location as well if the database is not available? ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=41#comment35 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.

14 years, 10 months

[tracker] Task changed: kamailio registrar module / usrloc should be able to recover from temporary data loss

by sip-router

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#41 - kamailio registrar module / usrloc should be able to recover from temporary data loss User who did this: Henning Westerholt (henningw) Summary: Database and cache inconsistency with registrar module / usrloc -> kamailio registrar module / usrloc should be able to recover from temporary data loss Task Type: Bug Report -> Feature Request More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=41 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.

14 years, 10 months

[tracker] Comment added: kamailio registrar module / usrloc should be able to recover from temporary data loss

by sip-router

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY. The following task has a new comment added: FS#41 - kamailio registrar module / usrloc should be able to recover from temporary data loss User who did this - Henning Westerholt (henningw) ---------- I've changed this issue to a feature request, as according your informations the data loss was caused from some issues in your setup, and not from the behaviour of the module. ---------- More information can be found at the following URL: http://sip-router.org/tracker/index.php?do=details&task_id=41#comment34 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.

14 years, 10 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev