sr-dev March 2025

sr-dev@lists.kamailio.org

10 participants
178 discussions

[kamailio/kamailio] If fix_nated_contact is used, then remove_hf("Contact"), the contact header will not be deleted cleanly. (Issue #4190)
by QuincyGao 08 May '25

08 May '25

QuincyGao created an issue (kamailio/kamailio#4190)  ### Description  I want to use opensips as SBC, When the agent registers to kamailio, the contact content is modified to the ip and port of kamailio, and then Register is forwarded to the agent. remove_hf("Contact") can't remove the whole Contact( field, vlue). here is my config: ``` route[REGISTRAR] { if (!is_method("REGISTER")) return; if(isflagset(FLT_NATS)) { setbflag(FLB_NATB); #!ifdef WITH_NATSIPPING # do SIP NAT pinging setbflag(FLB_NATSIPPING); #!endif } fix_nated_contact(); if (!save("location","0x02")) { #if (!save("location")) { sl_reply_error(); } $fs="udp:172.16.4.111:5461"; $du="sip:172.16.4.114:5060"; remove_hf("Contact"); $var(contact) = "Contact: <sip:" +$fU+"@"+"172.16.4.111:5461>;expires=120\r\n" ; append_hf("$var(contact)"); route(RELAY); exit; } ``` here is the sip message: ``` 2025/03/26 16:36:07.706093 172.16.4.111:5461 -> 172.16.4.114:5060 REGISTER sip:172.16.4.111:5460 SIP/2.0 Via: SIP/2.0/UDP 172.16.4.111:5461;branch=z9hG4bKfc7e.d2df36f3b5681afeb71e442e645de38d.0 Via: SIP/2.0/UDP 172.16.80.3:49309;received=172.16.80.3;rport=49309;branch=z9hG4bKPj8ab8bd1d3c3a4c1bb0cd639540fa3183 Max-Forwards: 69 From: <sip:1008@172.16.4.111>;tag=95f7f5601f8b40458a1efe6923ab0a29 To: <sip:1008@172.16.4.111> Call-ID: f84b643f5d284d18a0d8175e1ef4d747 CSeq: 33264 REGISTER User-Agent: MicroSIP/3.21.6 sip:1008@172.16.80.3:49309;obExpires: 120 Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Content-Length: 0 Contact: <sip:1008@172.16.4.111:5461>;expires=120 ``` you can see the problem is that: `sip:1008@172.16.80.3:49309;obExpires: 120` , `sip:1008@172.16.80.3:49309` is the value of the Contact field after fix_nated_contact(). ### 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` ``` version: kamailio 5.8.5 (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_SEND_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: compiled on 11:27:01 Mar 21 2025 with gcc 4.8.5 ``` * **Operating System**:  ``` Centos7.9 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4190 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4190(a)github.com>

1 1

[kamailio/kamailio] dmq send dialog message failed (Issue #4189)
by QuincyGao 08 May '25

08 May '25

QuincyGao created an issue (kamailio/kamailio#4189)  ### Description  I used dmq on two machines, registered two softphones on the 111 machine, and then used one phone to call another. After the call was connected, dmq sent a dialog message with an error message 400 bad request. Here is the 111 config, 113 almost same to 111: ``` loadmodule "dmq.so" modparam("dmq", "server_address", "sip:172.16.4.111:5464") modparam("dmq", "server_socket", "udp:172.16.4.111:5464") modparam("dmq", "notification_address", "sip:172.16.4.113:5464") modparam("dmq", "notification_channel", "peers") modparam("dmq", "num_workers", 4) modparam("dmq", "ping_interval", 30) loadmodule "dmq_usrloc.so" modparam("dmq_usrloc", "enable", 1) modparam("dmq_usrloc", "sync", 1) modparam("dmq_usrloc", "batch_msg_contacts", 50) # 50 contacts / message modparam("dmq_usrloc", "batch_size", 10000) # 10000 contacts / batch modparam("dmq_usrloc", "batch_usleep", 500000) loadmodule "dialog.so" modparam("dialog", "enable_stats", 1) modparam("dialog", "enable_dmq", 1) ... if (is_method("INVITE")) { setflag(FLT_ACC); # do accounting dlg_manage(); } ``` Here is the sip: <img width="836" alt="Image" src="https://github.com/user-attachments/assets/df609e21-77bb-43e9-a8aa-112069a3…" /> the 113 log error: ``` dialog [dlg_dmq.c:127]: dlg_dmq_handle_msg(): no content length header found ``` ### Troubleshooting #### Reproduction  The inevitable bug #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` 113 log: 22(4389) DEBUG: <core> [core/udp_server.c:708]: udp_rcv_loop(): received on udp socket: (106/100/767) [[KDMQ sip:dialog@172.16.4.113:5464 SIP/2.0 0D 0A Via: SIP/2.0/UDP 172.16.4.111:5464;branch=z9hG4bK28e.2ec7]] 22(4389) DEBUG: <core> [core/receive.c:190]: ksr_evrt_received(): event route core:msg-received not defined 22(4389) DEBUG: <core> [core/parser/parse_fline.c:249]: parse_first_line(): first line type 1 (request) flags 1 22(4389) DEBUG: <core> [core/parser/msg_parser.c:722]: parse_msg(): SIP Request: 22(4389) DEBUG: <core> [core/parser/msg_parser.c:724]: parse_msg(): method: <KDMQ> 22(4389) DEBUG: <core> [core/parser/msg_parser.c:726]: parse_msg(): uri: <sip:dialog@172.16.4.113:5464> 22(4389) DEBUG: <core> [core/parser/msg_parser.c:728]: parse_msg(): version: <SIP/2.0> 22(4389) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [Via] type 1 22(4389) DEBUG: <core> [core/parser/parse_via.c:1312]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK28e.2ec78467000000000000000000000000.0>; state=16 22(4389) DEBUG: <core> [core/parser/parse_via.c:2663]: parse_via(): end of header reached, state=5 22(4389) DEBUG: <core> [core/parser/msg_parser.c:592]: parse_headers(): Via found, flags=2 22(4389) DEBUG: <core> [core/parser/msg_parser.c:594]: parse_headers(): this is the first via 22(4389) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [To] type 3 22(4389) DEBUG: <core> [core/parser/parse_addr_spec.c:904]: parse_addr_spec(): end of header reached, state=10 22(4389) DEBUG: <core> [core/parser/msg_parser.c:173]: get_hdr_field(): <To> [32]; uri=[sip:dialog@172.16.4.113:5464] 22(4389) DEBUG: <core> [core/parser/msg_parser.c:176]: get_hdr_field(): to body (32)[<sip:dialog@172.16.4.113:5464> ], to tag (0)[] 22(4389) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [From] type 4 22(4389) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [CSeq] type 5 22(4389) DEBUG: <core> [core/parser/msg_parser.c:154]: get_hdr_field(): cseq <CSeq>: <10> <KDMQ> 22(4389) DEBUG: <core> [core/parser/parse_hname2.c:316]: parse_sip_header_name(): parsed header name [Call-ID] type 6 22(4389) DEBUG: <core> [core/receive.c:397]: receive_msg(): --- received sip message - request - call-id: [6ecc0d71033645ea-1972(a)172.16.4.111] - cseq: [10 KDMQ] 22(4389) DEBUG: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| <core> [core/receive.c:263]: ksr_evrt_pre_routing(): event route core:pre-routing not defined 22(4389) DEBUG: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| <core> [core/receive.c:474]: receive_msg(): preparing to run routing scripts... 22(4389) exec: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=584 a=26 n=xlog 22(4389) INFO: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| <script>: 172.16.4.111:5464|172.16.4.113:5464|udp|KDMQ 22(4389) exec: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=592 a=16 n=if 22(4389) exec: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=589 a=25 n=is_method 22(4389) exec: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| *** cfgtrace:dbg_cfg_trace(): request_route=[DEFAULT_ROUTE] c=[/usr/local/bin/../etc/kamailio/conf/kamailio.cfg] l=590 a=24 n=dmq_process_message 22(4389) DEBUG: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| dmq [message.c:154]: ki_dmq_process_message_rc(): dmq_handle_message [KDMQ sip:dialog@172.16.4.113:5464] 22(4389) DEBUG: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| dmq [message.c:168]: ki_dmq_process_message_rc(): dmq_handle_message peer found: dialog 22(4389) DEBUG: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=6c399121368d030ed41b62758342ea91-0405b528 22(4389) DEBUG: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| <core> [core/parser/parse_addr_spec.c:904]: parse_addr_spec(): end of header reached, state=29 22(4389) DEBUG: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| dialog [dlg_dmq.c:124]: dlg_dmq_handle_msg(): dmq message received 22(4389) ERROR: |25-03-26 15:25:01|6ecc0d71033645ea-1972@172.16.4.111| dialog [dlg_dmq.c:127]: dlg_dmq_handle_msg(): no content length header found ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.8.5 (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_SEND_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: compiled on 11:27:01 Mar 21 2025 with gcc 4.8.5 ``` * **Operating System**:  ``` centos7.9 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4189 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4189(a)github.com>

1 2

[kamailio/kamailio] ims_diameter_server not freeing shared memory (Issue #4116)
by MGrimby 07 May '25

07 May '25

### Description I have run in to an issue when sending diameter requests using the ims_diameter_server module. Shared memory keeps increasing and are not being freed until restart of kamailio. This leads to all shared memory is being used and no more are able to be allocated. This only happens when the request is sent synchronously. When sent asynchronously shared memory is being freed as far as I can see. Following functions have been used for sending requests. diameter_request([peer], appid, commandcode, message) diameter_request_async([peer], appid, commandcode, message) ### Troubleshooting Sent a bunch of diameter requests and verified that shared memory for the following functions are not freed. do_receive(600): AAATranslateMessage(500): AAACreateAVP(137): #### Reproduction It's possible to reproduce by sending sync diameter request and verify shared memory. Example of diameter request block ``` route[CHECK_LOCATION] { diameter_request("hss.ims.test.local", "16777217", "306", "[ " + "{ \"avpCode\":260, \"vendorId\":0, \"Flags\":64, \"list\":[ { \"avpCode\":266, \"vendorId\":0, \"Flags\":64, \"int32\":10415 }, { \"avpCode\":258, \"vendorId\":0, \"Flags\":64, \"int32\":16777217 } ] }, " + "{ \"avpCode\":277, \"vendorId\":0, \"Flags\":64, \"int32\":1 }, " + "{ \"avpCode\":283, \"vendorId\":0, \"Flags\":64, \"string\":\"ims.test.local\"}, " + "{ \"avpCode\":706, \"vendorId\":10415, \"Flags\":192, \"int32\":0 }, " + "{ \"avpCode\":700, \"vendorId\":10415, \"Flags\":192, \"list\": [ { \"avpCode\":601, \"vendorId\":10415, \"Flags\":192, \"string\":\"tel:" + $fU + "\" }]}, " + "{ \"avpCode\":707, \"vendorId\":10415, \"Flags\":192, \"int32\":0 }, " + "{ \"avpCode\":703, \"vendorId\":10415, \"Flags\":192, \"int32\":14 } ]"); xlog("L_INFO", "Sent Diameter request"); } ``` Stats cdp:replies_received = 343310 shmem:fragments = 142 shmem:free_size = 1221489992 shmem:max_used_size = 948242168 shmem:real_used_size = 925993656 shmem:total_size = 2147483648 shmem:used_size = 558205656 kamcmd mod.stats cdp shm do_receive(600): 256245808 AAATranslateMessage(500): 64420712 AAACreateAVP(137): 218100320 Total: 538774000 #### 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` ``` version: kamailio 5.7.4 (x86_64/linux) dc393e 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: dc393e compiled on 13:56:27 Feb 27 2024 with gcc 8.5.0 ``` * **Operating System**:  ``` Linux bmatkamas1 4.18.0-553.16.1.el8_10.x86_64 #1 SMP Thu Aug 1 04:16:12 EDT 2024 x86_64 x86_64 x86_64 GNU/Linux Red Hat Enterprise Linux release 8.10 (Ootpa) ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4116 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4116(a)github.com>

4 5

[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] Memory usage increases everytime tls.reload is executed (Issue #3823)
by Sebastian Denz 06 May '25

06 May '25

### Description We are using Kamailio 5.7.4 on Debian 12 (from http://deb.kamailio.org/kamailio57) with rtpengine as an Edgeproxy for our clients. The instance terminates SIP/TLS (with Cliencertificates) and forwards the SIP Traffic to internal systems. After some days we are getting errors like this `tls_complete_init(): tls: ssl bug #1491 workaround: not enough memory for safe operation: shm=7318616 threshold1=8912896` First we thought Kamailio just doesnt have enough memory, so we doubled it.. But after some days the Logmessage (and Userissues) occured again. So we monitored the shmmem statistics and found that used and max_used are constantly growing til it reaches the limit. As i mentioned we are using client-certificates and so we are also using the CRL feature. We do have a systemd-timer which fetches the CRL every hour and runs 'kamcmd tls.reload' when finished. Our tls.cfg looks like this: ``` [server:default] method = TLSv1.2+ private_key = /etc/letsencrypt/live/hostname.de/privkey.pem certificate = /etc/letsencrypt/live/hostname.de/fullchain.pem ca_list = /etc/kamailio/ca_list.pem ca_path = /etc/kamailio/ca_list.pem crl = /etc/kamailio/combined.crl.pem verify_certificate = yes require_certificate = yes [client:default] verify_certificate = yes require_certificate = yes ``` After testing a bit we found that every time tls.reload is executed Kamailio consumes a bit more memory which eventually leads to all the memory being consumed which leads to issues for our users. See following example: ``` [0][root@edgar-dev:~]# while true ; do /usr/sbin/kamcmd tls.reload ; /usr/sbin/kamcmd core.shmmem ; sleep 1 ; done Ok. TLS configuration reloaded. { total: 268435456 free: 223001520 used: 41352552 real_used: 45433936 max_used: 45445968 fragments: 73 } Ok. TLS configuration reloaded. { total: 268435456 free: 222377960 used: 41975592 real_used: 46057496 max_used: 46069232 fragments: 78 } Ok. TLS configuration reloaded. { total: 268435456 free: 221748664 used: 42604992 real_used: 46686792 max_used: 46698080 fragments: 77 } Ok. TLS configuration reloaded. { total: 268435456 free: 221110832 used: 43242408 real_used: 47324624 max_used: 47335608 fragments: 81 } ^C [130][root@edgar-dev:~]# ``` ### Troubleshooting #### Reproduction Everytime tls.reload is called the memory consumptions grows.. #### Debugging Data  ``` If you let me know what would be interesting for tracking this down, i am happy to provide logs/debugging data! ``` #### Log Messages  ``` If you let me know what would be interesting for tracking this down, i am happy to provide logs/debugging data! ``` #### SIP Traffic SIP doesnt seem to be relevant here ### Possible Solutions Calling tls.reload less often or restart kamailio before memory is consumed ;) ### Additional Information ``` 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**: ``` * Debian GNU/Linux 12 (bookworm) * Linux edgar-dev 6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11) x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3823 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3823(a)github.com>

9 31

[kamailio/kamailio] cmake format options and naming styles (Issue #4075)
by Daniel-Constantin Mierla 06 May '25

06 May '25

Discussion to define cmake format options and coding/naming styles. It is better to define most of them now to have coherency in the future. Started from the discussion on #4066. Comment with what you would like to have, describing when useful why your proposal is a good/better option. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4075 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4075(a)github.com>

5 9

[kamailio/kamailio] ims_dialog: missing srdb1 schema definition (Issue #4100)
by Victor Seva 06 May '25

06 May '25

there's no ``kamailio-ims_dialog.xml`` at ``src/lib/srdb1/schema`` but there's a manual file created at ``utils/kamctl/mysql/ims_dialog-create.sql`` Same thing for: - ``utils/kamctl/mysql/ims_charging-create.sql`` - ``utils/kamctl/mysql/ims_usrloc_pcscf-create.sql`` - ``utils/kamctl/mysql/ims_usrloc_scscf-create.sql`` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4100 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4100(a)github.com>

3 8

[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] Crash involving rtpengine (Issue #4179)
by Joe Mordica 28 Apr '25

28 Apr '25

jmordica created an issue (kamailio/kamailio#4179) ### Description Kamailio crash involving rtpengine ### Troubleshooting #### Reproduction  #### Debugging Data  ``` GNU gdb (Debian 13.1-3) 13.1 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/sbin/kamailio... Reading symbols from /usr/lib/debug/.build-id/20/dc8be8c0aa02eba62b84db3c283789f068fb79.debug... warning: Can't open file /dev/zero (deleted) during file-backed mapping note processing [New LWP 37] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `kamailio -DD -E -m 8000 -M 512 -f /etc/kamailio/kamailio.cfg -P /var/run/kamail'. Program terminated with signal SIGABRT, Aborted. #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 44 ./nptl/pthread_kill.c: No such file or directory. (gdb) bt full #0 __pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44 tid = <optimized out> ret = 0 pd = <optimized out> old_mask = {__val = {0}} ret = <optimized out> #1 0x00007f0a2dd31f1f in __pthread_kill_internal (signo=6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78 No locals. #2 0x00007f0a2dce2fb2 in __GI_raise (sig=sig@entry=6) at ../sysdeps/posix/raise.c:26 ret = <optimized out> #3 0x00007f0a2dccd472 in __GI_abort () at ./stdlib/abort.c:79 save_stage = 1 act = {__sigaction_handler = {sa_handler = 0x20, sa_sigaction = 0x20}, sa_mask = {__val = {1880844493789993498, 1880844493789993498, 1880844493789993498, 0, 0, 0, 0, 2314885530818453536, 2314885530818453536, 2314885530818453536, 2314885530818453536, 0, 0, 0, 0, 94814674008008}}, sa_flags = 365707264, sa_restorer = 0x563bc3029320 <log_prefix_buf>} #4 0x0000563bc2e27414 in qm_debug_check_frag (qm=qm@entry=0x7f0815cc4000, f=f@entry=0x7f0834533950, file=file@entry=0x7f0a0a93420f "rtpengine: rtpengine_hash.c", line=line@entry=528, eline=eline@entry=546, efile=0x563bc2f6abcc "core/mem/q_malloc.c") at core/mem/q_malloc.c:132 p = <optimized out> __func__ = "qm_debug_check_frag" #5 0x0000563bc2e282b9 in qm_free (qmp=<optimized out>, p=0x7f0834533990, file=0x7f0a0a93420f "rtpengine: rtpengine_hash.c", func=0x7f0a0a935040 <__func__.2> "rtpengine_hash_table_free_entry", line=528, mname=0x7f0a0a92a000 "rtpengine") at core/mem/q_malloc.c:546 qm = <optimized out> f = 0x7f0834533950 size = <optimized out> next = <optimized out> prev = <optimized out> __func__ = "qm_free" #6 0x0000563bc2e2d51f in qm_shm_free (qmp=<optimized out>, p=0x7f0834533990, file=0x7f0a0a93420f "rtpengine: rtpengine_hash.c", func=0x7f0a0a935040 <__func__.2> "rtpengine_hash_table_free_entry", line=528, mname=0x7f0a0a92a000 "rtpengine") at core/mem/q_malloc.c:1532 No locals. #7 0x00007f0a0a922adb in rtpengine_hash_table_free_entry (entry=0x7f08263a3f80) at ./src/modules/rtpengine/rtpengine_hash.c:528 __func__ = "rtpengine_hash_table_free_entry" --Type <RET> for more, q to quit, c to continue without paging--info locals #8 0x00007f0a0a927dd4 in rtpengine_hash_table_lookup (callid=..., viabranch=..., op=op@entry=OP_OFFER) at ./src/modules/rtpengine/rtpengine_hash.c:428 entry = 0x7f08263a3f80 last_entry = 0x7f08174e0450 hash_index = 87 node = <optimized out> __func__ = "rtpengine_hash_table_lookup" #9 0x00007f0a0a90ec2b in select_rtpp_node_old (do_test=1, op=OP_OFFER, viabranch=..., callid=...) at ./src/modules/rtpengine/rtpengine.c:3810 node = 0x0 node = <optimized out> __func__ = "select_rtpp_node_old" __llevel = <optimized out> __kld = <optimized out> __llevel = <optimized out> __kld = <optimized out> #10 select_rtpp_node (callid=..., viabranch=..., queried_nodes_list=0x7f0a0de84430, queried_nodes=queried_nodes@entry=0, op=OP_OFFER, do_test=1) at ./src/modules/rtpengine/rtpengine.c:3864 node = 0x0 __func__ = "select_rtpp_node" #11 0x00007f0a0a91228a in rtpp_function_call (bencbuf=bencbuf@entry=0x7ffeb1d5bea0, msg=msg@entry=0x7f0a0de94350, op=<optimized out>, flags_str=<optimized out>, body_out=body_out@entry=0x7ffeb1d5be80, cl_field=cl_field@entry=0x7ffeb1d5be90) at ./src/modules/rtpengine/rtpengine.c:3178 ng_flags = {via = -1, to = 1, packetize = 0, transport = 256, directional = 0, dict = 0x7f0a0de98b78, flags = 0x7f0a0de98d08, direction = 0x7f0a0de98e68, replace = 0x7f0a0de98ec8, rtcp_mux = 0x7f0a0de98f28, sdes = 0x7f0a0de98f88, t38 = 0x7f0a0de99098, received_from = 0x7f0a0de98e08, codec = 0x7f0a0de990f8, codec_strip = 0x0, codec_offer = 0x0, codec_transcode = 0x0, codec_mask = 0x0, codec_set = 0x0, codec_except = 0x0, codec_accept = 0x0, codec_consume = 0x0, call_id = { s = 0x563bc30e195f <buf+287> "5783b150-6ad4-4e55-9555-decf4048c8fb\r\nCSeq: 23471 INVITE\r\nAllow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, INFO, REFER\r\nk: replaces, histinfo\r\nX-UNIQUEI"..., len = 36}, from_tag = { s = 0x563bc30e18fb <buf+187> "47d9d572-1f09-46bf-b966-16988c17cf56\r\nt: <sip:02-5333@10.142.0.56>\r\nm: <sip:vxm@10.52.7.2:5081>\r\ni: 5783b150-6ad4-4e55-9555-decf4048c8fb\r\nCSeq: 23471 INVITE\r\nAllow: OPTIONS, REGISTER, SUBSCRIBE, NOTIF"..., len = 36}, to_tag = {s = 0x0, len = 0}} item = <optimized out> resp = <optimized out> viabranch = {s = 0x7f0a0dd15720 "z9hG4bKPje1c3efee-2490-4035-9e2e-b124ec630b820", len = 46} body = { s = 0x563bc30e1b33 <buf+755> "v=0\r\no=- 1936793669 1936793669 IN IP4 10.52.7.2\r\ns=VXM\r\nc=IN IP4 10.52.7.2\r\nt=0 0\r\nm=audio 18690 RTP/AVP 0 101\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101 0-16\r\na=ptime:20\r\na=maxptime:140\r\na=sendre"..., len = 204} --Type <RET> for more, q to quit, c to continue without paging--list error = <optimized out> ret = 1 queried_nodes = 0 cont_type = <optimized out> node = <optimized out> cp = <optimized out> pv_val = {rs = {s = 0x7f083a53d3c0 "p", len = -1025336010}, ri = 47244640256, flags = 1} md5 = "\004\220\361\302;V\000\000\260r\366\302;V", '\000' <repeats 11 times>, "\345\323A\270\253\205\301" branch_buf = "\210\033\016\303;V\000\000\177W\315\302;V\000\000\216\033\016\303;V\000\000\000\345\323A\270\253\205\301\224\033\016\303;V\000\000\000\345\323A\270\253\205\301\220\201\351\r\n\177\000\000\000\345" result = <optimized out> t = <optimized out> branch_idx = <optimized out> __func__ = "rtpp_function_call" select_node = <optimized out> #12 0x00007f0a0a917346 in rtpp_function_call_ok (bencbuf=bencbuf@entry=0x7ffeb1d5bea0, msg=msg@entry=0x7f0a0de94350, op=<optimized out>, flags_str=<optimized out>, body=body@entry=0x7ffeb1d5be80, cl_field=cl_field@entry=0x7ffeb1d5be90) at ./src/modules/rtpengine/rtpengine.c:3371 ret = <optimized out> __func__ = "rtpp_function_call_ok" #13 0x00007f0a0a919708 in rtpengine_offer_answer (msg=0x7f0a0de94350, flags=<optimized out>, op=<optimized out>, more=0) at ./src/modules/rtpengine/rtpengine.c:4495 bencbuf = {pieces = 0x7f0a0de9a270, free_list = 0x0, error = 0} dict = <optimized out> body = {s = 0x7f0a0de94350 "\233@\006", len = 1104405760} newbody = <optimized out> anchor = <optimized out> pv_val = {rs = {s = 0x0, len = 177318755}, ri = 0, flags = 4} cur_body = {s = 0x0, len = 0} cl_field = {s = 0x0, len = 0} cl_repl = {s = 0x0, len = 0} __func__ = "rtpengine_offer_answer" error_free = <optimized out> #14 0x0000563bc2c77195 in sr_kemi_exec_func (ket=ket@entry=0x7f0a0a93d5c8 <sr_kemi_rtpengine_exports+72>, msg=<optimized out>, pno=pno@entry=1, vps=<optimized out>) at core/kemiexec.c:84 ``` #### Log Messages  ``` CRITICAL: {1 23471 INVITE 5783b150-6ad4-4e55-9555-decf4048c8fb} <core> [core/mem/q_malloc.c:148]: qm_debug_check_frag(): BUG: qm: prev. fragm. tail overwritten(c0c00a0d, abcdefed)[0x7f0834533950:0x7f0834533990]! Memory allocator was called from rtpengine: rtpengine_hash.c:528. Fragment marked by rtpengine: ../../core/parser/../ut.h:891. Exec from core/mem/q_malloc.c:546. CRITICAL: {1 23471 INVITE 5783b150-6ad4-4e55-9555-decf4048c8fb} <core> [core/mem/q_malloc.c:156]: qm_debug_check_frag(): BUG: qm: prev. fragm. tail overwritten [0x7f08345335b0:0x7f08345335f0] - fragment marked by core: core/msg_translator.c:2305 ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.8.5 (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_SEND_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 gke-us-east1-external-sip-4b67daea-x3rj 5.15.0-1020-gke #25-Ubuntu SMP Thu Oct 27 05:38:18 UTC 2022 x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4179 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4179(a)github.com>

4 8

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