sr-dev January 2025

sr-dev@lists.kamailio.org

21 participants
294 discussions

[kamailio/kamailio] Handling Duplicate Values in secfilter Module's kamcmd Commands (Issue #4091)
by AsedMorteza 13 Mar '25

13 Mar '25

**Description** The `secfilter` module in `kamcmd` currently allows duplicate entries when adding values to certain lists (e.g., blacklists, whitelists). This can lead to unexpected behavior and potential inconsistencies. Could you clarify the reason behind accepting duplicate values? Recently, I submitted a pull request to add delete commands to the `secfilter` module #4089. When a user, for example, executes: `kamcmd secfilter.del_bl user 1005` I iterate through the entire list to ensure all occurrences of `1005` are removed, as I realized duplicates might exist. This is inefficient and could be avoided by preventing duplicates in the first place. **Proposed Solutions** 1. **Prevent Duplicates in Existing `add` Commands:** * I can modify existing `add` commands to directly prevent the addition of duplicate values. This would simplify future operations and improve performance. 2. **Introduce New `add_unique` Commands:** * I can maintain the current `add` commands for backward compatibility. * I can introduce new `add_unique` commands (e.g., `secfilter.add_bl_unique`) that explicitly reject duplicate entries. **Recommendation** I recommend implementing the first solution (preventing duplicates in existing `add` commands) as it provides the most straightforward and efficient approach. **Further Considerations** * Consider adding a check for duplicates during the `add` operation and returning an appropriate error message if a duplicate is encountered. * Document the behavior of duplicate values in the `secfilter` module's documentation. **I would appreciate your feedback and guidance on the best course of action.** -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4091 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4091(a)github.com>

4 4

