sr-dev March 2025

sr-dev@lists.kamailio.org

10 participants
184 discussions

[kamailio/kamailio] cdp: restructure locking order to prevent rare deadlock (PR #4191)
by Morten Tryfoss 06 May '25

06 May '25

#### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [x] Each component has a single commit (if not, squash them into one commit) - [x] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [x] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description We've been running the ims_charging module in production for quite some time, without any issues. A couple of days ago the whole instance freezed, but I was able to get a dump before the stuck processes before restarting. The traffic volume has gradually increased over time, so it's likely related to that. I then did a summary of the different types of stuck processes. Which locks they're holding, and what they're waiting for: ``` holding lock: AAASessionsLock waiting for lock: lock_get(peer_list_lock); #1 0x00007fe70eba8cde in futex_get (lock=0x7fe6e4a5c680) at ../../core/futexlock.h:108 #2 0x00007fe70ebaaca2 in get_peer_by_fqdn (fqdn=0x7fe6e4a5ba30) at peermanager.c:259 #3 0x00007fe70ebb64b7 in get_first_connected_route (cdp_session=0x7fe6e5cc5350, r=0x7fe6e4a5ba30, app_id=4, vendor_id=10415) at routing.c:115 #4 0x00007fe70ebb9a37 in get_routing_peer (cdp_session=0x7fe6e5cc5350, m=0x7fe6e5447ab0) at routing.c:293 #5 0x00007fe70ebcaf8c in AAASendMessage (message=0x7fe6e5447ab0, callback_f=0x7fe707a9e323 <resume_on_initial_ccr>, callback_param=0x7fe6e5297110) at diameter_comm.c:139 #6 0x00007fe707a9d3e0 in Ro_Send_CCR (msg=0x7fe70f011100, dlg=0x7fe6e5c571f0, dir=0, reservation_units=30, incoming_trunk_id=0x7ffe50efb060, outgoing_trunk_id=0x7ffe50efb050, pani=0x7ffe50efaee0, action=0x7fe70efa4730, tindex=10484, tlabel=677172593) at ims_ro.c:1511 #7 0x00007fe707a8285d in ki_ro_ccr (msg=0x7fe70f011100, s_route_name=0x7ffe50efb080, s_direction=0x7ffe50efb070, reservation_units=30, s_incoming_trunk_id=0x7ffe50efb060, s_outgoing_trunk_id=0x7ffe50efb050) at ims_charging_mod.c:742 #8 0x00007fe707a7bf01 in w_ro_ccr (msg=0x7fe70f011100, c_route_name=0x7fe70ef8b8d0 "\220\311\371\016\347\177", c_direction=0x7fe70ef8b980 "p\240\371\016\347\177", reservation_units=30, c_incoming_trunk_id=0x7fe70ef8ba30 "p\241\371\016\347\177", c_outgoing_trunk_id=0x7fe70ef8bae0 "\360\241\371\016\347\177") at ims_charging_mod.c:507 #9 0x00000000004858d8 in do_action (h=0x7ffe50efb970, a=0x7fe70ef99e20, msg=0x7fe70f011100) at core/action.c:1144 #10 0x00000000004928d6 in run_actions (h=0x7ffe50efb970, a=0x7fe70ef99e20, msg=0x7fe70f011100) at core/action.c:1618 #11 0x0000000000492f52 in run_actions_safe (h=0x7ffe50eff1e0, a=0x7fe70ef99e20, msg=0x7fe70f011100) at core/action.c:1681 #12 0x0000000000450156 in rval_get_long (h=0x7ffe50eff1e0, msg=0x7fe70f011100, i=0x7ffe50efbec8, rv=0x7fe70ef9c1d8, cache=0x0) at core/rvalue.c:973 #13 0x0000000000454d24 in rval_expr_eval_long (h=0x7ffe50eff1e0, msg=0x7fe70f011100, res=0x7ffe50efbec8, rve=0x7fe70ef9c1d0) at core/rvalue.c:1854 #14 0x0000000000454d52 in rval_expr_eval_long (h=0x7ffe50eff1e0, msg=0x7fe70f011100, res=0x7ffe50efc448, rve=0x7fe70ef9b920) at core/rvalue.c:1864 #15 0x00000000004850ce in do_action (h=0x7ffe50eff1e0, a=0x7fe70ef9b070, msg=0x7fe70f011100) at core/action.c:1097 -- holding lock: AAASessionsLock waiting for lock: lock_get(peer_list_lock); #1 0x00007fe70eba8d4f in futex_get (lock=0x7fe6e4a5c680) at ../../core/futexlock.h:121 #2 0x00007fe70ebaaca2 in get_peer_by_fqdn (fqdn=0x7ffe50efab90) at peermanager.c:259 #3 0x00007fe70ebb8e89 in get_routing_peer (cdp_session=0x7fe6e5ab6910, m=0x7fe6e5435be0) at routing.c:252 #4 0x00007fe70ebcaf8c in AAASendMessage (message=0x7fe6e5435be0, callback_f=0x7fe707a95edc <resume_on_termination_ccr>, callback_param=0x0) at diameter_comm.c:139 #5 0x00007fe707a95b02 in send_ccr_stop_with_param (ro_session=0x7fe6e5ab65e0, code=0, reason=0x7ffe50efb060) at ims_ro.c:1181 #6 0x00007fe707a72ff7 in dlg_terminated (dlg=0x7fe6e623d7a0, type=64, termcode=0, reason=0x7fe707ab72b3 "normal call clearing", _params=0x7fe707f67280 <params>) at dialog.c:249 #7 0x00007fe707a6a729 in dlg_callback_received (dlg=0x7fe6e623d7a0, type=64, _params=0x7fe707f67280 <params>) at dialog.c:25 #8 0x00007fe707d341b9 in run_dlg_callbacks (type=64, dlg=0x7fe6e623d7a0, req=0x7fe70f011100, rpl=0x0, dir=1, dlg_data=0x0) at dlg_cb.c:271 #9 0x00007fe707cf4db4 in dlg_terminated (req=0x7fe70f011100, dlg=0x7fe6e623d7a0, dir=1) at dlg_handlers.c:413 #10 0x00007fe707cfddeb in dlg_onroute (req=0x7fe70f011100, route_params=0x7ffe50efb6d0, param=0x0) at dlg_handlers.c:1097 #11 0x00007fe70ad285f6 in run_rr_callbacks (req=0x7fe70f011100, rr_param=0x7ffe50efb7c0) at rr_cb.c:96 #12 0x00007fe70ad3ae92 in after_loose (_m=0x7fe70f011100, preloaded=0) at loose.c:1021 #13 0x00007fe70ad3b5ce in loose_route_mode (_m=0x7fe70f011100, _mode=0) at loose.c:1056 #14 0x00007fe70ad3f74f in w_loose_route (msg=0x7fe70f011100, p1=0x0, p2=0x0) at rr_mod.c:273 #15 0x00000000004855ff in do_action (h=0x7ffe50efc390, a=0x7fe70efe0d40, msg=0x7fe70f011100) at core/action.c:1121 -- holding lock: lock_get(peer_list_lock); waiting for lock: lock_get(p->lock); #1 0x00007fe70eba8d4f in futex_get (lock=0x7fe6e4a5cbd0) at ../../core/futexlock.h:121 #2 0x00007fe70ebab0ae in peer_timer (now=1742807320, ptr=0x0) at peermanager.c:286 #3 0x00007fe70ebd0f39 in timer_loop () at timer.c:116 #4 0x00007fe70ebd21b2 in timer_process (returns=0) at timer.c:216 #5 0x00007fe70eb8ccf8 in diameter_peer_start (blocking=0) at diameter_peer.c:350 #6 0x00007fe70eb7cbb2 in cdp_child_init (rank=0) at cdp_mod.c:272 -- holding lock: lock_get(p->lock) waiting for lock: AAASessionsLock #1 0x00007fe70ebf2597 in futex_get (lock=0x7fe6e4a5d490) at ../../core/futexlock.h:108 #2 0x00007fe70ebf26f1 in AAASessionsLock (hash=0) at session.c:79 #3 0x00007fe70ebf5e6e in cdp_get_session (id=...) at session.c:316 #4 0x00007fe70eba6892 in Snd_Message (p=0x7fe6e4a5c880, msg=0x7fe6e63998d0) at peerstatemachine.c:1237 #5 0x00007fe70eba003e in sm_process (p=0x7fe6e4a5c880, event=Send_Message, msg=0x7fe6e63998d0, peer_locked=0, sock=0) at peerstatemachine.c:429 #6 0x00007fe70ebcbdc6 in AAASendMessage (message=0x7fe6e63998d0, callback_f=0x7fe707a8f208 <resume_on_interim_ccr>, callback_param=0x7fe6e6190a90) at diameter_comm.c:166 #7 0x00007fe707a8edb3 in send_ccr_interim (ro_session=0x7fe6e5399160, used=60, reserve=30) at ims_ro.c:847 #8 0x00007fe707a68bd6 in ro_session_ontimeout (tl=0x7fe6e5399200) at ro_timer.c:513 #9 0x00007fe707a63078 in ro_timer_routine (ticks=114862426, attr=0x0) at ro_timer.c:279 #10 0x00000000004fd33e in compat_old_handler (ti=1837798827, tl=0x7fe6e4cf6260, data=0x7fe6e4cf6260) at core/timer.c:980 #11 0x00000000004fde7a in slow_timer_main () at core/timer.c:1103 #12 0x000000000042e4e7 in main_loop () at main.c:1911 #13 0x000000000043876c in main (argc=10, argv=0x7ffe50f001c8) at main.c:3236 ``` In `get_first_connected_route()` in `routing.c` of the cdp module there are two places `get_peer_by_fqdn()` are called. One of them has an unlock/relock of the session list before and after (and a comment about holding two locks at a time), while the other doesn't. I'm currently testing two version of this. The first by just doing the some relock for the other `get_peer_by_fqdn()`, but this PR got an approach for maybe fixing more latent issues. `sm_process()` also got some strange handling by `Rcv_Process()` after the peer lock is released, which seems to be about the same thing. My deadlock is for the `Snd_Message()` equivalent. I've now removed this queueing behaviour, and instead doing a re-lock of the peer to (hopefully) have the same locking order as the other operations. The problem with this thing is how rare it occurs. Just wanted to share my findings for others with more knowledge to the cdp module for comments, suggestions and hopefully some extra testing. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4191 -- Commit Summary -- * cdp: restructure locking order to prevent rare deadlock -- File Changes -- M src/modules/cdp/peerstatemachine.c (25) M src/modules/cdp/routing.c (6) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4191.patch https://github.com/kamailio/kamailio/pull/4191.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4191 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4191(a)github.com>

4 13

[kamailio/kamailio] Topoh module does not hide 180 Ringing and 200 Ok to the caller UE in IMS config (Issue #4164)
by Farzaneh Soltanzadeh 05 May '25

05 May '25

Fr-Soltanzadeh created an issue (kamailio/kamailio#4164) ### Description In a IMS lab using Kamailio PCSCF, ICSCF and SCSCF default configs, I have used TOPOH module in PCSCF for topology hiding. Topoh config is as follows: ``` modparam("topoh", "mask_key", "my-key") modparam("topoh", "mask_ip", "127.0.0.2") modparam("topoh", "sanity_checks", 1) ``` As shown in attached traffic, SCSCF IP is not hided in 180 ringing and 200ok messages to the caller. In invite, ack and bye messages hiding is performed well. [topoh.zip](https://github.com/user-attachments/files/19086420/topoh.zip) [topoh.zip](https://github.com/user-attachments/files/19086428/topoh.zip) [topoh.zip](https://github.com/user-attachments/files/19086431/topoh.zip)  ### Troubleshooting #### Reproduction  #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` (paste your log messages here) ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` (paste your output here) ``` * **Operating System**:  ``` (paste your output here) ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4164 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4164(a)github.com>

3 4

[kamailio/kamailio] secfilter‌: support remove rule in Whitelist and Blacklist (PR #4089)
by AsedMorteza 30 Apr '25

30 Apr '25

6 11

[kamailio/kamailio] Allow single quotes in From name (Issue #3984)
by ThomasSevestre 28 Apr '25

28 Apr '25

### Description `secf_check_sqli_all();` block requests when a single quote is present in From name : ``` From: "O'Reilly" <sip:100@example.net>;tag=abcd ``` Since single quotes are frequent in names. It makes it difficult to use this function. ### Possible Solutions A solution would be to skip single quote check in From name. I'll write the PR if you are OK with this solution -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3984 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3984(a)github.com>

5 10

[kamailio/kamailio] Update PCSCF IMS example config (PR #4177)
by Tobias Funke 25 Apr '25

25 Apr '25

3 3

[kamailio/kamailio] Why can't set_body_multipart and append_body_part* functions be used from ONREPLY_ROUTE? (Issue #4149)
by rodrigodc 22 Apr '25

22 Apr '25

rodrigodc created an issue (kamailio/kamailio#4149) Hello, Is there a strong reason why the following functions from [textops](https://www.kamailio.org/docs/modules/5.4.x/modules/textops.html) can't be used from `ONREPLY_ROUTE`? - [set_body_multipart](https://www.kamailio.org/docs/modules/5.4.x/modules/tex… - [append_body_part_hex](https://www.kamailio.org/docs/modules/5.4.x/modules/t… I need to add ISUP to outgoing `SIP/18x` replies which already have an SDP body and would like to use those functions for that. However, they cannot be used from `ONREPLY_ROUTE`, just as they can from `REQUEST_ROUTE` (which I use to add ISUP to `SIP/INVITE`). So I am considering sending a pull request allowing them to be used from `ONREPLY_ROUTE`, but first I would like to know if it makes sense. Thank you. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4149 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4149(a)github.com>

4 4

[kamailio/kamailio] xmpp module causes crash in component mode with prosody (Issue #4154)
by Jan Rozhon 22 Apr '25

22 Apr '25

jrozhon created an issue (kamailio/kamailio#4154)  ### Description I have Kamailio configured to act as a gateway between SIP and XMPP in my lab setup. I only have module configured, no routing is implemented yet. When handshake with XMPP server (Prosody) occurs, Kamailio crashes. ### Troubleshooting I cannot use newer version of kamailio as it crashes because of presence module. Older versions up to 5.5.7 behave the same. If i get backtrace right crash is caused by a problem with parsing the incoming xml, but it seems fine to me. #### Reproduction Have prosody xmpp server configured to accept component connection from kamailio. In kamailio have xmpp.so module loaded with following parameters set: modparam("xmpp", "backend", "component") modparam("xmpp", "gateway_domain", "kamailio-dns") modparam("xmpp", "xmpp_domain", "xmpp-dns") modparam("xmpp", "xmpp_host", "xmpp-dns") modparam("xmpp", "xmpp_port", 5347) modparam("xmpp", "xmpp_password", "shared-password") #### Debugging Data ``` (gdb) bt full #0 _xode_put_expatattribs (owner=0x13c5480, atts=0x13be6d0) at xstream.c:35 i = 10 #1 0x00007f77df410211 in _xode_stream_startElement (xs=0x13c07f0, name=0x13c0170 "stream:stream", atts=0x13be6d0) at xstream.c:56 p = 0x13be110 #2 0x00007f77df3c2934 in doContent () from /lib64/libexpat.so.1 No symbol table info available. #3 0x00007f77df3c0fde in doProlog () from /lib64/libexpat.so.1 No symbol table info available. #4 0x00007f77df3c1eac in prologProcessor () from /lib64/libexpat.so.1 No symbol table info available. #5 0x00007f77df3b958f in callProcessor () from /lib64/libexpat.so.1 No symbol table info available. #6 0x00007f77df3c60a7 in XML_ParseBuffer () from /lib64/libexpat.so.1 No symbol table info available. #7 0x00007f77df410594 in xode_stream_eat (xs=0x13c07f0, buff=0x7f77df4185e0 <buf> "<?xml version='1.0'?><stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:component:accept' id='09b989ba-0ba4-4b58-ad8e-53b07fe2f13a' from='sip.xmpp.osk3.lab' xml:lang='en'>", len=197) at xstream.c:176 err = 0x4000000 <error: Cannot access memory at address 0x4000000> xerr = 0x7f77e4d06ed0 <syslog> maxerr = "maximum node size reached" deeperr = "maximum node depth reached" #8 0x00007f77df404955 in xmpp_component_child_process (data_pipe=9) at xmpp_component.c:237 buf = 0x7f77df4185e0 <buf> "<?xml version='1.0'?><stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:component:accept' id='09b989ba-0ba4-4b58-ad8e-53b07fe2f13a' from='sip.xmpp.osk3.lab' xml:lang='en'>" fd = 5 maxfd = 9 rv = 1 fdset = {__fds_bits = {32, 0 <repeats 15 times>}} pool = 0x13bae50 stream = 0x13c07f0 priv = {fd = 5, running = 1} cmd = 0xa09250 <main_state+16> __func__ = "xmpp_component_child_process" #9 0x00007f77df3fafef in xmpp_process (rank=1) at xmpp.c:280 __func__ = "xmpp_process" #10 0x00007f77df3fac4b in child_init (rank=0) at xmpp.c:263 pid = 0 #11 0x0000000000650a0c in init_mod_child (m=0x7f77e44b8f90, rank=0) at core/sr_module.c:911 ret = 0 __func__ = "init_mod_child" #12 0x0000000000650656 in init_mod_child (m=0x7f77e44b93e0, rank=0) at core/sr_module.c:903 ret = 0 __func__ = "init_mod_child" #13 0x0000000000650656 in init_mod_child (m=0x7f77e44b9b78, rank=0) at core/sr_module.c:903 ret = 0 __func__ = "init_mod_child" #14 0x0000000000650656 in init_mod_child (m=0x7f77e44ba000, rank=0) at core/sr_module.c:903 ret = 0 __func__ = "init_mod_child" #15 0x0000000000650656 in init_mod_child (m=0x7f77e44bafa0, rank=0) at core/sr_module.c:903 ret = 32 __func__ = "init_mod_child" #16 0x0000000000650656 in init_mod_child (m=0x7f77e44bb498, rank=0) at core/sr_module.c:903 ret = 0 __func__ = "init_mod_child" #17 0x0000000000650656 in init_mod_child (m=0x7f77e44bbe58, rank=0) at core/sr_module.c:903 ret = 0 __func__ = "init_mod_child" #18 0x0000000000650656 in init_mod_child (m=0x7f77e44bc370, rank=0) at core/sr_module.c:903 ret = 1 __func__ = "init_mod_child" #19 0x0000000000651207 in init_child (rank=0) at core/sr_module.c:990 ret = -464031792 type = 0x884ffb "PROC_MAIN" __func__ = "init_child" #20 0x000000000042fb48 in main_loop () at main.c:1929 i = 8 pid = 450007 si = 0x0 si_desc = "udp receiver child=7 sock=kamailio.osk3.lab:5060\000K\207\362\377\177\000\000\000\000\000\000\000\000\000\000PQ\207\362\377\177\000\000\263\266\204\000\000\000\000\0000\277K\344w\177\000\000\320n\320\344w\177\000\000\000\000\000\004\000\000\000\000jo\320\344w\177\000\0000\000\000\0000\000\000\000\bM\207\362\377\177\000" nrprocs = 8 woneinit = 1 __func__ = "main_loop" #21 0x0000000000439d03 in main (argc=11, argv=0x7ffff2875268) at main.c:3213 cfg_stream = 0x130b380 c = -1 r = 0 tmp = 0x7ffff2876ea2 "" tmp_len = 0 port = 0 proto = 0 ahost = 0x0 aport = 0 options = 0x8373a8 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 863415900 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 2 n_lst = 0x40 p = 0x1000000 <error: Cannot access memory at address 0x1000000> st = {st_dev = 23, st_ino = 1015, st_nlink = 2, st_mode = 16832, st_uid = 977, st_gid = 976, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1739449861, tv_nsec = 919999685}, st_mtim = {tv_sec = 1740224132, tv_nsec = 607723775}, st_ctim = {tv_sec = 1740224132, tv_nsec = 607723775}, __glibc_reserved = {0, 0, 0}} tbuf = "9M\t\345w\177\000\000\210\n\006\345w\177\000\000\340N\207\362\377\177\000\000\006\000\000\000\000\000\000\000\b\367\005\345w\177\000\000\006\000\000\000\020\000\000\0000Z\t\345w\177\000\000\325\331\006\345w\177\000\000\000\000\000\000\000\000\000\000\240\354\006\345w\177\000\000\370\377\300\344w\177\000\000\000:\005\345w\177\000\000\000\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\260N\207\362\377\177\000\000\240\n\006\345w\177\000\000\240\n\006\345w\177\000\000\000\000\000\000\000\000\000\000`H\005\345w\177\000\000\260N\207\362\377\177\000\000\200e\t\345w\177\000\000\000\360\005\345w\177\000\000\342\373\005\345w\177\000\000v\244\006\345w\177\000\000\334#\300\344w\177\000\000"... option_index = 12 long_options = {{name = 0x839a46 "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x8344f4 "version", has_arg = 0, flag = 0x0, val = 118}, { name = 0x839a4b "alias", has_arg = 1, flag = 0x0, val = 1024}, {name = 0x839a51 "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x839a57 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x839a60 "substdefs", has_arg = 1, flag = 0x0, val = 1027}, {name = 0x839a6a "server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x839a74 "loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x839a7f "modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x839a88 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x839a93 "debug", has_arg = 1, flag = 0x0, val = 1032}, { name = 0x839a99 "cfg-print", has_arg = 0, flag = 0x0, val = 1033}, {name = 0x839aa3 "atexit", has_arg = 1, flag = 0x0, val = 1034}, { name = 0x839aaa "all-errors", has_arg = 0, flag = 0x0, val = 1035}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} __func__ = "main" ``` ``` (gdb) info locals i = 10 ``` ``` (gdb) list 30 static void _xode_put_expatattribs(xode owner, const char **atts) 31 { 32 int i = 0; 33 if(atts == NULL) 34 return; 35 while(*(atts[i]) != '\0') { 36 xode_put_attrib(owner, atts[i], atts[i + 1]); 37 i += 2; 38 } 39 } ``` #### Log Messages  ``` Feb 22 11:39:10 kamailio /usr/sbin/kamailio[445061]: INFO: tls [tls_domain.c:418]: ksr_tls_fill_missing(): TLSc<default>: verify_client=0 Feb 22 11:39:10 kamailio /usr/sbin/kamailio[445061]: INFO: tls [tls_domain.c:781]: set_verification(): TLSc<default>: Server MAY present invalid certificate Feb 22 11:39:10 kamailio /usr/sbin/kamailio[445109]: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 28 Feb 22 11:39:10 kamailio /usr/sbin/kamailio[445066]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 3 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445107]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 15 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445065]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 2 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445088]: INFO: ctl [io_listener.c:214]: io_listen_loop(): using epoll_lt io watch method (config) Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445070]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 4 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445064]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 1 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445074]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 7 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445076]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 8 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445096]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 9 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445085]: INFO: jsonrpcs [jsonrpcs_sock.c:471]: jsonrpc_dgram_process(): a new child 0/445085 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445072]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 6 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445108]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 16 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445061]: ALERT: <core> [main.c:792]: handle_sigs(): child process 445090 exited by a signal 11 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445061]: ALERT: <core> [main.c:796]: handle_sigs(): core was generated Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445061]: INFO: <core> [main.c:819]: handle_sigs(): terminating due to SIGCHLD Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445071]: INFO: tls [tls_mod.c:576]: mod_child(): OpenSSL loaded private keys in child: 5 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445066]: INFO: <core> [main.c:875]: sig_usr(): signal 15 received Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445065]: INFO: <core> [main.c:875]: sig_usr(): signal 15 received Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445076]: INFO: <core> [main.c:875]: sig_usr(): signal 15 received Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445064]: INFO: <core> [main.c:875]: sig_usr(): signal 15 received Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445083]: INFO: <core> [main.c:875]: sig_usr(): signal 15 received Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445089]: INFO: <core> [main.c:875]: sig_usr(): signal 15 received Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445081]: INFO: <core> [main.c:875]: sig_usr(): signal 15 received Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445109]: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 25 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445109]: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 17 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445109]: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 15 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445109]: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 8 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445088]: INFO: <core> [main.c:875]: sig_usr(): signal 15 received Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445109]: CRITICAL: <core> [core/pass_fd.c:281]: receive_fd(): EOF on 26 Feb 22 11:39:11 kamailio /usr/sbin/kamailio[445077]: INFO: <core> [main.c:875]: sig_usr(): signal 15 received ``` #### SIP Traffic  ``` no sip traffic, just simple xml exchanged ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.7.5 (x86_64/linux) 58499a flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, MEM_JOIN_FREE, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 58499a compiled on 00:00:00 Sep 13 2022 with gcc 11.4.1 ``` * **Operating System**:  ``` RHEL 9 Linux kamailio 5.14.0-503.15.1.el9_5.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Nov 14 15:45:31 EST 2024 x86_64 x86_64 x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4154 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4154(a)github.com>

3 4

[kamailio/kamailio] Error when sending NOTIFYs in the presence of disconnected websocket watchers (Issue #4118)
by Flavio Grossi 20 Apr '25

20 Apr '25

### Description if multiple sip websocket clients are subscribed to some UA and one of the watchers suddenly disappears (e.g. the web page is reloaded), then no NOTIFY is ever sent after issuing a `pres_refresh_watchers()`. The following error is logged: ``` WARNING: <core> [core/msg_translator.c:3007]: via_builder(): TCP/TLS connection (id: 0) for WebSocket could not be found ERROR: tm [t_msgbuilder.c:1423]: assemble_via(): via building failed ERROR: tm [t_msgbuilder.c:1614]: build_uac_req(): error while assembling Via ERROR: tm [uac.c:552]: t_uac_prepare(): Error while building message ERROR: presence [notify.c:1734]: send_notify_request(): in function tm t_request_within() ERROR: presence [notify.c:1829]: notify(): sending Notify not successful ERROR: presence [notify.c:1585]: query_db_notify(): Could not send notify for [event]=dialog ERROR: presence [presence.c:739]: pres_refresh_watchers(): sending Notify requests ``` ### Troubleshooting when the client disconnects, the old watcher is not removed from the active_watchers table, instead it coexists with the new one, but the stale connection causes the error above when sending the notify, and then all of the following watchers (even the valid ones) are skipped too. Looking at the logs, the valid watchers are not notified because the while loop [here](https://github.com/kamailio/kamailio/blob/b96bc11a54f11ec688429c057bf… is skipped because of the `goto done` line in case of errors, which happens because it fails to build the via header for the message relevant to the stale websocket connection. By breaking out of the while loop, the remaining subs in the `subs_array` are skipped. #### Reproduction Just subscribe to a sip client using a websocket-based phone, then abruptly disconnect it (e.g. by reloading the web page) and then issue a `pres_refresh_watchers()` to make it generate a notify. #### Debugging Data #### Log Messages #### SIP Traffic ### Possible Solutions I tried to use the "websocket:closed" route to purge stale connections, but to my knowledge there are no APIs to clean invalid watchers. A possible solution could be to automatically remove the watchers on disconnection and maybe skip the invalid ones without exiting from the refresh loop ### Additional Information kamailio 5.8.2 * **Operating System**: Rocky Linux 9 -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4118 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4118(a)github.com>

4 5

[kamailio/kamailio] fr_timer documentation mistake (Issue #3939)
by Dmitry Sinina 20 Apr '25

20 Apr '25

Documentation https://www.kamailio.org/docs/modules/devel/modules/tm.html#tm.p.fr_timer says: >Timer which hits if no **final reply** for a request or ACK for a negative INVITE reply arrives (in milliseconds). Looks like it is not correct description - fr_timer value works until 1xx(not **final**) response received and then timer restarted with fr_inv_timer value there: https://github.com/kamailio/kamailio/blob/master/src/modules/tm/t_reply.c#L… Looks like old doc from sip router https://sip-router.org/wiki/ref_manual/timers explains it correctly: > fr_timer This timer is used for all SIP requests. It hits if no reply for an INVITE request or other request has been received (F in milliseconds). If a provisional reply is received for an INVITE (any 1xx), then the fr_inv_timer will be used instead. And if no replies (at all) for an INVITE are received before `fr_timer` hits, the transaction is terminated with a 408 in failure route. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3939 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3939(a)github.com>

3 10

[kamailio/kamailio] path: add_path_received() appends transport=ws instead of transport=wss (Issue #4168)
by Christian Berger 19 Apr '25

19 Apr '25

ChristianBergerSipgate created an issue (kamailio/kamailio#4168) We think we have found a potential bug in the path module. When we call `add_path_received()` we get the following for WSS connections: `Path: <sip:217.10.77.242;lr;received=sip:217.10.69.93:42612%3Btransport%3Dws>` We think there should be a `transport%3Dwss` appended instead of ws. We have looked a bit into the code and think that this is caused by the following definition: ``` in modules/path/path.c const static char *proto_strings[] = { [PROTO_TCP] = "%3Btransport%3Dtcp", [PROTO_TLS] = "%3Btransport%3Dtls", [PROTO_SCTP] = "%3Btransport%3Dsctp", [PROTO_WS] = "%3Btransport%3Dws", [PROTO_WSS] = "%3Btransport%3Dws", }; ``` We think that on the last line, it should read ` [PROTO_WSS] = "%3Btransport%3Dwss",` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4168 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4168(a)github.com>

5 5

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev March 2025