sr-dev September 2015

sr-dev@lists.kamailio.org

37 participants
387 discussions

[kamailio] kex: per module memory debugging (#225)

by Stefan Mititelu

Kex module updated to also give some details about memory used by each module. Changed f_*, q_* and tlsf_* memory stubs to also include the module name. Added 2 new memory API functions(for each of the memory algos) which will iterate throughout the memory fragments and agregate the memory size used by each function in order to print it. Tested with MEMMNG=0,1,2 and MEMDBG=0,1. Use "kamcmd mem.stat mod_name pkg/shm/all" to test Updated doku. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/225 -- Commit Summary -- * kex: per module memory debugging -- File Changes -- M events.c (25) M events.h (4) M mem/f_malloc.c (135) M mem/f_malloc.h (47) M mem/mem.h (32) M mem/q_malloc.c (113) M mem/q_malloc.h (40) M mem/shm_mem.c (4) M mem/shm_mem.h (32) M mem/src_loc.h (2) M mem/tlsf.c (105) M mem/tlsf.h (32) M modules/ctl/binrpc_run.c (12) M modules/kex/doc/kex_admin.xml (76) M modules/kex/kex_mod.c (7) A modules/kex/mod_stats.c (288) A modules/kex/mod_stats.h (37) -- Patch Links -- https://github.com/kamailio/kamailio/pull/225.patch https://github.com/kamailio/kamailio/pull/225.diff --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/225

8 years, 5 months

[kamailio] Proposed: Consolidate example kamailio.cfg files (#209)

by tuxd00d

- There are relatively few differences between the example configuration files. - The time needed to maintain three separate files doesn't match the benefit. - The power of the #!define and #!ifdef system negates the need for separate examples. - It is simple enough to remove #!ifdef sections if one wishes to slim down the file size. - I'll do a consolidation if no valid argument against it is raised. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/209

8 years, 6 months

[kamailio] nathelper sending keep alives on nodes where contact replicated using dmq_usrloc (#310)

by 00Asgaroth00

I have 3 registrars being replicated to each other using dmq_usrloc. These registrars sit behind proxy servers. I use the path header to specify the received address. When the nathelper module is enabled, the nathelper then sends keep alive options messages from all three registrars for the same contact instead of the node that processed the original registration. I am using in-memory replication (db_mode = 0), so the server_id core parameter does not seem to be taking affect for in-memory replication, i believe this is only for database mode only. I currently have server_id set differently for each registrar, to no effect. nathelper module configuration parameters are as follows: ``` modparam("nathelper", "natping_interval", 20) modparam("nathelper", "natping_processes", 4) modparam("nathelper", "ping_nated_only", 1) modparam("nathelper", "sipping_from", "sip:keepalive@domain.com") modparam("nathelper", "sipping_method", "OPTIONS") modparam("nathelper", "force_socket", NAT_PING_SOCKET) ``` NAT_PING_SOCKET is set to the local interface of each registrar where I want the message to originate from: ``` # Registrar01 #!define NAT_PING_SOCKET "10.7.0.170:5060" # Registrar02 #!define NAT_PING_SOCKET "10.7.0.171:5060" # Registrar03 #!define NAT_PING_SOCKET "10.7.0.172:5060" ``` server_id is set for each registrar ``` # Registrar01 server_id=001 # Registrar02 server_id=002 # Registrar03 server_id=003 ``` I noticed that when the force_socket is set and a registration is sent from a node that did not process the request, then an options messages is sent via the forced_socket but the originating IP is that of the primary interface of the node, in this case, the kamailio listening address on the 10.6.0.0/24 segment, and example message follows: ``` 12:42:13.320519 00:50:56:91:5e:77 > 00:50:56:91:64:fe, ethertype IPv4 (0x0800), length 455: (tos 0x60, ttl 64, id 62009, offset 0, flags [none], proto UDP (17), length 441) 10.6.0.170.sip > 10.7.0.109.sip: [udp sum ok] SIP, length: 413 OPTIONS sip:subscriber01@172.16.0.138:5060;alias=78.143.152.30~49233~1 SIP/2.0 Via: SIP/2.0/UDP 10.6.0.170:5060;branch=0 Route: <sip:10.7.0.109;lr;received=sip:78.143.152.30:49233> From: sip:keepalive@domain.com;tag=uloc-3-55e0473b-1503-af38-6cf5fbae-864c1976 To: sip:subscriber01@172.16.0.138:5060;alias=78.143.152.30~49233~1 Call-ID: 9f855711-a24ef866-112a3d5(a)10.6.0.170 CSeq: 1 OPTIONS Content-Length: 0 ``` The MAC address above confirms that the sending interface is that of force_socket for nathelper, but the source IP address is that of the primary interface of the registrar. This results in martian source messages on the target proxy server: ``` Aug 31 12:42:13 proxy01 kernel: martian source 10.7.0.109 from 10.6.0.170, on dev eth1 Aug 31 12:42:13 proxy01 kernel: ll header: 00:50:56:91:64:fe:00:50:56:91:5e:77:08:00 ``` I suspect the latter issue (martian source) will resolve itself if the registrar not processing the registration stops sending nathelper keep alive messages for contacts it did not itself process. Please let me know if you require any additional information from me to debug this issue further. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/310

8 years, 6 months

[kamailio] Module cnxcc: Error in log while parsing fake message (#324)

by Rick

``` 10(21119) DEBUG: dialog [dlg_req_within.c:384]: send_bye(): BYE sent to callee 10(21119) DEBUG: dialog [dlg_hash.c:832]: dlg_unref(): unref dlg 0x808f57580 with 1 -> 2 10(21119) DEBUG: cnxcc [cnxcc_mod.c:1005]: terminate_call(): dlg_end_dlg sent to call [] 10(21119) DEBUG: cnxcc [cnxcc_sip_msg_faker.c:45]: faked_msg_init_with_dlg_info(): fake msg: OPTIONS sip:you@kamailio.org SIP/2.0 Via: SIP/2.0/UDP 127.0.0.1 From: <>;tag= To: <>;tag= Call-ID: CSeq: 1 OPTIONS Content-Length: 0 10(21119) DEBUG: <core> [parser/msg_parser.c:606]: parse_msg(): SIP Request: 10(21119) DEBUG: <core> [parser/msg_parser.c:608]: parse_msg(): method: <OPTIONS> 10(21119) DEBUG: <core> [parser/msg_parser.c:610]: parse_msg(): uri: <sip:you@kamailio.org> 10(21119) DEBUG: <core> [parser/msg_parser.c:612]: parse_msg(): version: <SIP/2.0> 10(21119) DEBUG: <core> [parser/parse_via.c:2642]: parse_via(): end of header reached, state=2 10(21119) DEBUG: <core> [parser/msg_parser.c:496]: parse_headers(): parse_headers: Via found, flags=2 10(21119) DEBUG: <core> [parser/msg_parser.c:498]: parse_headers(): parse_headers: this is the first via 10(21119) exec: *** cfgtrace:request_route=[CNXCC] c=[/usr/local/etc/kamailio/kamailio.cfg] l=777 a=26 n=xlog 10(21119) ERROR: <core> [parser/parse_addr_spec.c:764]: parse_addr_spec(): ERROR: parse_to : unexpected char [>] in status 5: <<<>> . 10(21119) ERROR: <core> [parser/msg_parser.c:165]: get_hdr_field(): ERROR: get_hdr_field: bad to header 10(21119) DEBUG: <core> [parser/msg_parser.c:280]: get_hdr_field(): get_hdr_field: error exit 10(21119) INFO: <core> [parser/msg_parser.c:338]: parse_headers(): ERROR: bad header field [To: <>;tag= Call-ID] 10(21119) ERROR: pv [pv_core.c:635]: pv_get_callid(): cannot parse Call-Id header 10(21119) INFO: <script>: [<null>]: call killed ``` it seems that the fake message values are not filled, does I miss load an special module or is it an error because of old source code. Using version 4.31. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/324

8 years, 6 months

[kamailio] tm: fake msg and environment to append new branches (#346)

by Federico Cabiddu

This fix try to solve the crash reported in http://lists.sip-router.org/pipermail/sr-users/2015-September/089846.html. The cause of the crash was that the sip message used to append branch was the shmem clone of the original message. When the new branches were going through their configured branch route, modifications done by other modules' function (like rtpproxy) were applied to this stored copy directly, causing the crash once a failure route was run. This patch take the same approach as the failure handler one, creating a fake request from the origin message and using this one to append branches. I am not sure if this is a good approach, since the appended branch are going through the branch route and some function called there could not be compatible with a faked request. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/346 -- Commit Summary -- * tm: fake msg and environment to append new branches -- File Changes -- M modules/tm/t_append_branches.c (54) -- Patch Links -- https://github.com/kamailio/kamailio/pull/346.patch https://github.com/kamailio/kamailio/pull/346.diff --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/346

8 years, 6 months

[kamailio] Building a json/rest module (#318)

by Laurent Debacker

Any plans to build a json/rest over http module? There is such a module over rpc, but not over http. Could the http_query module be used as a basis for such a module? Potentially with https and basic authentication? --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/318

8 years, 6 months

[kamailio] kamailio 4.3 crash in update_dialog_vars_dbinfo (#301)

by MayamaTakeshi

Commit is the latest for 4.3: 48d78ce87e2f42bdc77e688a0f45ff725ea97de5 Here is the backtrace: ``` Program terminated with signal 11, Segmentation fault. #0 0x00007f3b4fd779da in update_dialog_vars_dbinfo (cell=0x7f3b3c3aa958, var=0x3433) at dlg_db_handler.c:651 651 SET_STR_VALUE(values+2, var->key); Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.5-7.el6_0.x86_64 db4-4.7.25-19.el6_6.x86_64 elfutils-libelf-0.161-3.el6.x86_64 glibc-2.12-1.166.el6_7.1.x86_64 keyutils-libs-1.4-5.el6.x86_64 krb5-libs-1.10.3-42.el6.x86_64 libacl-2.2.49-6.el6.x86_64 libattr-2.4.44-7.el6.x86_64 libcap-2.16-5.5.el6.x86_64 libcom_err-1.41.12-22.el6.x86_64 libgcc-4.4.7-16.el6.x86_64 libselinux-2.0.94-5.8.el6.x86_64 lm_sensors-libs-3.1.1-17.el6.x86_64 lua-5.1.4-4.1.el6.x86_64 mysql-libs-5.1.73-5.el6_6.x86_64 net-snmp-libs-5.5-54.el6_7.1.x86_64 nspr-4.10.8-1.el6_6.x86_64 nss-3.19.1-3.el6_6.x86_64 nss-softokn-freebl-3.14.3-22.el6_6.x86_64 nss-util-3.19.1-1.el6_6.x86_64 openssl-1.0.1e-42.el6.x86_64 pcre-7.8-7.el6.x86_64 perl-libs-5.10.1-141.el6.x86_64 popt-1.13-7.el6.x86_64 rpm-libs-4.8.0-47.el6.x86_64 tcp_wrappers-libs-7.6-57.el6.x86_64 xz-libs-4.999.9-0.5.beta.20091007git.el6.x86_64 zlib-1.2.3-29.el6.x86_64 (gdb) bt #0 0x00007f3b4fd779da in update_dialog_vars_dbinfo (cell=0x7f3b3c3aa958, var=0x3433) at dlg_db_handler.c:651 #1 0x00007f3b4fd78511 in update_dialog_dbinfo_unsafe (cell=0x7f3b3c3aa958) at dlg_db_handler.c:718 #2 0x00007f3b4fd79afc in update_dialog_dbinfo (cell=0x7f3b3c3aa958) at dlg_db_handler.c:861 #3 0x00007f3b4fdb93dc in set_dlg_variable (dlg=0x7f3b3c3aa958, key=0x7f3b508b8760, val=0x7fff7efaae60) at dlg_var.c:305 #4 0x00007f3b50696a9c in set_start_time (dialog=0x7f3b3c3aa958) at acc_cdr.c:523 #5 0x00007f3b5069c932 in cdr_on_create (dialog=0x7f3b3c3aa958, type=2, params=0x7f3b4ffda0a0) at acc_cdr.c:790 #6 0x00007f3b4fd68398 in run_create_callbacks (dlg=0x7f3b3c3aa958, msg=0x7f3b530498f0) at dlg_cb.c:230 #7 0x00007f3b4fd82590 in dlg_new_dialog (req=0x7f3b530498f0, t=0x7f3b3c7b89a8, run_initial_cbs=1) at dlg_handlers.c:865 #8 0x00007f3b4fd81006 in dlg_onreq (t=0x7f3b3c7b89a8, type=1, param=0x7f3b52df2760) at dlg_handlers.c:717 #9 0x00007f3b52b36c3a in run_reqin_callbacks_internal (hl=0x7f3b3b7eb480, trans=0x7f3b3c7b89a8, params=0x7f3b52df2760) at t_hooks.c:360 #10 0x00007f3b52b36d48 in run_reqin_callbacks (trans=0x7f3b3c7b89a8, req=0x7f3b530498f0, code=1) at t_hooks.c:385 #11 0x00007f3b52af7b58 in build_cell (p_msg=0x7f3b530498f0) at h_table.c:356 #12 0x00007f3b52b48283 in new_t (p_msg=0x7f3b530498f0) at t_lookup.c:1269 #13 0x00007f3b52b494b3 in t_newtran (p_msg=0x7f3b530498f0) at t_lookup.c:1409 #14 0x00007f3b52b1de9c in t_relay_to (p_msg=0x7f3b530498f0, proxy=0x0, proto=0, replicate=0) at t_funcs.c:236 #15 0x00007f3b52b5cbbb in _w_t_relay_to (p_msg=0x7f3b530498f0, proxy=0x0, force_proto=0) at tm.c:1476 #16 0x00007f3b52b5dd20 in w_t_relay (p_msg=0x7f3b530498f0, _foo=0x0, _bar=0x0) at tm.c:1677 #17 0x000000000041ddad in do_action (h=0x7fff7efabc80, a=0x7f3b52efc9b8, msg=0x7f3b530498f0) at action.c:1053 #18 0x000000000042a4c3 in run_actions (h=0x7fff7efabc80, a=0x7f3b52efc9b8, msg=0x7f3b530498f0) at action.c:1548 #19 0x000000000042ab28 in run_actions_safe (h=0x7fff7efac8a0, a=0x7f3b52efc9b8, msg=0x7f3b530498f0) at action.c:1613 #20 0x0000000000543c94 in rval_get_int (h=0x7fff7efac8a0, msg=0x7f3b530498f0, i=0x7fff7efac158, rv=0x7f3b52efd008, cache=0x0) at rvalue.c:912 #21 0x0000000000547ecc in rval_expr_eval_int (h=0x7fff7efac8a0, msg=0x7f3b530498f0, res=0x7fff7efac158, rve=0x7f3b52efd000) at rvalue.c:1906 #22 0x00000000005482c2 in rval_expr_eval_int (h=0x7fff7efac8a0, msg=0x7f3b530498f0, res=0x7fff7efac5e0, rve=0x7f3b52efd700) at rvalue.c:1914 #23 0x000000000041d897 in do_action (h=0x7fff7efac8a0, a=0x7f3b52efccb0, msg=0x7f3b530498f0) at action.c:1029 #24 0x000000000042a4c3 in run_actions (h=0x7fff7efac8a0, a=0x7f3b52e45308, msg=0x7f3b530498f0) at action.c:1548 #25 0x000000000042abf0 in run_top_route (a=0x7f3b52e45308, msg=0x7f3b530498f0, c=0x0) at action.c:1634 #26 0x000000000050a938 in receive_msg ( buf=0xa6fee0 "INVITE sip:09011112222@192.168.2.185:5060 SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.0.186:5010;rport;branch=z9hG4bK-13146-256700-4\r\nFrom: \"user1\" <sip:user1@test1.com>;tag=13146SIPpTag00256700\r\nTo: <sip:09011"..., len=947, rcv_info=0x7fff7efacb90) at receive.c:196 #27 0x000000000060a3ea in udp_rcv_loop () at udp_server.c:495 #28 0x00000000004a7ef7 in main_loop () at main.c:1573 #29 0x00000000004ae2d2 in main (argc=7, argv=0x7fff7efacfc8) at main.c:2533 ``` --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/301

8 years, 6 months

[kamailio] rtpengine: new read_sdp_pv parameter (#283)

by Camille Oudot

this parameter allows to specify a script var or AVP for rtpengine to get the SDP from, instead of the SIP message body. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/283 -- Commit Summary -- * rtpengine: new read_sdp_pv parameter -- File Changes -- M modules/rtpengine/doc/rtpengine_admin.xml (25) M modules/rtpengine/rtpengine.c (26) -- Patch Links -- https://github.com/kamailio/kamailio/pull/283.patch https://github.com/kamailio/kamailio/pull/283.diff --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/283

8 years, 6 months

TCP connection close event

by Olle E. Johansson

Hi! A while ago we discussed an event route when a client close a connection so we can remove registrations. Did that ever happen? /O

8 years, 6 months

Install scripts and /var/run/kamailio

by Olle E. Johansson

Just a note so I don’t forget: When doing training we installed a few computers from tarballs, and got problems running the default script - install doesn’t seem to create /var/run/kamailio which is now a default for some options. We propably need to make sure this directory is created by standard install, not just by the RPM/DEB installs. /O

8 years, 6 months

← Newer
1
2
3
4
5
6
7
...
39
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev September 2015