[kamailio/kamailio] Failure in building db_sqlite and db_unixodbc in Alpine 3.21 (Issue #4121)
by Ben Kaufman 11 Mar '25

11 Mar '25

4 6

[kamailio/kamailio] topos: add enable_register_publish (PR #3766)
by Harish S 09 Mar '25

09 Mar '25

Added enable_register_publish parameter to enable REGISTER and PUBLISH method for topos If set to 1 REGISTER and PUBLISH will be enabled for topos Currently only via header will be applied for topos and if mask_callid is set to 1 call-ID will be masked. Other headers should be manged by the user as required.   #### 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) - [ ] 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  You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3766 -- Commit Summary -- * add enable_register_publish -- File Changes -- M src/modules/topos/topos_mod.c (2) M src/modules/topos/tps_msg.c (132) M src/modules/topos/tps_msg.h (2) M src/modules/topos/tps_storage.c (6) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3766.patch https://github.com/kamailio/kamailio/pull/3766.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3766 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3766(a)github.com>

5 39

[kamailio/kamailio] topos:added get_callid_mask/get_callid_unmask funtion for handeling Refer-To header (PR #3872)
by Harish S 09 Mar '25

09 Mar '25

Topos: Added get_callid_mask functin which will give the masked callID if actual callID is given and get_callid_unmask function which will unmask the given call-ID. This funtion is useful when the client sends a refer methord with refer-to header containing call-id  #### 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 - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3872 -- Commit Summary -- * add funtion to mask/unmask callID * get_callid_mask /get_callid_unmask Document Update -- File Changes -- M src/modules/topos/doc/topos_admin.xml (87) M src/modules/topos/topos_mod.c (183) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3872.patch https://github.com/kamailio/kamailio/pull/3872.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3872 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3872(a)github.com>

4 12

[kamailio/kamailio] In function ksr_tm_event_response_sent(evname), header and body modifications are not applied (Issue #3997)
by JuanPascual2 05 Mar '25

05 Mar '25

Hello In the function ksr_tm_event_response_sent(evname), header and body modifications are not applied. **Example of modification:** KSR.textops.set_body("application/test", "teststbody") KSR.textops.remove_hf("Contact") KSR.hdr.append("X-My-Hdr: testhdrappend \r\n") In the Kamailio logs, we can see that the changes have been processed, but the response sent does not contain the changes. BR Juan **Configuration kamailio.cfg** modparam("tm", "event_callback_lres_sent", "ksr_tm_event_response_sent") **Configuration kamailio.lua** ----------------------- --Function ksr_tm_event_response_sent bug ----------------------- function ksr_tm_event_response_sent(evname) log.debug("\27[36m --> Sending reply: $rs $rr \27[0m") log.debug("\27[35m Reply sent ",evname,"\27[0m") KSR.textops.set_body("application/test", "teststbody") KSR.textops.remove_hf("Contact") KSR.hdr.append("X-My-Hdr: testhdrappend \r\n") end **Traces debug KAMAILIO** 4(260) DEBUG: app_lua [app_lua_api.c:1023]: sr_kemi_lua_exec_func_ex(): param[0] for: xinfo is str: 2024-10-10 10-18-10 [debug] /opt/kamailio/kamailio.lua:96: --> Sending reply: $rs $rr 4(260) DEBUG: <core> [core/pvapi.c:502]: pv_spec_lookup(): PV <$rs> is not in cache 4(260) DEBUG: <core> [core/pvapi.c:386]: pv_cache_add(): pvar [$rs] added in cache 4(260) DEBUG: <core> [core/pvapi.c:502]: pv_spec_lookup(): PV <$rr> is not in cache 4(260) DEBUG: <core> [core/pvapi.c:386]: pv_cache_add(): pvar [$rr] added in cache 4(260) INFO: <script>: 2024-10-10 10-18-10 [debug] /opt/kamailio/kamailio.lua:96: --> Sending reply: 200 OK 4(260) DEBUG: app_lua [app_lua_api.c:1023]: sr_kemi_lua_exec_func_ex(): param[0] for: xinfo is str: 2024-10-10 10-18-10 [debug] /opt/kamailio/kamailio.lua:97: Reply sent tm:local-response-sent 4(260) INFO: <script>: 2024-10-10 10-18-10 [debug] /opt/kamailio/kamailio.lua:97: Reply sent tm:local-response-sent 4(260) DEBUG: app_lua [app_lua_api.c:1023]: sr_kemi_lua_exec_func_ex(): param[0] for: set_body is str: application/test 4(260) DEBUG: app_lua [app_lua_api.c:1023]: sr_kemi_lua_exec_func_ex(): param[1] for: set_body is str: teststbody 4(260) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name(): parsed header name [To] type 3 4(260) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=bb3c24ed793eec883784ff522b4e48d0 4(260) DEBUG: <core> [core/parser/parse_addr_spec.c:904]: parse_addr_spec(): end of header reached, state=29 4(260) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): <To> [61]; uri=[sip:1234@sip.osp.com] 4(260) DEBUG: <core> [core/parser/msg_parser.c:174]: get_hdr_field(): to body (22)[<sip:1234@sip.osp.com>], to tag (32)[bb3c24ed793eec883784ff522b4e48d0] 4(260) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name(): parsed header name [From] type 4 4(260) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name(): parsed header name [CSeq] type 5 4(260) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <63723> <REGISTER> 4(260) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name(): parsed header name [Call-ID] type 6 4(260) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name(): parsed header name [Content-Type] type 11 4(260) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name(): parsed header name [Contact] type 7 4(260) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name(): parsed header name [Content-Length] type 12 4(260) DEBUG: <core> [core/parser/msg_parser.c:187]: get_hdr_field(): content_length=6 4(260) DEBUG: <core> [core/parser/msg_parser.c:91]: get_hdr_field(): found end of header 4(260) DEBUG: textops [textops.c:2597]: ki_set_body(): new body: [application/test] 4(260) DEBUG: app_lua [app_lua_api.c:1023]: sr_kemi_lua_exec_func_ex(): param[0] for: remove_hf is str: Contact 4(260) DEBUG: <core> [core/parser/parse_hname2.c:315]: parse_sip_header_name(): parsed header name [Contact] type 7 4(260) DEBUG: <core> [core/kemi.c:2350]: sr_kemi_hdr_remove(): remove hf: Contact 4(260) DEBUG: app_lua [app_lua_api.c:1023]: sr_kemi_lua_exec_func_ex(): param[0] for: append is str: X-My-Hdr: testhdrappend 4(260) DEBUG: <core> [core/kemi.c:2224]: sr_kemi_hdr_append(): append hf: X-My-Hdr: testhdrappend 4(260) DEBUG: app_lua [app_lua_mod.c:166]: sr_kemi_config_engine_lua(): execution of route type 513 with name [ksr_tm_event_response_sent] returned 1 4(260) DEBUG: tm [t_reply.c:634]: _reply_light(): reply sent out - buf=0x786b611bb9e0: SIP/2.0 200 OK Via:... shmem=0x786b58ceea80: SIP/2.0 200 OK Via: 4(260) DEBUG: tm [t_funcs.c:133]: put_on_wait(): put T [0x786b58ceb770] on wait 4(260) DEBUG: tm [t_reply.c:650]: _reply_light(): finished 4(260) DEBUG: jsonrpcs [jsonrpcs_mod.c:443]: jsonrpc_send_mode(): sending response with body: (nil) - 200 OK 4(260) DEBUG: app_lua [app_lua_api.c:1023]: sr_kemi_lua_exec_func_ex(): param[0] for: xinfo is str: 2024-10-10 10-18-10 [debug] /opt/kamailio/kamailio.lua:36: ksr_request_route: 23.11 ms 4(260) INFO: <script>: 2024-10-10 10-18-10 [debug] /opt/kamailio/kamailio.lua:36: ksr_request_route: 23.11 ms 4(260) DEBUG: app_lua [app_lua_mod.c:169]: sr_kemi_config_engine_lua(): execution of route type 1 with no name returned 1 4(260) DEBUG: <core> [core/receive.c:531]: receive_msg(): request-route executed in: 23343 usec 4(260) DEBUG: <core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil) 4(260) DEBUG: <core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil) 4(260) DEBUG: <core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil) 4(260) DEBUG: <core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil) 4(260) DEBUG: <core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil) 4(260) DEBUG: <core> [core/usr_avp.c:654]: destroy_avp_list(): destroying list (nil) 4(260) DEBUG: <core> [core/xavp.c:630]: xavp_destroy_list(): destroying xavp list (nil) 4(260) DEBUG: <core> [core/xavp.c:630]: xavp_destroy_list(): destroying xavp list (nil) 4(260) DEBUG: <core> [core/xavp.c:630]: xavp_destroy_list(): destroying xavp list (nil) 4(260) DEBUG: <core> [core/receive.c:635]: receive_msg(): cleaning up 18(274) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x786b58ce81a0 (p:0x786b58baa3c0/n:0x786b58baa3c0) 18(274) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x786b58ce81a0 from timer.c:651 18(274) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x786b58ceb770 (p:0x786b58b729c0/n:0x786b58b729c0) 18(274) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x786b58ceb770 from timer.c:651 -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3997 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3997(a)github.com>

