sr-dev March 2024

sr-dev@lists.kamailio.org

14 participants
238 discussions

[kamailio/kamailio] support zero media stream for sdp parsing module (Issue #3779)

by Dakna adnane

when using sdp module to parse sdp I noticed that function called from sdp_get return -1 when no m-lines are present in sdp , normally we should accept sdp without m -line because it can be at a later time through a modified offer , how can we accept such sdp without changing source code for function "parse_sdp_session" -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3779 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3779(a)github.com>

3 months, 1 week

[kamailio/kamailio] User-params parsing fails in multiple ways (Issue #3762)

by Alex Hermann

### Description The uri parser seems to fail in multiple ways on username-parameters. The ways it fails depends on the presence of user-params in the incoming request and on adjustments to $ru, $rd and $rU in the script. My expectation is that the whole username, including user-params is *always* visible in $rU. In reality, the user-params are absent or present depending on manipulations to the uri in the script. When setting $rU to a value with a user-param, that user-param is represented when reading $ru, but not in $rU.  ### Troubleshooting #### Reproduction I used below config script to test various scenario's. ``` debug=2 memlog=4 #fork=no # This option should not be present to enable forking but disable daemonize, also -D commandline parameter is needed log_stderror=yes log_name="kamailio-test" log_facility=LOG_LOCAL5 sip_warning=no children=2 shm_mem_size=128 check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) dns_use_search_list=no use_dns_failover=yes dns_srv_lb=yes disable_tcp=yes auto_aliases=no listen=172.16.1.19:7060 loadmodule "sl.so" loadmodule "pv.so" loadmodule "xlog.so" modparam("xlog", "prefix", "") route { xnotice("Incoming $rm to $rU\n"); xinfo("$$ru = $ru\n"); switch ($rU) { case "100": xnotice("Set $$rU = \"1234;first=yes\"\n"); $rU = "1234;first=yes"; xinfo("$$ru: $ru\n"); xinfo("$$rU: $rU\n"); if ($rU != "1234;first=yes") { xerr("Fail!\n"); } else { xinfo("Success!\n"); } break; case "200": xnotice("Set $$rd = \"example.com;transport=udp\"\n"); $rd = "example.com;transport=udp"; xinfo("$$ru: $ru\n"); xinfo("$$rU: $rU\n"); xnotice("Set $$rU = \"1234;first=yes\"\n"); $rU = "1234;first=yes"; xinfo("$$ru: $ru\n"); xinfo("$$rU: $rU\n"); if ($rU != "1234;first=yes") { xerr("Fail!\n"); } else { xinfo("Success!\n"); } break; case "300": xnotice("Set $$ru = \"sip:1234@example.com;transport=udp\"\n"); $ru = "sip:1234@example.com;transport=udp"; xinfo("$$ru: $ru\n"); xinfo("$$rU: $rU\n"); xnotice("Set $$rU = \"1234;first=yes\"\n"); $rU = "1234;first=yes"; xinfo("$$ru: $ru\n"); xinfo("$$rU: $rU\n"); if ($rU != "1234;first=yes") { xerr("Fail!\n"); } else { xinfo("Success!\n"); } break; case "400": xnotice("Set $$ru = \"sip:1234;first=yes@example.com;transport=udp\"\n"); $ru = "sip:1234;first=yes@example.com;transport=udp"; xinfo("$$ru: $ru\n"); xinfo("$$rU: $rU\n"); if ($rU != "1234;first=yes") { xerr("Fail!\n"); } else { xinfo("Success!\n"); } xnotice("Set $$rU = \"1234;second=yes\"\n"); $rU = "1234;second=yes"; xinfo("$$ru: $ru\n"); xinfo("$$rU: $rU\n"); if ($rU != "1234;second=yes") { xerr("Fail!\n"); } else { xinfo("Success!\n"); } break; } sl_send_reply(500, "Done"); exit; } ``` Outputs: --- ``` 1(2206122) NOTICE: Incoming INVITE to 100 1(2206122) INFO: $ru = sip:100@172.16.1.19:7060;user=phone 1(2206122) NOTICE: Set $rU = "1234;first=yes" 1(2206122) INFO: $ru: sip:1234;first=yes@172.16.1.19:7060;user=phone 1(2206122) INFO: $rU: 1234 1(2206122) ERROR: Fail! ``` Setting $rU with a user-param sets it correctly in $ru, but reading $rU back fails. --- ``` 1(2206122) NOTICE: Incoming INVITE to 200 1(2206122) INFO: $ru = sip:200@172.16.1.19:7060;user=phone 1(2206122) NOTICE: Set $rd = "example.com;transport=udp" 1(2206122) INFO: $ru: sip:200@example.com;transport=udp:7060;user=phone 1(2206122) INFO: $rU: 200 1(2206122) NOTICE: Set $rU = "1234;first=yes" 1(2206122) INFO: $ru: sip:1234;first=yes@example.com;transport=udp:7060;user=phone 1(2206122) INFO: $rU: 1234 1(2206122) ERROR: Fail! ``` Same when setting $rd in advance. --- ``` 1(2206122) NOTICE: Incoming INVITE to 300 1(2206122) INFO: $ru = sip:300@172.16.1.19:7060;user=phone 1(2206122) NOTICE: Set $ru = "sip:1234@example.com;transport=udp" 1(2206122) INFO: $ru: sip:1234@example.com;transport=udp 1(2206122) INFO: $rU: 1234 1(2206122) NOTICE: Set $rU = "1234;first=yes" 1(2206122) INFO: $ru: sip:1234;first=yes@example.com;transport=udp 1(2206122) INFO: $rU: 1234;first=yes 1(2206122) INFO: Success! ``` When setting $ru first with no user-param lets a later asssignment to $rU with user-param succeed. --- ``` 1(2206122) NOTICE: Incoming INVITE to 400 1(2206122) INFO: $ru = sip:400@172.16.1.19:7060;user=phone 1(2206122) NOTICE: Set $ru = "sip:1234;first=yes@example.com;transport=udp" 1(2206122) INFO: $ru: sip:1234;first=yes@example.com;transport=udp 1(2206122) INFO: $rU: 1234;first=yes 1(2206122) INFO: Success! 1(2206122) NOTICE: Set $rU = "1234;second=yes" 1(2206122) INFO: $ru: sip:1234;second=yes@example.com;transport=udp 1(2206122) INFO: $rU: 1234;second=yes 1(2206122) INFO: Success! ``` Setting $ru with a user-params succeeds. Subsequently overwriting the user part with $rU with a user-param also succeeds. --- ``` 1(2206122) NOTICE: Incoming INVITE to 400 1(2206122) INFO: $ru = sip:400;existing=yes@172.16.1.19:7060;user=phone 1(2206122) NOTICE: Set $ru = "sip:1234;first=yes@example.com;transport=udp" 1(2206122) INFO: $ru: sip:1234;first=yes@example.com;transport=udp 1(2206122) INFO: $rU: 1234;first=yes 1(2206122) INFO: Success! 1(2206122) NOTICE: Set $rU = "1234;second=yes" 1(2206122) INFO: $ru: sip:1234;second=yes@example.com;transport=udp 1(2206122) INFO: $rU: 1234;second=yes 1(2206122) INFO: Success! ``` Same as previous, but with incoming user-param. --- ``` 1(2206122) NOTICE: Incoming INVITE to 100 1(2206122) INFO: $ru = sip:100;existing=yes@172.16.1.19:7060;user=phone 1(2206122) NOTICE: Set $rU = "1234;first=yes" 1(2206122) INFO: $ru: sip:1234;first=yes;existing=yes@172.16.1.19:7060;user=phone 1(2206122) INFO: $rU: 1234 1(2206122) ERROR: Fail! ``` This one fails in an interesting way. The incoming uri has a user-param. When overwriting $rU with a user-param, the user-param from the incoming request is kept in addition to the new one instead of being overwritten. $rU still misses (both) user-params. #### Debugging Data I have no build (yet) with EXTRA_DEBUG enabled. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3762 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3762(a)github.com>

3 months, 2 weeks

[kamailio/kamailio] tm: memory leak in case dropping messages in local-request event route (PR #3403)

by Simon Darienko

#### 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:  - [x] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description I faced an issue with memory leak in case drop NOTIFY messages in the "local-request" event route in `mem_copy_subs` and `build_uac_req` analysis of mem leak: kamcmd corex.shm_summary <code>... Mar 23 12:00:28 pbx kamailio[72308]: NOTICE: fm_status: fm_sums(): count= 11 size= 7520 bytes from presence: hash.c: mem_copy_subs(141)<br> Mar 23 12:00:28 pbx kamailio[72308]: NOTICE: fm_status: fm_sums(): count= 23 size= 22536 bytes from tm: t_msgbuilder.c: build_uac_req(1618) ...</code> a lot of dropped messages in local-request event route <code>... Mar 23 12:01:09 pbx kamailio[72308]: NOTICE: fm_status: fm_sums(): count= 83 size= 51256 bytes from presence: hash.c: mem_copy_subs(141) Mar 23 12:01:09 pbx kamailio[72308]: NOTICE: fm_status: fm_sums(): count= 98 size= 116864 bytes from tm: t_msgbuilder.c: build_uac_req(1618) ...</code> no messages, no activities <code>... Mar 23 12:02:34 pbx kamailio[72308]: NOTICE: fm_status: fm_sums(): count= 83 size= 51256 bytes from presence: hash.c: mem_copy_subs(141) Mar 23 12:02:34 pbx kamailio[72308]: NOTICE: fm_status: fm_sums(): count= 96 size= 115432 bytes from tm: t_msgbuilder.c: build_uac_req(1618) ...</code> In the code, we have a comment like "never free cbp here because if t_uac_prepare fails, cbp is not freed and thus caller has no chance to discover if it is freed or not", but we'll free the cbp in two cases: 1. in case of error, but we have if (ret == E_DROP) then ret = 0; (so, no error result) 2. in case call insert_tmcb for cbp, but we don't do it for E_DROP You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3403 -- Commit Summary -- * tm: memory leak in case dropping messages in local-request event route -- File Changes -- M src/modules/tm/uac.c (8) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3403.patch https://github.com/kamailio/kamailio/pull/3403.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3403 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3403(a)github.com>

3 months, 2 weeks

[kamailio/kamailio] registrar: adding contact and UA to xavp_cfg (Issue #3753)

by nirvanr-nextiva

### Description We are using Kamailio as a 'mid-registrar', and saving the location record (i.e calling registrar.save()) in the reply-route depending on received status code from other registrar. We noticed the saved location record had the contact URI (incl. instance id) and UA from response message; instead we would like to use the contact and UA from the original request. This feature change is similar to what was added for `tcpconn_id` in PR: https://github.com/kamailio/kamailio/pull/3430. i.e. we would set the request's contact URI and UA in `xavp_cfg` variable. Then `registrar.save.c` would use the contact and UA from `xavp_cfg`. Thanks. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3753 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3753(a)github.com>

3 months, 2 weeks

[kamailio/kamailio] ims_registrar_scscf: fix memleaks, minor refactors (PR #3787)

by Alexander Couzens

#### Pre-Submission Checklist    - [x] Commit message has the format required by CONTRIBUTING guide - [x] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] 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:  - [x] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description A couple small changes to the ims_registrar_scscf which prevents kamailio from crashing on my system. I would love to have more testing because I only did tests in my single user IMS setup. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3787 -- Commit Summary -- * ims_registrar_scscf: fix uninitialized arguments in save() * ims_registrar_scscf: refactor save_fixup4 * ims_registrar_scscf: fix typo in function name uint_fixup * ims_registrar_scscf: free_uint_fixup: fix memleak/freeing the wrong parameter -- File Changes -- M src/modules/ims_registrar_scscf/ims_registrar_scscf_mod.c (55) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3787.patch https://github.com/kamailio/kamailio/pull/3787.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3787 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3787(a)github.com>

3 months, 2 weeks

[kamailio/kamailio] Chaining Transformations {uri.param,received}{uri.host} does not work for IPv6 (Issue #3794)

by ChristianBergerSipgate

### Description Chaining the transformations {uri.param,received} and {uri.host} does not work if the address is IPv6. It works for IPv4 addresses. #### Reproduction We tested this with the following code: ``` if ($du != $null) { $var(received_uri)=$(du{uri.param,received}); if ($var(received_uri)!="") { $var(subscriber_host)=$(var(received_uri){uri.host}); } $var(test_tmp)=$(du{uri.param,received}{uri.host}); xlog("L_ERR", "WURST subscriber_host=$var(subscriber_host) test_tmp=$var(test_tmp) du=$du received_uri=$var(received_uri)"); } } #### Log Messages For IPv6 this gives us: ``` "module": "pv", "file": "pv_trans.c", "line": 1545, "function": "tr_eval_uri", "logprefix": ", "callid": "1-91(a)1.2.4.16", "x-telco-capture-id": "<null>"", "message": **"invalid uri [ab:cdef:dead:beef]:1234]\n"** "module": "core", "file": "core/lvalue.c", "line": 351, "function": "lval_pvar_assign", "logprefix": ", "callid": "1-91(a)1.2.4.16", "x-telco-capture-id": "<null>"", "message": "non existing right pvar\n" "module": "core", "file": "core/lvalue.c", "line": 411, "function": "lval_assign", "logprefix": ", "callid": "1-91(a)1.2.4.16", "x-telco-capture-id": "<null>"", "message": "assignment failed at pos: (1432,19-1432,53)\n" "module": "xlog", "file": "xlog.c", "line": 278, "function": "", "logprefix": ", "callid": "1-91(a)1.2.4.16", "x-telco-capture-id": "<null>"", "message": "WURST subscriber_host=[2001:db8:0123:4567:89ab:cdef:dead:beef] test_tmp=0 du=sip:1.2.4.129;lr;received=sip[2001:db8:0123:4567:89ab:cdef:dead:beef]:1234 received_uri=sip:[2001:db8:0123:4567:89ab:cdef:dead:beef]:1234" "module": "xlog", "file": "xlog.c", "line": 278, "function": "", "logprefix": ", "callid": "1-91(a)1.2.4.16", "x-telco-capture-id": "<null>"", "message": "determineSubscribeIpFamily: contacts worked path=0 ip=[2001:db8:0123:4567:89ab:cdef:dead:beef] af=6" ``` For IPv4 it works: `{ "idx": 8, "pid": 577, "level": "ERROR", "module": "xlog", "file": "xlog.c", "line": 278, "function": "", "logprefix": ", "callid": "1-91(a)1.2.4.16", "x-telco-capture-id": "<null>"", "message": "WURST subscriber_host=12.34.56.78 test_tmp=12.34.56.78 du=sip:1.2.4.149;lr;received=sip:12.34.56.78:1234 received_uri=sip:12.34.56.78:1234" } ` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3794 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3794(a)github.com>

3 months, 3 weeks

[kamailio/kamailio] ndb_reids module in event_route[tcp:closed] route block error: "no redis context for server" (Issue #3768)

by liangbaolin

### Description The process of using kamailio prompts the following error： ERROR: ndb_redis [redis_client.c:963]: redisc_exec(): no redis context for server: srvN I did not encounter similar errors in version 5.4.8, and there were no similar errors in other routing blocks. Suspect that the new core version has unknown logical issues with the routing block of the module in event_route.  #### Log Messages  ``` 2024-02-26T03:39:11.161557654Z 51(97) DEBUG: <core> [core/tcp_read.c:280]: tcp_read_data(): EOF on connection 0x7f24539006a0 (state: 0, flags: c018) - FD 24, bytes 0, rd-flags 10000 ([12.0.1.6]:22827 -> [12.0.1.6]:5060)51(97) DEBUG: <core> [core/tcp_read.c:343]: tcp_read(): read 0 bytes: 2024-02-26T03:39:11.161563494Z 2024-02-26T03:39:11.161567864Z 51(97) DEBUG: <core> [core/tcp_read.c:1532]: tcp_read_req(): read= 0 bytes, parsed=0, state=0, error=1 2024-02-26T03:39:11.161574144Z 51(97) DEBUG: <core> [core/tcp_read.c:1534]: tcp_read_req(): last char=0x00, parsed msg= 2024-02-26T03:39:11.161579134Z 2024-02-26T03:39:11.161584594Z 51(97) DEBUG: <core> [core/tcp_read.c:1544]: tcp_read_req(): EOF 2024-02-26T03:39:11.161598914Z 51(97) DEBUG: <core> [core/io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0x563e1ce29740, 24, -1, 0x10) fd_no=2 called 2024-02-26T03:39:11.161604494Z 51(97) DEBUG: <core> [core/tcp_read.c:1927]: handle_io(): removing from list 0x7f24539006a0 id 1 fd 24, state 2, flags c018, main fd 132, refcnt 2 ([12.0.1.6]:22827 -> [12.0.1.6]:5060) 2024-02-26T03:39:11.161610294Z 51(97) DEBUG: <core> [core/tcp_read.c:1702]: release_tcpconn(): releasing con 0x7f24539006a0, state -1, fd=24, id=1 ([12.0.1.6]:22827 -> [12.0.1.6]:5060) 2024-02-26T03:39:11.161615934Z 51(97) DEBUG: <core> [core/tcp_read.c:1705]: release_tcpconn(): extra_data (nil) 2024-02-26T03:39:11.162263374Z 83(129) DEBUG: <core> [core/tcp_main.c:3747]: handle_tcp_child(): reader response= 7f24539006a0, -1 from 0 2024-02-26T03:39:11.162286594Z 83(129) DEBUG: <core> [core/tcp_main.c:3671]: tcp_emit_closed_event(): TCP closed event creation triggered (reason: 0) 2024-02-26T03:39:11.162293034Z 83(129) DEBUG: tcpops [tcpops.c:311]: tcpops_handle_tcp_closed(): received TCP closed event 2024-02-26T03:39:11.162299134Z 83(129) DEBUG: tcpops [tcpops.c:261]: tcpops_tcp_closed_run_route(): event reason id: 0 rt: 1 2024-02-26T03:39:11.162304234Z 83(129) ERROR: tcpops [tcpops.c:278]: tcpops_tcp_closed_run_route(): run_top_route() before tev->id: 1 2024-02-26T03:39:11.162311444Z 83(129) DEBUG: <core> [core/tcp_main.c:1713]: _tcpconn_find(): 1 port 0 2024-02-26T03:39:11.162316784Z 83(129) DEBUG: <core> [core/tcp_main.c:1721]: _tcpconn_find(): c=0x7f24539006a0, c->id=1, port=22827 2024-02-26T03:39:11.162322944Z 83(129) DEBUG: <core> [core/ip_addr.c:577]: print_ip(): ip=12.0.1.6 2024-02-26T03:39:11.162328584Z 83(129) DEBUG: <core> [core/tcp_main.c:1725]: _tcpconn_find(): found connection by id: 1 2024-02-26T03:39:11.162333764Z 83(129) DEBUG: <core> [core/tcp_main.c:1713]: _tcpconn_find(): 1 port 0 2024-02-26T03:39:11.162338674Z 83(129) DEBUG: <core> [core/tcp_main.c:1721]: _tcpconn_find(): c=0x7f24539006a0, c->id=1, port=22827 2024-02-26T03:39:11.162343764Z 83(129) DEBUG: <core> [core/ip_addr.c:577]: print_ip(): ip=12.0.1.6 2024-02-26T03:39:11.162349254Z 83(129) DEBUG: <core> [core/tcp_main.c:1725]: _tcpconn_find(): found connection by id: 1 2024-02-26T03:39:11.162355494Z 83(129) DEBUG: <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 101 2024-02-26T03:39:11.162360924Z 83(129) ERROR: <script>: tcp connection closed conid: (1), tcp(conid): 1, Ri: 12.0.1.185, Rp: 5060 , si: 12.0.1.6 , sp: 22827 2024-02-26T03:39:11.162375744Z 83(129) DEBUG: <core> [core/tcp_main.c:1713]: _tcpconn_find(): 1 port 0 2024-02-26T03:39:11.162381944Z 83(129) DEBUG: <core> [core/tcp_main.c:1721]: _tcpconn_find(): c=0x7f24539006a0, c->id=1, port=22827 2024-02-26T03:39:11.162388024Z 83(129) DEBUG: <core> [core/ip_addr.c:577]: print_ip(): ip=12.0.1.6 2024-02-26T03:39:11.162395164Z 83(129) DEBUG: <core> [core/tcp_main.c:1725]: _tcpconn_find(): found connection by id: 1 2024-02-26T03:39:11.162400884Z 83(129) DEBUG: <core> [core/tcp_main.c:1713]: _tcpconn_find(): 1 port 0 2024-02-26T03:39:11.162406634Z 83(129) DEBUG: <core> [core/tcp_main.c:1721]: _tcpconn_find(): c=0x7f24539006a0, c->id=1, port=22827 2024-02-26T03:39:11.162412284Z 83(129) DEBUG: <core> [core/ip_addr.c:577]: print_ip(): ip=12.0.1.6 2024-02-26T03:39:11.162417034Z 83(129) DEBUG: <core> [core/tcp_main.c:1725]: _tcpconn_find(): found connection by id: 1 2024-02-26T03:39:11.162422294Z 83(129) DEBUG: <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 27 2024-02-26T03:39:11.162427844Z 83(129) ERROR: <script>: tcp connection closed (1) 2024-02-26T03:39:11.162433574Z 83(129) DEBUG: <core> [core/tcp_main.c:1713]: _tcpconn_find(): 1 port 0 2024-02-26T03:39:11.162439254Z 83(129) DEBUG: <core> [core/tcp_main.c:1721]: _tcpconn_find(): c=0x7f24539006a0, c->id=1, port=22827 2024-02-26T03:39:11.162444184Z 83(129) DEBUG: <core> [core/ip_addr.c:577]: print_ip(): ip=12.0.1.6 2024-02-26T03:39:11.162449324Z 83(129) DEBUG: <core> [core/tcp_main.c:1725]: _tcpconn_find(): found connection by id: 1 2024-02-26T03:39:11.162454724Z 83(129) DEBUG: <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 1 2024-02-26T03:39:11.162460094Z 83(129) DEBUG: <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 52 2024-02-26T03:39:11.162466084Z 83(129) DEBUG: <core> [core/tcp_main.c:1713]: _tcpconn_find(): 1 port 0 2024-02-26T03:39:11.162471724Z 83(129) DEBUG: <core> [core/tcp_main.c:1721]: _tcpconn_find(): c=0x7f24539006a0, c->id=1, port=22827 2024-02-26T03:39:11.162477324Z 83(129) DEBUG: <core> [core/ip_addr.c:577]: print_ip(): ip=12.0.1.6 2024-02-26T03:39:11.162482144Z 83(129) DEBUG: <core> [core/tcp_main.c:1725]: _tcpconn_find(): found connection by id: 1 2024-02-26T03:39:11.162487154Z 83(129) DEBUG: <core> [core/pvapi.c:1418]: pv_printf_mode(): final buffer length 52 2024-02-26T03:39:11.162501164Z 83(129) DEBUG: ndb_redis [redis_client.c:399]: redisc_get_server(): Hash 2100282857 (srvN) 2024-02-26T03:39:11.162508124Z 83(129) DEBUG: ndb_redis [redis_client.c:402]: redisc_get_server(): Entry 2694209461 (12.0.1.9:7469), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162514104Z 83(129) DEBUG: ndb_redis [redis_client.c:402]: redisc_get_server(): Entry 2694209462 (12.0.1.8:7469), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162520554Z 83(129) DEBUG: ndb_redis [redis_client.c:402]: redisc_get_server(): Entry 2694209448 (12.0.1.7:7469), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162526404Z 83(129) DEBUG: ndb_redis [redis_client.c:402]: redisc_get_server(): Entry 2694210133 (12.0.1.9:7369), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162532034Z 83(129) DEBUG: ndb_redis [redis_client.c:402]: redisc_get_server(): Entry 2694210134 (12.0.1.8:7369), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162537324Z 83(129) DEBUG: ndb_redis [redis_client.c:402]: redisc_get_server(): Entry 2694210120 (12.0.1.7:7369), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162542824Z 83(129) DEBUG: ndb_redis [redis_client.c:402]: redisc_get_server(): Entry 2100282854 (srvM), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162548064Z 83(129) DEBUG: ndb_redis [redis_client.c:402]: redisc_get_server(): Entry 2100282857 (srvN), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162554074Z 83(129) DEBUG: ndb_redis [redis_client.c:402]: redisc_get_server(): Entry 2100306023 (srvTPS), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162559184Z 83(129) DEBUG: ndb_redis [redis_client.c:408]: redisc_get_server(): Entry 2694209461 (12.0.1.9:7469), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162564524Z 83(129) DEBUG: ndb_redis [redis_client.c:408]: redisc_get_server(): Entry 2694209462 (12.0.1.8:7469), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162569904Z 83(129) DEBUG: ndb_redis [redis_client.c:408]: redisc_get_server(): Entry 2694209448 (12.0.1.7:7469), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162575334Z 83(129) DEBUG: ndb_redis [redis_client.c:408]: redisc_get_server(): Entry 2694210133 (12.0.1.9:7369), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162580154Z 83(129) DEBUG: ndb_redis [redis_client.c:408]: redisc_get_server(): Entry 2694210134 (12.0.1.8:7369), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162585964Z 83(129) DEBUG: ndb_redis [redis_client.c:408]: redisc_get_server(): Entry 2694210120 (12.0.1.7:7369), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162592294Z 83(129) DEBUG: ndb_redis [redis_client.c:408]: redisc_get_server(): Entry 2100282854 (srvM), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162597644Z 83(129) DEBUG: ndb_redis [redis_client.c:408]: redisc_get_server(): Entry 2100282857 (srvN), rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162611324Z 83(129) DEBUG: ndb_redis [redis_client.c:413]: redisc_get_server(): Using entry 2100282857 (srvN) 2024-02-26T03:39:11.162617084Z 83(129) DEBUG: ndb_redis [redis_client.c:960]: redisc_exec(): rsrv->ctxRedis = (nil) 2024-02-26T03:39:11.162622004Z 83(129) ERROR: ndb_redis [redis_client.c:963]: redisc_exec(): no redis context for server: srvN 2024-02-26T03:39:11.162627834Z 83(129) ERROR: tcpops [tcpops.c:280]: tcpops_tcp_closed_run_route(): run_top_route() after tev->id: 1 2024-02-26T03:39:11.162633294Z 83(129) DEBUG: <core> [core/tcp_main.c:3904]: handle_tcp_child(): case CONN_EOF tcp_emit_closed_event before 5 ``` #### SIP Traffic  ``` event_route[tcp:closed] { xlog("L_ERR", "$proto connection closed conid: ($conid), tcp(conid): $tcp(conid), Ri: $Ri, Rp: $Rp , si: $si , sp: $sp\n"); if($conid ne $null) { xlog("L_ERR", "$proto connection closed ($conid)\n"); route(TCPEVENT); } } route[TCPEVENT] { if(redis_cmd("srvN", "get %s", "$conid", "r")) { ..... } } #redis module config loadmodule "ndb_redis" modparam("ndb_redis", "cluster", 1) modparam("ndb_redis", "allow_dynamic_nodes", 1) modparam("ndb_redis", "server", "name=srvN;addr=NDB_N_REDIS_CLUSTER_MAINADDR;port=NDB_N_REDIS_CLUSTER_MAINPORT;pass=NDB_REDIS_PASSWORD") modparam("ndb_redis", "server", "name=srvM;addr=NDB_M_REDIS_CLUSTER_MAINADDR;port=NDB_M_REDIS_CLUSTER_MAINPORT;pass=NDB_REDIS_PASSWORD") modparam("ndb_redis", "server", "name=12.0.1.7:7369;addr=12.0.1.7;port=7369;pass=NDB_REDIS_PASSWORD") modparam("ndb_redis", "server", "name=12.0.1.8:7369;addr=12.0.1.8;port=7369;pass=NDB_REDIS_PASSWORD") modparam("ndb_redis", "server", "name=12.0.1.9:7369;addr=12.0.1.9;port=7369;pass=NDB_REDIS_PASSWORD") modparam("ndb_redis", "server", "name=12.0.1.7:7469;addr=12.0.1.7;port=7469;pass=NDB_REDIS_PASSWORD") modparam("ndb_redis", "server", "name=12.0.1.8:7469;addr=12.0.1.8;port=7469;pass=NDB_REDIS_PASSWORD") modparam("ndb_redis", "server", "name=12.0.1.9:7469;addr=12.0.1.9;port=7469;pass=NDB_REDIS_PASSWORD") ``` * **Operating System**:  ``` version: kamailio 5.7.4 (x86_64/linux) 9920d9-dirty flags: , EXTRA_DEBUGUSE_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: 9920d9 -dirty compiled on 09:59:52 Feb 26 2024 with gcc 7.5.0 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3768 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3768(a)github.com>

3 months, 3 weeks

[kamailio/kamailio] TSILO: ts_append_to(): transaction 11743:1310842517: error updating dset (-1) (Issue #3782)

by vteliatnykov

After the transaction was suspended, 1st user registered, got INVITE message, there is 2nd user wakes up and send REGISTER. Kamailio check if transaction suspended (for 2nd user, it is not suspended anymore), and checks if there is stored transaction. So, for 2nd user we have stored transaction, then it should append new branch. ts_append failed. if ($var(suspended) == 0) { if ($var(stored)) { # no suspended INVITE (i.e. there was at least one # registered contact for target) and 'stored' set # (i.e. ongoing transaction) -> this newly just # registered contact needs alerting. ts_append("location", "sip:$avp(extension)@LOCALVIRTUALIP"); xinfo("appending branches for sip:$avp(extension)@LOCALVIRTUALIP, result $rc"); } else { xinfo("no suspended transactions for $tu"); } return; } Mar 10 21:07:11 stage-webrtc-kama-01 /usr/sbin/kamailio[4067482]: INFO: [t3jutj5k1na4eir1o8pvk9 REGISTER WAKE_SUSPENDED:1:1339] <script>: -----------122583d4102d400d8565c6f48d217b8d Mar 10 21:07:11 stage-webrtc-kama-01 /usr/sbin/kamailio[4067482]: INFO: [t3jutj5k1na4eir1o8pvk9 REGISTER WAKE_SUSPENDED:1:1348] <script>: var(suspended)=0, tsilo=>suspended::122583d4102d400d8565c6f48d217b8d Mar 10 21:07:11 stage-webrtc-kama-01 /usr/sbin/kamailio[4067482]: INFO: [t3jutj5k1na4eir1o8pvk9 REGISTER WAKE_SUSPENDED:1:1349] <script>: var(stored)=1, tsilo=>stored::122583d4102d400d8565c6f48d217b8d Mar 10 21:07:11 stage-webrtc-kama-01 /usr/sbin/kamailio[4067482]: ERROR: [t3jutj5k1na4eir1o8pvk9 REGISTER WAKE_SUSPENDED:1:1357] tsilo [ts_append.c:152]: ts_append_to(): transaction 11743:1310842517: error updating dset (-1) Mar 10 21:07:11 stage-webrtc-kama-01 /usr/sbin/kamailio[4067482]: INFO: [t3jutj5k1na4eir1o8pvk9 REGISTER WAKE_SUSPENDED:1:1359] <script>: appending branches for sip:1000@10.160.201.190, result 1 At this moment we have active transaction `{ cell: 0x7f313d43cda8 tindex: 11743 tlabel: 1310842517 method: INVITE from: From: "9988" <sip:9988@10.156.0.6>;tag=as081c0936 to: To: <sip:1000@10.160.201.190:5070> callid: Call-ID: 66d9dace125df36915783fb379f4e3dd@10.156.0.6:5060 cseq: CSeq: 102 uas_request: yes tflags: 69 outgoings: 3 ref_count: 1 lifetime: 5402832 } ` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3782 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3782(a)github.com>

3 months, 3 weeks

[kamailio/kamailio] tcp/docs: Added tcp_accept_iplimit config sample (PR #3792)

by Arnis Voitkāns

4 months

[kamailio/kamailio] Option to not add received via param (Issue #3515)

by zusrut

### Description Hello. Probably I'm doing something wrong but I can't get rid of **received** parameter in the **Via** header in responses from kamailio by websocket transport. According [RFC 7118](https://datatracker.ietf.org/doc/rfc7118/): `` When a SIP WebSocket Server receives a request, it MAY decide not to add a "received" parameter to the top Via header. Therefore, SIP WebSocket Clients MUST accept responses without such a parameter in the top Via header regardless of whether the **Via** "sent-by" field contains a domain name. `` ### Expected behavior For responses to websocket transport have a way to not add **received** parameter in **Via** header #### Actual observed behavior Responses to OPTION or REGISTER methods trough websocket got **received** containing IP we want to not show to the end users. ### Possible Solutions maybe add a param in **tm** module or something ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.2.1 (x86_64/linux) ``` and ``` kamailio 5.6.1 (x86_64/linux) b36a13 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3515 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3515(a)github.com>

4 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev March 2024