sr-dev April 2024

sr-dev@lists.kamailio.org

12 participants
264 discussions

[kamailio/kamailio] TM crash when relaying reply, in context of unreachable rtpengine (Issue #3297)
by Alex Balashov 22 Sep '24

22 Sep '24

When relaying this `200 OK` repeatedly with calls to `rtpengine_answer()` failing because all RTPEngines in a set are unreachable... ``` Dec 8 06:24:38 gw kamailio[4823]: ERROR: rtpengine [rtpengine.c:2960]: select_rtpp_node(): rtpengine failed to select new for calllen=36 callid=8279a4ea-151e-48de-a23c-5840104126de ``` ``` SIP/2.0 200 OK v:SIP/2.0/UDP 10.150.20.20;branch=z9hG4bK03e.e4da444e627bb575ef4f46151729a1fa.0,SIP/2.0/UDP 10.151.20.108;received=10.151.20.108;rport=5060;branch=z9hG4bKKQyrBKpp04X0K Record-Route:<sip:10.150.20.20;lr;ftag=emHm2apy95jFe;rtp_relay=1;rtp_group=0> f:"14045551212"<sip:14045551212@10.151.20.108>;tag=emHm2apy95jFe t:<sip:16782001111@internal.evaristesys.com>;tag=tHQt0rDcF7UHK i:8279a4ea-151e-48de-a23c-5840104126de CSeq:60686471 INVITE m:<sip:16782001111@10.160.10.55:5060;transport=udp> User-Agent:VoiceAppServer Allow:INVITE,ACK,BYE,CANCEL,OPTIONS,MESSAGE,INFO,UPDATE,REFER,NOTIFY k:path,replaces u:talk,hold,conference,refer c:application/sdp Content-Disposition:session l:257 v=0 o=DM 1670428117 1670428118 IN IP4 10.160.10.55 s=DM c=IN IP4 10.160.10.55 t=0 0 m=audio 52418 RTP/AVP 0 101 a=rtpmap:0 PCMU/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=rtcp:52419 IN IP4 10.160.10.55 ``` Repeat INVITEs eventually result in a crash. This backtrace is taken from a different server but identical scenario: ``` #0 t_should_relay_response (Trans=0x7f4aee56ba80, new_code=200, branch=0, should_store=0x7ffd8b8bbba0, should_relay=0x7ffd8b8bbba4, cancel_data=0x7ffd8b8bbe40, reply=0x7f4afe40df70) at t_reply.c:1285 1285 && !(inv_through && Trans->uac[branch].last_received<300)) { Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.192.el6.x86_64 jansson-2.11-1.el6.x86_64 keyutils-libs-1.4-5.el6.x86_64 krb5-libs-1.10.3-57.el6.x86_64 libcom_err-1.41.12-22.el6.x86_64 libev-4.03-3.el6.x86_64 libselinux-2.0.94-7.el6.x86_64 libunistring-0.9.3-5.el6.x86_64 openssl-1.0.1e-48.el6_8.3.x86_64 sqlite-3.6.20-1.el6_7.2.x86_64 zlib-1.2.3-29.el6.x86_64 (gdb) where #0 t_should_relay_response (Trans=0x7f4aee56ba80, new_code=200, branch=0, should_store=0x7ffd8b8bbba0, should_relay=0x7ffd8b8bbba4, cancel_data=0x7ffd8b8bbe40, reply=0x7f4afe40df70) at t_reply.c:1285 #1 0x00007f4afd73ab7d in relay_reply (t=0x7f4aee56ba80, p_msg=0x7f4afe40df70, branch=0, msg_status=200, cancel_data=0x7ffd8b8bbe40, do_put_on_wait=1) at t_reply.c:1821 #2 0x00007f4afd740c38 in reply_received (p_msg=0x7f4afe40df70) at t_reply.c:2558 #3 0x00000000004b5d6a in do_forward_reply (msg=0x7f4afe40df70, mode=0) at core/forward.c:747 #4 0x00000000004b78c9 in forward_reply (msg=0x7f4afe40df70) at core/forward.c:852 #5 0x000000000054982b in receive_msg ( buf=0xb27700 "SIP/2.0 200 OK\r\nv:SIP/2.0/UDP xxx;branch=z9hG4bK9915.dcfe6d03cb21e6c94a6705adb095c566.0,SIP/2.0/UDP xxx;received=xxx;rport=5060;branch=z9hG4bKZmZp0NZv3FvQB\r\nRecord-Rout"..., len=984, rcv_info=0x7ffd8b8bc6c0) at core/receive.c:434 #6 0x00000000006658ca in udp_rcv_loop () at core/udp_server.c:541 #7 0x000000000042500f in main_loop () at main.c:1655 #8 0x000000000042c5bb in main (argc=11, argv=0x7ffd8b8bcc88) at main.c:2696 ``` Looks like in the crash frame, `Trans->uac` is `NULL`: ``` (gdb) frame 0 #0 t_should_relay_response (Trans=0x7f4aee56ba80, new_code=200, branch=0, should_store=0x7ffd8b8bbba0, should_relay=0x7ffd8b8bbba4, cancel_data=0x7ffd8b8bbe40, reply=0x7f4afe40df70) at t_reply.c:1285 1285 && !(inv_through && Trans->uac[branch].last_received<300)) { (gdb) print Trans->uac $1 = (struct ua_client *) 0x0 ``` I have seen this crash from time to time, though it is infrequent. It always seems to occur when there are problems reaching RTPEngine in a timely fashion. This is on Kamailio 5.2.4:de9a03, which I know has long fallen off the back of the maintenance train. However, line 1386 of `t_reply.c` in `master:HEAD` shows that the code is no different now: https://github.com/kamailio/kamailio/blob/master/src/modules/tm/t_reply.c#L… Of course, it's possible that something upstream has changed so as to prevent this state. Otherwise, I suppose a null pointer safety check for `Trans->uac` is recommended. I'd be happy to submit a patch, just wasn't sure if the feeling was more that this should be resolved higher up the call stack. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3297 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3297(a)github.com>

2 3

[kamailio/kamailio] core/tcp_main: Match protocol when lookup tcp/tls connections (PR #3810)
by Xenofon Karamanos 21 Sep '24

21 Sep '24

#### 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) - [x] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [x] PR should be backported to stable branches - [x] Tested changes locally - [x] Related to issue [reported in lists](https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.k… #### Description  This PR aims to fix a bug/security issue where data that was supposed to be encrypted and transferred through TLS, were transferred instead with TCP protocol. More information and how to replicate can be found in the above [issue](https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.k… in list. This PR suggests using also the protocol to match if a TCP connection exists, and when doing connection lookups, otherwise, it might return a wrong connection, ie a TCP one when we are asking for a TLS one (a case when source ip/port and dest IP are same but dest port is set 0 (wildcard) ). `tcpconn_get` was left unchanged due to being used by some modules and not wanting to break them. Please advise whether it should be beneficial to also change it. In some cases like, `tcpconn_add_alias` and `tcpconn_get` we used the `PROTO_NONE` which preserves the original behavior. `tcpconn_add_alias` we do have the protocol available, should it be also used? `tcpconn_get` does not have the protocol available unless we pass it as an argument. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3810 -- Commit Summary -- * tcp_main: Add protocol argument for searching tcp/tls connections * tcp_main: Add proto argument to tcpconn_exists function * tcp_main: Update comment docs * core/forward: Match protocol when forwarding * tcp_main: Match wss protocol -- File Changes -- M src/core/forward.h (3) M src/core/tcp_conn.h (3) M src/core/tcp_main.c (43) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3810.patch https://github.com/kamailio/kamailio/pull/3810.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3810 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3810(a)github.com>

5 10

[kamailio/kamailio] Hello, I would like to confirm if our SMS module supports sending long SMS messages ？ (Issue #3822)
by Helloworld1668 13 Aug '24

13 Aug '24

### Description  Hello, when I was testing the SMSC SMS business, I found that the SMS could not be forwarded by the SMSC when the characters were too long, approximately 117 characters. The issue was traced back to the smsops module, which has a limit on the length of the SMS, but it seems that it does not handle SMS segmentation. The error message returned is as follows. Could you please provide some suggestions and help? ### Troubleshooting #### Reproduction  #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages ``` 2024-04-24T05:59:01.837950514Z 3(24) ERROR: <script>: SMS for "" (Valid: 0 ) 2024-04-24T05:59:14.466167796Z 2(23) ERROR: <script>: 3GPP-SMS: MESSAGE (sip:+8618107550088@ims.mnc011.mcc460.3gppnetwork.org (172.22.0.20:6060) to tel:+8613800138000, bnecb4LQJ(a)10.46.2.1) 2024-04-24T05:59:14.466173859Z 2(23) ERROR: smsops [smsops_impl.c:1055]: decode_3gpp_sms(): Length of TP-User-Data payload exceeds maximum length! 2024-04-24T05:59:14.466175929Z 2(23) ERROR: smsops [smsops_impl.c:1320]: pv_get_sms(): Error getting/decoding RP-Data from request! 2024-04-24T05:59:14.466191554Z 2(23) ERROR: smsops [smsops_impl.c:1055]: decode_3gpp_sms(): Length of TP-User-Data payload exceeds maximum length! 2024-04-24T05:59:14.466194545Z 2(23) ERROR: smsops [smsops_impl.c:1320]: pv_get_sms(): Error getting/decoding RP-Data from request! 2024-04-24T05:59:14.466196517Z 2(23) ERROR: smsops [smsops_impl.c:1055]: decode_3gpp_sms(): Length of TP-User-Data payload exceeds maximum length! 2024-04-24T05:59:14.466198406Z 2(23) ERROR: smsops [smsops_impl.c:1320]: pv_get_sms(): Error getting/decoding RP-Data from request! 2024-04-24T05:59:14.466200311Z 2(23) ERROR: <script>: SMS for "" (Valid: ) 2024-04-24T05:59:14.466255812Z 2(23) ERROR: smsops [smsops_impl.c:1055]: decode_3gpp_sms(): Length of TP-User-Data payload exceeds maximum length! 2024-04-24T05:59:14.466276249Z 2(23) ERROR: smsops [smsops_impl.c:1903]: isRPDATA(): Error getting/decoding RP-Data from request! ``` #### SIP Traffic  ``` ``` ![image](https://github.com/kamailio/kamailio/assets/152272255/808e65ce-9763-4056-9924-77122f6d9c25) ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 4fb8ac -dirty compiled on 03:11:49 Apr 24 2024 with gcc 9.4.0 ``` version: kamailio 5.9.0-dev0 (x86_64/linux) 4fb8ac-dirty 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_SEND_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB ``` * **Operating System**:  ``` Linux sder 4.15.0-128-generic #131-Ubuntu SMP Wed Dec 9 06:57:35 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3822 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3822(a)github.com>

3 5

[kamailio/kamailio] Mem leak in smsops which leads to the udp receiver process leak memory continuously (Issue #3833)
by paresh-panda 02 Aug '24

02 Aug '24

Hi, I am using Kamailio 5.8.1 ( ubuntu 22.04 Jammy 64 Bit),. Below are the observations. I am running a load of 500 3GPP IMS SMS which kamailio decodes and sends to another application over Rabbit MQ (Kazoo Module). **-m 512 -M 256** , using 512 MB Shared memory and 256MB Package Memory. When the load for 20 mins the available Memory drops from **80% to 25%** And I see below error logs > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/mem/q_malloc.c:324]: qm_find_free(): qm_find_free(0x7ff912e21010, 192); Free fragment not found! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/mem/q_malloc.c:463]: qm_malloc(): qm_malloc(0x7ff912e21010, 192) called from smsops: smsops_impl.c: decode_3gpp_sms(813), module: smsops; Free fragment not found! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:815]: decode_3gpp_sms(): Error allocating 192 bytes! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:1320]: pv_get_sms(): Error getting/decoding RP-Data from request! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/mem/q_malloc.c:324]: qm_find_free(): qm_find_free(0x7ff912e21010, 192); Free fragment not found! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/mem/q_malloc.c:463]: qm_malloc(): qm_malloc(0x7ff912e21010, 192) called from smsops: smsops_impl.c: decode_3gpp_sms(813), module: smsops; Free fragment not found! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:815]: decode_3gpp_sms(): Error allocating 192 bytes! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:1320]: pv_get_sms(): Error getting/decoding RP-Data from request! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/pvapi.c:1136]: pv_parse_format(): could not allocate private memory from pkg pool > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/sr_module.c:1318]: fix_param(): bad PVE format: "PRD-IR92/11 term-Motorola/XT2205-1-T2STS33.105-51-11-1-2-2 device-type/smart-phone" > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/mod_fix.c:601]: fixup_spve_null(): Cannot convert function parameter 1 to spve > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1178]: do_action(): runtime fixup failed for jansson_set param 3 > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1566]: do_action(): run action error at: /etc/kamailio/kamailio.cfg:539 > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/sr_module.c:1208]: fix_param(): could not allocate private memory from pkg pool > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/mod_fix.c:601]: fixup_spve_null(): Cannot convert function parameter 1 to spve > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1178]: do_action(): runtime fixup failed for jansson_set param 3 > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1566]: do_action(): run action error at: /etc/kamailio/kamailio.cfg:540 > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/sr_module.c:1208]: fix_param(): could not allocate private memory from pkg pool > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/mod_fix.c:601]: fixup_spve_null(): Cannot convert function parameter 1 to spve > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1178]: do_action(): runtime fixup failed for jansson_set param 3 > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1566]: do_action(): run action error at: /etc/kamailio/kamailio.cfg:541 > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/rvalue.c:1321]: rval_get_str(): could not allocate private memory from pkg pool > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1178]: do_action(): failed to convert RVE to string > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1566]: do_action(): run action error at: /etc/kamailio/kamailio.cfg:542 > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/rvalue.c:1321]: rval_get_str(): could not allocate private memory from pkg pool > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1178]: do_action(): failed to convert RVE to string > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1566]: do_action(): run action error at: /etc/kamailio/kamailio.cfg:543 > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:815]: decode_3gpp_sms(): Error allocating 192 bytes! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:1320]: pv_get_sms(): Error getting/decoding RP-Data from request! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:815]: decode_3gpp_sms(): Error allocating 192 bytes! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:1320]: pv_get_sms(): Error getting/decoding RP-Data from request! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:815]: decode_3gpp_sms(): Error allocating 192 bytes! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:1320]: pv_get_sms(): Error getting/decoding RP-Data from request! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:815]: decode_3gpp_sms(): Error allocating 192 bytes! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} smsops [smsops_impl.c:1320]: pv_get_sms(): Error getting/decoding RP-Data from request! > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/rvalue.c:1321]: rval_get_str(): could not allocate private memory from pkg pool > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1178]: do_action(): failed to convert RVE to string > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1566]: do_action(): run action error at: /etc/kamailio/kamailio.cfg:555 > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/rvalue.c:1321]: rval_get_str(): could not allocate private memory from pkg pool > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1178]: do_action(): failed to convert RVE to string > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1566]: do_action(): run action error at: /etc/kamailio/kamailio.cfg:556 > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/rvalue.c:1321]: rval_get_str(): could not allocate private memory from pkg pool > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1171]: do_action(): failed to convert RVE to string > Apr 29 13:28:53 stgn-haud-vm-ub-kamailio01 /usr/sbin/kamailio[5520]: ERROR: {1 1 MESSAGE 739708-3401(a)192.168.136.152} <core> [core/action.c:1566]: do_action(): run action error at: /etc/kamailio/kamailio.cfg:559 > I am attaching the configuration for reference. Help on this is much appreciated [configfiles.tar.gz](https://github.com/kamailio/kamailio/files/15148792/con… , I am looking into this issue for quite a long time. Thank you! Regards Paresh -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3833 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3833(a)github.com>

5 7

[kamailio/kamailio] Uint fixes (PR #3828)
by Tyler Moore 01 Aug '24

01 Aug '24

#### 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 - [ ] 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 Adding support for converting unsigned integers from database tables into kamailio pseudo variables usable in the routing config. This is quite useful when pulling `int unsigned` fields from a database, in modules that support "extra fields" in their module parameters. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3828 -- Commit Summary -- * permissions: fixup uint support in address table reload * htable: add uint support when packing an htable * lib/srdb1: add uint support for db->pv conversions -- File Changes -- M src/lib/srdb1/db_ut.c (4) M src/modules/htable/ht_db.c (6) M src/modules/permissions/address.c (35) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3828.patch https://github.com/kamailio/kamailio/pull/3828.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3828 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3828(a)github.com>

4 9

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

24 Jul '24

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>

3 4

[kamailio/kamailio] Dialog DMQ sync: Timer needs fixing, firing on wrong node! (Issue #3656)
by Benoît Panizzon 17 Jul '24

17 Jul '24

Situation: Two Kamailio nodes syncing dialog profiles via DMQ Observation: When a dialog timeout is encountered, about half of the time, the timeout is triggered on the peer node not handling the dialog preventing the call to be correctly terminated and also leaving entries in the dialog database which never get deleted. https://kamailio.org/docs/modules/5.7.x/modules/dialog.html#dialog.p.enable… Makes clear, that only the node which is handling the dialog in question, can make changes not related to the dialog profiles. So when a dialog times out, it is this node which has to trigger the timeout, not any other one. When looking at the source code, it is clear, that the 'lifetime' is transmitted via DMQ dialog message to the peer nodes, which in turn arm a timer. So it is obvious, this time will trigger, sometimes before the instance handling the dialog itself triggers that timer. With some assistance of @oej I found a way to alter the JSON payload to extend the lifetime on the peer nodes: ``` route[DMQ_CAPTURE] { if(is_method("KDMQ")) { if(has_body("application/json") && $fU == 'dialog') { if (jansson_get("lifetime", $rb, "$var(lifetime)")) { $var(new_lifetime) = $var(lifetime) + 60; # Add 60 seconds on DMQ peer to make sure it expires AFTER main node. $var(newrb) = $rb; jansson_set("integer", "lifetime", $var(new_lifetime), "$var(newrb)"); set_body("$var(newrb)","application/json"); msg_apply_changes(); } } dmq_handle_message(); exit; } } ``` Testing with this config fixed the issue of the timeout firing on a peer node instead of the node handling the dialog. Issue is present in 5.5, 5.6 and after looking at the code, I assume also on 5.7 -Benoît -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3656 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3656(a)github.com>

6 15

[kamailio/kamailio] Debian package build fails for Kamailio 5.7.4 (Issue #3722)
by Alexander Bakker 15 Jul '24

15 Jul '24

### Description The Debian package build fails for Kamailio 5.7.4 because it can't find static libssl. This happens because ``LIBSSL_STATIC_SRCPATH`` is set to the wrong location in the rules file. ### Troubleshooting #### Reproduction 1. Run ``ln -s pkg/kamailio/deb/bookworm debian`` 2. Run ``make deb`` #### Output ``` gcc -shared -g -m64 -Wl,-O2 -Wl,-E -Wl,-z,relro -pthread -rdynamic "-ldl" -Wl,-Bsymbolic-functions tls_bio.o tls_cfg.o tls_config.o tls_ct_wrq.o tls_domain.o tls_dump_vf.o tls_init.o tls_locking.o tls_map.o tls_rand.o tls_rpc.o tls_select.o tls_server.o tls_util.o tls_verify.o tlsa_mod.o -lm /usr/lib64/libssl.a /usr/lib64/libcrypto.a -o tlsa.so /usr/bin/ld: cannot find /usr/lib64/libssl.a: No such file or directory /usr/bin/ld: cannot find /usr/lib64/libcrypto.a: No such file or directory collect2: error: ld returned 1 exit status make[5]: *** [../../Makefile.rules:191: tlsa.so] Error 1 ``` ### Possible Solutions An extremely hacky workaround is to patch the rules file to point ``LIBSSL_STATIC_SRCPATH`` to the right location: ``` sed -i -e "/LIBSSL_STATIC_SRCPATH/a export\\ LIBSSL_STATIC_SRCPATH=\\/usr\\/lib\\/$(uname -m)-linux-gnu" pkg/kamailio/deb/bookworm/rules ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.7.4 (x86_64/linux) 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: unknown compiled with gcc 12.2.0 ``` * **Operating System**: ``` Distributor ID: Debian Description: Debian GNU/Linux 12 (bookworm) Release: 12 Codename: bookworm ``` ``` Linux 6.5.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 14 14:59:49 UTC 2023 x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3722 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3722(a)github.com>

3 10

[kamailio/kamailio] No CDR is written on failover (Issue #3254)
by Earn330 15 Jul '24

15 Jul '24

Hi, I think there is an issue with writing CDRs on failover scenarios. I have two servers with Kamailio. Both server running Debian 11 (bulleye) and latest Kamailio 5.6.1 from git. I'm using DMQ to sync dialogs and htable between these servers, so both servers have the same knowledge of dialog state. Both Kamailio uses nobind option, so I can switch a VIP from one server to the other one. This is managed with keepalived. Switching the VIP from one server the other one works fine an while a call is running I can switch the VIP. I can see that the BYE Message is handled OK after I made a switch. I can see that acc is triggered but what is missing is acc_cdr in this case. I'm using htable to fill all necessary variables to complete the CDR an I can see that all values are synced correctly. The acc_cdr is created fine if there is no failover so i think it can't be an configuration issue. Both server holds the same Kamailio configuration except the IP. `version: kamailio 5.6.1 (x86_64/linux) bfc5c2-dirty 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: bfc5c2 -dirty compiled with gcc 10.2.1` `root@voip-lab-proxy01:~# lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 11 (bullseye) Release: 11 Codename: bullseye` `root@voip-lab-proxy01:~# lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian Address sizes: 38 bits physical, 48 bits virtual CPU(s): 4 On-line CPU(s) list: 0-3 Thread(s) per core: 1 Core(s) per socket: 4 Socket(s): 1 NUMA node(s): 1 Vendor ID: GenuineIntel CPU family: 6 Model: 23 Model name: Intel(R) Xeon(R) CPU E5420 @ 2.50GHz Stepping: 10 CPU MHz: 2500.088 BogoMIPS: 5000.17 Virtualization: VT-x Hypervisor vendor: KVM Virtualization type: full L1d cache: 128 KiB L1i cache: 128 KiB L2 cache: 16 MiB L3 cache: 16 MiB NUMA node0 CPU(s): 0-3 Vulnerability Itlb multihit: Not affected Vulnerability L1tf: Mitigation; PTE Inversion; VMX EPT disabled Vulnerability Mds: Vulnerable: Clear CPU buffers attempted, no microcode; SMT Host state unknown Vulnerability Meltdown: Mitigation; PTI Vulnerability Mmio stale data: Unknown: No mitigations Vulnerability Retbleed: Not affected Vulnerability Spec store bypass: Vulnerable Vulnerability Spectre v1: Mitigation; usercopy/swapgs barriers and __user pointer sanitization Vulnerability Spectre v2: Mitigation; Retpolines, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected Vulnerability Srbds: Not affected Vulnerability Tsx async abort: Not affected Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx pdpe1gb lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni vmx ssse3 cx16 pdcm sse4_1 x2apic tsc_deadline_timer xsave hypervisor lahf_lm cpuid_fault pti tpr_shadow vnmi flexpriority vpid tsc_adjust arat arch_capabilit ies` If you need more information, please let me know. As I'm running this on a test system I can reproduce the issue at any time. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3254 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3254(a)github.com>

5 9

[kamailio/kamailio] extented haproxy protocol support (PR #3731)
by sergey-safarov 12 Jul '24

12 Jul '24

#### 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 - [ ] Small bug fix (non-breaking change which fixes an issue) - [x] 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 #3667 #### Description Allow creating Record-Route and Via header using destination address and port in the haproxy protocol header. PR created behalf @ivanuschak You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3731 -- Commit Summary -- * core: extented haproxy protocol parser * rr: extented haproxy protocol suppport * path: extented haproxy protocol suppport * websocket: extented haproxy protocol suppport * siptrace: extented haproxy protocol suppport -- File Changes -- M src/core/forward.h (4) M src/core/msg_translator.c (137) M src/core/parser/msg_parser.h (1) M src/core/receive.c (6) M src/core/receive.h (3) M src/core/tcp_conn.h (1) M src/core/tcp_main.c (22) M src/core/tcp_read.c (20) M src/modules/path/path.c (2) M src/modules/rr/loose.c (4) M src/modules/rr/record.c (6) M src/modules/siptrace/siptrace.c (89) M src/modules/websocket/ws_frame.c (9) M src/modules/websocket/ws_handshake.c (3) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3731.patch https://github.com/kamailio/kamailio/pull/3731.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3731 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3731(a)github.com>

6 22

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev April 2024