4 8

[kamailio/kamailio] dispatcher module usage on kamailio 5.8.4 generate kamailio crash (Issue #4061)
by pgravet 05 Mar '25

05 Mar '25

### Description kamailio crash with signal 6 ### Troubleshooting #### Reproduction After each couple of dispatcher ping interval. #### Debugging Data No core dump file. #### Log Messages Dec 6 17:47:24 frnappcoe3router2 /usr/sbin/kamailio[1618]: INFO: ctl [io_listener.c:211]: io_listen_loop(): using epoll_lt as the io watch method (auto detected) Dec 6 17:47:34 frnappcoe3router2 /usr/sbin/kamailio[1614]: NOTICE: <script>: tm:local-request called OPTIONS to <sip:frnappcoe3sfl05.orange-voicemail.net:5060> Dec 6 17:47:34 frnappcoe3router2 /usr/sbin/kamailio[1614]: NOTICE: <script>: tm:local-request called OPTIONS to <sip:cs1-tool-misc.orange-voicemail.net:5060> Dec 6 17:47:44 frnappcoe3router2 /usr/sbin/kamailio[1614]: NOTICE: <script>: tm:local-request called OPTIONS to <sip:frnappcoe3sfl05.orange-voicemail.net:5060> Dec 6 17:47:44 frnappcoe3router2 /usr/sbin/kamailio[1614]: NOTICE: <script>: tm:local-request called OPTIONS to <sip:cs1-tool-misc.orange-voicemail.net:5060> Dec 6 17:47:44 frnappcoe3router2 /usr/sbin/kamailio[1608]: CRITICAL: <core> [core/mem/q_malloc.c:555]: qm_free(): BUG: freeing already freed pointer (0x7f178fa8a700), called from core: core/xavp.c: xavp_free(81), first free core: core/xavp.c: xavp_new_value(117) - ignoring Dec 6 17:47:44 frnappcoe3router2 /usr/sbin/kamailio[1608]: CRITICAL: <core> [core/mem/q_malloc.c:136]: qm_debug_check_frag(): BUG: qm: fragm. 0x7f178fa8a560 (address 0x7f178fa8a5a0) end overwritten (0, f00000000000)! Memory allocator was called from core: core/xavp.c:81. Fragment marked by (null):2882400237. Exec from core/mem/q_malloc.c:546. Dec 6 17:47:44 frnappcoe3router2 /usr/sbin/kamailio[1604]: ALERT: <core> [main.c:805]: handle_sigs(): child process 1608 exited by a signal 6 Dec 6 17:47:44 frnappcoe3router2 /usr/sbin/kamailio[1604]: ALERT: <core> [main.c:809]: handle_sigs(): core was not generated Dec 6 17:47:44 frnappcoe3router2 /usr/sbin/kamailio[1604]: INFO: <core> [main.c:832]: handle_sigs(): terminating due to SIGCHLD #### SIP Traffic ### Possible Solutions ### Additional Information [root@frnappcoe3router2 ~]# kamailio -v version: kamailio 5.8.4 (x86_64/linux) f1d83d 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: f1d83d compiled on 13:59:57 Nov 12 2024 with gcc 8.5.0 kamailio.cfg loadmodule "dispatcher.so" modparam("dispatcher", "list_file", DISPATCHER_FILE) modparam("dispatcher", "ds_probing_mode", 1) modparam("dispatcher", "ds_probing_threshold",3) modparam("dispatcher", "flags", 3) modparam("dispatcher", "ds_ping_from", "sip:siprouter@unisys.com") modparam("dispatcher", "xavp_dst", "_dsdst_") modparam("dispatcher", "xavp_ctx", "_dsctx_") modparam("dispatcher", "ds_hash_size", 8) modparam("dispatcher", "ds_ping_interval", 10) modparam("dispatcher", "ds_ping_reply_codes", "class=2;class=3") * **Operating System**: RHEL8.8 -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4061 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4061(a)github.com>

5 11

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

01 Mar '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>

3 2

[kamailio/kamailio] Module snmpstats reporting inconsistent call success metrics on intense peaks of failed calls (Issue #4006)
by igorpotjevlesh 28 Feb '25

28 Feb '25

### Description We are plotting the call success rate on each of our proxies. Using the Kamailio snmpstats module, we try to obtain three counters in order to plot them on a graph: - Total Calls - Active Calls - Error Calls Most of the time, everything works well and we obtain sensible values: `snmpwalk -c mycommunity -v 2c W.X.Y.Z 1.3.6.1.4.1.34352.3.1.3.1.3.2 -O n` > .1.3.6.1.4.1.34352.3.1.3.1.3.2.1.0 = Gauge32: 309 -> Total Calls .1.3.6.1.4.1.34352.3.1.3.1.3.2.2.0 = Gauge32: 95 -> Active Calls .1.3.6.1.4.1.34352.3.1.3.1.3.2.3.0 = Gauge32: 214 -> Error calls However, **when our proxies are facing intense peaks of failed calls in a short timespan**, sometimes, the **"Error Calls"** counter returns a value **higher than "Total Calls"**. As a result, **"Active Calls"** suddenly reaches a value close to the **maximum of a _Gauge32_** (because ${TotalCalls} - {ErrorCalls} < 0$). `snmpwalk -c mycommunity -v 2c W.X.Y.Z 1.3.6.1.4.1.34352.3.1.3.1.3.2 -O n` > .1.3.6.1.4.1.34352.3.1.3.1.3.2.1.0 = Gauge32: 153 -> Total Calls .1.3.6.1.4.1.34352.3.1.3.1.3.2.2.0 = Gauge32: 4294967226 -> Active Calls .1.3.6.1.4.1.34352.3.1.3.1.3.2.3.0 = Gauge32: 223 -> Error calls As a result, our graphs make no more sense. ### Troubleshooting There seems to be a bug causing Total calls to be lower than Error calls when a high number of failed calls are received in a short time window. Moreover, there is an integer overflow resulting to the negative result of the substraction being converted to a _Gauge32_. Maybe setting it to 0 in case of a negative result would be safer ? #### Reproduction Using the following configuration for the snmpstats module of your Kamailio proxy: ``` # -------- snmpstats params ------- modparam("snmpstats", "snmpgetPath", "/usr/bin/") modparam("snmpstats", "snmpCommunity", "mycommunity") modparam("snmpstats", "sipEntityType", "proxyServer") ``` On intense peaks of failed calls, get the call success metrics using `snmpwalk` : `snmpwalk -c mycommunity -v 2c W.X.Y.Z 1.3.6.1.4.1.34352.3.1.3.1.3.2 -O n` > .1.3.6.1.4.1.34352.3.1.3.1.3.2.1.0 = Gauge32: 153 -> Total Calls .1.3.6.1.4.1.34352.3.1.3.1.3.2.2.0 = Gauge32: 4294967226 -> Active Calls .1.3.6.1.4.1.34352.3.1.3.1.3.2.3.0 = Gauge32: 223-> Error calls ### Additional Information **Kamailio Version**: `kamailio -v` > version: kamailio 5.6.4 (x86_64/linux) a004cf 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_S R_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, U SE_NAPTR, USE_DST_BLOCKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS 1024, MAX_RECV_BUFFER_SIZE 262144, MAX_URI_SIZE 1024, BUF_SI ZE 65535, DEFAULT PKG_SIZE 64MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: a004cf compiled on 16:10:41 May 22 2023 with gcc 4.4.7 * **Operating System**: `uname -r` > 2.6.32-279.el6.x86_64 `lsb_release -a` > LSB Version: :core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch Distributor ID: RedHatEnterpriseServer Description: Red Hat Enterprise Linux Server release 6.3 (Santiago) Release: 6.3 Codename: Santiago -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4006 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4006(a)github.com>

2 5

[kamailio/kamailio] Wrong Route header order in called party re-INVITE when using topos (Issue #3778)
by Javi Montoro 24 Feb '25

24 Feb '25

Hi There, We found a situation where topos seems to break, let me explain... Assuming the following scenario: ``` Caller ---- Callee A: ------INVITE-----> Record-Route:A.A.A.A, Record-Route:B.B.B.B B: <-----200 OK------ C: <-----INVITE------ Route: A.A.A.A, B.B.B.B D: ------200 OK-----> Record-Route:B.B.B.B, Record-Route:A.A.A.A (reversed order) E: <======INVITE===== Route: B.B.B.B, A.A.A.A (wrong) ``` A and B establish the connection from caller to callee, and topos works fine. C (re-INVITE from callee) sends the Route header according to the Record-Routes from the original INVITE (A) D is the 200 OK sent from the caller to the first re-INVITE (C) coming from the callee, with the Record-Route headers reversed, because is the order in which the callee received them; and according to the RFC it's working as intended: ``` When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response (including the URIs, URI parameters, and any Record-Route header field parameters, whether they are known or unknown to the UAS) and MUST maintain the order of those values. [...] [When a UAC receives a response...] The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. ``` E takes the Route order from the last 200 OK ignoring they are in reversed order and assuming the top one is the first one, when it should be the other way around, sending to an IP address not reachable from the callee. And I think here is the issue, topos should not update the path on the Record-Routes from a 200 OK but if it does, it should take the reverse order When disabling topos, everything works fine, or with topos enabled, by setting rr_update=0 works for us, but what if there is a real path update, rr_update=0 wouldn't work for us anymore. The Kamailio version is 5.8.0-rc0 Let me know if you need more information. Thanks a lot, Javi -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/3778 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/3778(a)github.com>

5 16

[kamailio/kamailio] dmq and dmq_usrloc additions (PR #4134)
by Stefan Mititelu 21 Feb '25

21 Feb '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 - [ ] 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 - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  Add new api function to dmq to get local socket. Use that in dmq_usrloc. Sync dmq_usrloc UL_CONTACT_EXPIRE. Very useful for lost TCP connections, so contacts will be expired on all dmq nodes. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4134 -- Commit Summary -- * dmq: add new api function * dmq_usrloc: new value for replicate_socket_info * dmq_usrloc: add new modparam to sync UL_CONTACT_EXPIRE actions -- File Changes -- M src/modules/dmq/bind_dmq.c (1) M src/modules/dmq/bind_dmq.h (2) M src/modules/dmq/dmq_funcs.c (5) M src/modules/dmq/dmq_funcs.h (1) M src/modules/dmq_usrloc/dmq_usrloc.c (3) M src/modules/dmq_usrloc/doc/dmq_usrloc_admin.xml (26) M src/modules/dmq_usrloc/usrloc_sync.c (22) M src/modules/dmq_usrloc/usrloc_sync.h (1) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4134.patch https://github.com/kamailio/kamailio/pull/4134.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4134 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4134(a)github.com>

2 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev January 2025