sr-dev January 2024

sr-dev@lists.kamailio.org

19 participants
307 discussions

[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>

2 months, 2 weeks

[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>

3 months

[kamailio/kamailio] branch_failure route in case 503 and dns failover (PR #3138)

by vlitvinov

3 months, 2 weeks

[kamailio/kamailio] Consider adding socket options SO_BINDTODEVICE when the interface name is given for listen in the config file (Issue #3716)

by Harish S

3 months, 2 weeks

[kamailio/kamailio] topos module breaks UPDATE (Issue #3437)

by Guybrush T.

### Description Kamailio v5.5.6 with topos module and postgres DB. UAC (A) -> Kamailio Registrar (B) -> Kamailio PSTN GW (C) -> PSTN (D) Call goes from A to D, PSTN sends UPDATE, UPDATE is routed from C to A instead to B and then to A. #### Reproduction Caller calls callee and receives an UPDATE from callee. In my case it was when the call was routed to voicemail. #### Log Messages ``` Kamailio takes the wrong route in UPDATE (upstream) case. May 3 15:23:12 sipproxy /usr/sbin/kamailio[263013]: DEBUG: topos [tps_msg.c:882]: tps_request_received(): r-uri updated to: [sip:1234@<UAC-IP>;uniq=B0EB9A84A278626DA07219E2AE01C] May 3 15:23:12 sipproxy /usr/sbin/kamailio[263013]: DEBUG: topos [tps_msg.c:187]: tps_add_headers(): adding to headers(0) - [Route: sip:<<KamailioPSTNgwIP>>;lr=on;ftag=9945501E2B94B883;did=1fc.42f;nat=yes#015#012] May 3 15:23:12 sipproxy /usr/sbin/kamailio[263013]: DEBUG: topos [tps_msg.c:187]: tps_add_headers(): adding to headers(0) - [P-SR-XUID: atpsh-64527b0a-40362-1#015#012] The right one would be the x_rr (a_rr), but it takes only the s_rr: May 3 15:23:12 sipproxy /usr/sbin/kamailio[263013]: DEBUG: db_postgres [km_res.c:234]: db_postgres_convert_rows(): PQgetvalue(0x7fcb4893db50,0,7)=[sip:<KamailioRegistrarIP>;lr=on;ftag=9945501E2B94B883;did=1fc.7b92] May 3 15:23:12 sipproxy /usr/sbin/kamailio[263013]: DEBUG: db_postgres [km_res.c:242]: db_postgres_convert_rows(): [0][7] Column[x_rr]=[sip:<KamailioRegistrarIP>;lr=on;ftag=9945501E2B94B883;did=1fc.7b92] May 3 15:23:12 sipproxy /usr/sbin/kamailio[263013]: DEBUG: db_postgres [km_res.c:234]: db_postgres_convert_rows(): PQgetvalue(0x7fcb4893db50,0,8)=[sip:<PSTNgw>:5060;transport=udp;lr;Hpt=8ef8_116;CxtId=3;TRC=ffffffff-ffffffff;X-HwB2bUaCookie=18614] May 3 15:23:12 sipproxy /usr/sbin/kamailio[263013]: DEBUG: db_postgres [km_res.c:242]: db_postgres_convert_rows(): [0][8] Column[y_rr]=[sip:<PSTNgw>:5060;transport=udp;lr;Hpt=8ef8_116;CxtId=3;TRC=ffffffff-ffffffff;X-HwB2bUaCookie=18614] May 3 15:23:12 sipproxy /usr/sbin/kamailio[263013]: DEBUG: db_postgres [km_res.c:234]: db_postgres_convert_rows(): PQgetvalue(0x7fcb4893db50,0,9)=[sip:<<KamailioPSTNgwIP>>;lr=on;ftag=9945501E2B94B883;did=1fc.42f;nat=yes] May 3 15:23:12 sipproxy /usr/sbin/kamailio[263013]: DEBUG: db_postgres [km_res.c:242]: db_postgres_convert_rows(): [0][9] Column[s_rr]=[sip:<<KamailioPSTNgwIP>>;lr=on;ftag=9945501E2B94B883;did=1fc.42f;nat=yes] May 3 15:23:12 sipproxy /usr/sbin/kamailio[263019]: DEBUG: db_postgres [km_res.c:242]: db_postgres_convert_rows(): [0][10] Column[a_rr]=[sip:<KamailioRegistrarIP>;lr=on;ftag=9945501E2B94B883;did=1fc.7b92] May 3 15:23:12 sipproxy /usr/sbin/kamailio[263019]: DEBUG: db_postgres [km_res.c:234]: db_postgres_convert_rows(): PQgetvalue(0x7fcb4893dbd8,0,11)=[] ``` ### Possible Solutions Respect Route headers for UPDATE messages. ### Additional Information Current running kamailio 5.5.6 but tried also latest 5.6.4 with same behavior. ``` version: kamailio 5.5.6 (x86_64/linux) 72dbb0 flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MMAP, PKG_MALLOC, 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: 72dbb0 compiled on 05:48:21 Apr 27 2023 with gcc 11.3.0 ``` * **Operating System**: ``` Distributor ID: Ubuntu Description: Ubuntu 22.04.2 LTS Release: 22.04 Codename: jammy Linux sipproxy 5.15.0-70-generic #77-Ubuntu SMP Tue Mar 21 14:02:37 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux ``` Possibly related bug: https://github.com/kamailio/kamailio/issues/3090 -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3437 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3437(a)github.com>

3 months, 2 weeks

[kamailio/kamailio] xhttp: fix execution of async functions (PR #3723)

by Vadim Saranov

#### 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 - [x] Related to issue #3720 #### Description Fixing R-RURI and adding necessary headers when creating fake_msg in xhttp_mod.c for successful message validation and the ability to perform various kamailio functions from event_route[xhttp:request]. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3723 -- Commit Summary -- * xhttp: fix execution of async functions -- File Changes -- M src/modules/xhttp/xhttp_mod.c (39) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3723.patch https://github.com/kamailio/kamailio/pull/3723.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3723 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3723(a)github.com>

3 months, 3 weeks

[kamailio/kamailio] Docs: TLS module known limitation needs clarifications (Issue #3717)

by Thierno IB. BARRY

### Description We recently deployed successfully Kamailio with TLS certificates. Now we would like to use let's encrypt certificate which expire after 3 months. Means we need to renew certificate approximatively every 2 months. But while reading docs, in [known limitations](https://kamailio.org/docs/modules/devel/modules/tls.html#tls.k… it says : > TLS specific config reloading is not safe, so for now better don't use it, especially under heavy traffic. We struggle to understand if this behaviour is risky and not recommended under heavy traffic for certificate renewal. The doc has been added initially by @poandrei 18 years ago in Feb 21 2007 (see [commit](https://github.com/kamailio/kamailio/commit/32e4977cdb9c1c9ca24c140…) While digging we came across few discussions Kamailio user groups which are saying "the opposite" (kind of): - [Comments by a co-founder of Kamailio ](https://www.mail-archive.com/sr-users@lists.kamailio.org/msg16014.html)stating that the old connections shouldn’t be affected by reload. - Comments by a Kamailio core developer stating that certificate reload is fine with the “reload” cmd ([link1](https://lists.kamailio.org/pipermail/sr-users/2022-February/114296.h…, [link2](https://github.com/kamailio/kamailio/issues/3305)) Plus in another section in docs: - [By definition :](https://kamailio.org/docs/modules/devel/modules/tls.html#tls.r.tls.reload) (the) existing active TLS connections are not terminated and they continue to use the old certificates. The new configuration will be used for new connections. So 18 years after, Is it safe to use `tls.reload` command in production and in heavy traffic for **TLS certificate renewal** ? Because it sounds scary and confusing. So the documentation as it is, really needs clarifications to let users know which risk they're taking when running the `tls.reload` command.  ### Expected behavior The document should clearly documents risks, at least for certificate renewal. #### Actual observed behavior Docs and Kamailio user/dev groups are confusing. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3717 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3717(a)github.com>

4 months

[kamailio/kamailio] t_uac_send parser does not like exclamation or other non alphabetic characters in Contact header (Issue #3682)

by xaled1

Hi there is an issue with the SIP parser for the t_uac_send function https://www.kamailio.org/docs/modules/devel/modules/tm.html#tm.f.t_uac_send If I call this function for example: t_uac_send("INVITE", "sip:test@123.123.123.123:5060", "", "" ,"Content-Type: text/plain\r\nContact: <sip:85951b3d-096c-95d6-5f05-4f38095aca9f@172.17.64.120:5060;transport=tcp>;+u.sip!devicename.ccm.cisco.com=\"SEP5486BC7F2BBC\"", "Testbody") Then the resulting request is broken - it's probably due to a character (exclamation mark?) in the Contact header.... I tested it with a call from kemi, but it probably also occurs when you run it with a normal kamailio -script tests -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3682 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3682(a)github.com>

4 months

[kamailio/kamailio] Dispatcher: added two new flags to mode parameter of ds_is_from_list function for more strictly matching (PR #3699)

by Dennis

#### Pre-Submission Checklist    - [ ] Commit message has the format required by CONTRIBUTING guide - [ ] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [ ] 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 - [ ] 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 - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description This PR adds 2 new flags to the mode parameter of the ds_is_from_list function. Some times the dispatcher configuration can look like this (route attribute is just for exampe, sockname is important here): 70 sip:192.168.1.1:5060;transport=udp 0 1 route=route1;sockname=udp_5060 71 sip:192.168.1.1:5060;transport=udp 0 1 route=route2;sockname=udp_5061 72 sip:192.168.1.1:5060;transport=udp 0 1 route=route3;sockname=udp_5062 73 sip:192.168.1.1:5060;transport=udp 0 1 route=route4;sockname=udp_5063 Here we have one host/port/protocol on the remote side and different ports that we are listening on, In stock dispatcher version ds_is_from_list(-1,0) will always match first available - 70, but this is not right for dst ports 5061-5063 (sockets in realality, because we can have different local ip on same port also). The new mode flag DS_MATCH_SOCKET (8) allow match for dispatcher socket also. Second flag is DS_MATCH_STRICTEST (16), it allow to match more strictness target in "address/protocol/port/socket" key, for example: 70 sip:192.168.1.1;transport=udp 0 1 route=route1 71 sip:192.168.1.1:5061;transport=udp 0 1 route=route2 72 sip:192.168.1.1:5062;transport=udp 0 1 route=route3 73 sip:192.168.1.1;transport=udp 0 1 route=route4;socket=udp:192.168.10.10:5063 if packet come from from any port of sip:192.168.1.1;transport=udp except 5061-5062 ds_is_from list will return 70, if received port also is 5063 the result will be 73, packets from ports 5061-5062 will be matched at 71-72 respectively. In stock version of ds_is_from_list the result will always be 70. Note, the DS_MATCH_STRICTEST method can be more compute intensive, because we can potentially traverse all the dispatcher tree. The behavior of existing flags are not changed. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3699 -- Commit Summary -- * dispatcher: added two new flags to mode parameter of ds_is_from_list function for more strictly matching -- File Changes -- M src/modules/dispatcher/dispatch.c (112) M src/modules/dispatcher/dispatch.h (2) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3699.patch https://github.com/kamailio/kamailio/pull/3699.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3699 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3699(a)github.com>

4 months

Roadmap to next major Kamailio release series v5.8.x

by Daniel-Constantin Mierla

Hello, discussed a bit during the online Kamailio devel meeting, it is time to set the milestones towards the next major Kamailio release series v5.8.x. If no other suggestions that suit more developers, I would propose to freeze by end of this month or early February, then test for about 4 weeks as usual and release by end of February or during March. If anyone wants to add new features/modules, they have to be published till freezing date, either pushed in the git repository or proposed as pull request. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio Advanced Training, February 20-22, 2024 -- asipto.com Kamailio World Conference, April 18-19, 2024, Berlin -- kamailioworld.com

4 months, 1 week

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev January 2024