sr-dev December 2024

sr-dev@lists.kamailio.org

17 participants
345 discussions

[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] 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] Kamailio passive instance tries to send dialog keepalives after service restart (Issue #4077)
by akabihno 12 Feb '25

12 Feb '25

### Description Kamailio is running on 2 nodes using DMQ for HA. Following DMQ parameters are set: ``` modparam("dmq", "server_address", "sip:LOCAL_IP:DMQ_PORT") modparam("dmq", "notification_address", "sip:OTHER_NODE_IP:DMQ_PORT") modparam("dmq", "multi_notify", 0) modparam("dmq_usrloc", "enable", 1) modparam("dmq_usrloc", "sync", 1) modparam("dmq_usrloc", "replicate_socket_info", 1) modparam("dmq_usrloc", "batch_msg_contacts", 50) modparam("dmq_usrloc", "batch_size", 10000) modparam("dmq_usrloc", "batch_usleep", 500000) ``` If kamailio is restarted on passive instance, it tries to send keepalives for DMQ replicated dialog, producing errors ### Troubleshooting #### Reproduction - Have set dialog properties "ka-src", "ka-dst": ``` if (is_method("INVITE")) { setflag(FLT_ACC); #!ifdef WITH_DIALOG dlg_manage(); dlg_set_property("ka-src"); dlg_set_property("ka-dst"); #!endif } ``` - Have calls on active instance and DMQ replicated dialogs on passive instance ``` kamcmd dlg.list { h_entry: 936 h_id: 7534 ref: 2 call-id: inds188n38bjr7tsa2hb from_uri: sip:90123@10.1.2.3 to_uri: sip:0012345@10.1.2.3 state: 4 start_ts: 1734441148 init_ts: 1734441142 end_ts: 0 duration: 119 timeout: 1734484347 lifetime: 43200 dflags: 0 sflags: 0 iflags: 64 caller: { tag: c91qu93uc5 contact: sip:hp3405ho@iacvttr6b897.invalid;transport=ws;ob;alias=10.5.6.7~39402~6 cseq: 2 route_set: socket: <null string> } callee: { tag: 32fd1f16-2fd3-4924-9423-4267871f4ea8 contact: sip:10.2.3.4:5060 cseq: 0 route_set: socket: <null string> } profiles: { } variables: { } } ``` - Restart kamailio service on passive instance #### Debugging Data #### Log Messages ``` Dec 17 13:15:34 hostname.redacted.com docker[31099]: 45(53) WARNING: <core> [core/msg_translator.c:3024]: via_builder(): TCP/TLS connection (id: 0) for WebSocket could not be found Dec 17 13:15:34 hostname.redacted.com docker[31099]: 45(53) ERROR: tm [t_msgbuilder.c:1423]: assemble_via(): via building failed Dec 17 13:15:34 hostname.redacted.com docker[31099]: 45(53) ERROR: tm [t_msgbuilder.c:1614]: build_uac_req(): error while assembling Via Dec 17 13:15:34 hostname.redacted.com docker[31099]: 45(53) ERROR: tm [uac.c:552]: t_uac_prepare(): Error while building message Dec 17 13:15:34 hostname.redacted.com docker[31099]: 45(53) ERROR: dialog [dlg_req_within.c:810]: dlg_send_ka(): failed to send the OPTIONS request Dec 17 13:15:34 hostname.redacted.com docker[31099]: 45(53) ERROR: <core> [core/udp_server.c:810]: udp_send(): sendto(sock, buf: 0x7f3736a421b0, len: 329, 0, dst: (10.5.2.192:5060), tolen: 16) - err: Invalid argument (22) Dec 17 13:15:34 hostname.redacted.com docker[31099]: 45(53) CRITICAL: <core> [core/udp_server.c:817]: udp_send(): invalid sendtoparameters Dec 17 13:15:34 hostname.redacted.com docker[31099]: one possible reason is the server is bound to localhost and Dec 17 13:15:34 hostname.redacted.com docker[31099]: attempts to send to the net Dec 17 13:15:34 hostname.redacted.com docker[31099]: 45(53) ERROR: tm [../../core/forward.h:245]: msg_send_buffer(): udp_send failed Dec 17 13:15:34 hostname.redacted.com docker[31099]: 45(53) ERROR: tm [uac.c:708]: send_prepared_request_impl(): Attempt to send to precreated request failed Dec 17 13:15:34 hostname.redacted.com docker[31099]: 34(42) ERROR: <core> [core/udp_server.c:810]: udp_send(): sendto(sock, buf: 0x7f3736a42000, len: 329, 0, dst: (10.5.2.192:5060), tolen: 16) - err: Invalid argument (22) Dec 17 13:15:34 hostname.redacted.com docker[31099]: 34(42) CRITICAL: <core> [core/udp_server.c:817]: udp_send(): invalid sendtoparameters Dec 17 13:15:34 hostname.redacted.com docker[31099]: one possible reason is the server is bound to localhost and Dec 17 13:15:34 hostname.redacted.com docker[31099]: attempts to send to the net Dec 17 13:15:34 hostname.redacted.com docker[31099]: 34(42) ERROR: tm [../../core/forward.h:245]: msg_send_buffer(): udp_send failed ``` #### SIP Traffic ### Possible Solutions ### Additional Information ``` version: kamailio 5.8.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_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 on 13:38:04 Nov 12 2024 with gcc 13.2.1 ``` * **Operating System**: Running https://ghcr.io/kamailio/kamailio-ci:5.8.4-alpine in docker as systemd service ``` Host system: lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 16.04.3 LTS Release: 16.04 Codename: xenial uname -a Linux _hostname redacted_ 4.4.0-1052-aws #61-Ubuntu SMP Mon Feb 12 23:05:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux docker -v Docker version 20.10.7, build f0df350 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4077 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4077(a)github.com>

2 2

[kamailio/kamailio] xhttp_prom module with custom tags (Issue #4021)
by Christian Berger 11 Feb '25

11 Feb '25

### Description In Prometheus there is the possibility to tag values with tags. Those tags can then be used provide context to those values, for example to filter them. ### Expected behavior It would be great if there was a way to provide custom tags to the metrics. These would essentially just be a static string between the name of the metric and its value. Example: `system_load15{host="wurst23.dev.sipgate.net",hostname_short="wurst32"} 0.4` This could probably be achieved by having an `xhttp_prom_ending` parameter similar to the `xhttp_prom_beginning` as we essentially just want to append a static string right after the metric name. #### Actual observed behavior `kamailio_sip_lb_de_core_rcv_replies_1xx_invite 1773 1731419851663` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4021 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4021(a)github.com>

4 7

[kamailio/kamailio] app_python3: evaluate LIBS variable imediately in Makefile (PR #4085)
by sergey-safarov 08 Feb '25

08 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 - [x] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist: - [x] PR should be backported to stable branches - [x] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description latest `make` version does not evaluate variables immediately. PR explicitly evaluates the LIBS makefile variable. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/4085 -- Commit Summary -- * app_python3: evaluate LIBS variable imediately in Makefile -- File Changes -- M src/modules/app_python3/Makefile (4) -- Patch Links -- https://github.com/kamailio/kamailio/pull/4085.patch https://github.com/kamailio/kamailio/pull/4085.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/4085 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/4085(a)github.com>

5 96

[kamailio/kamailio] geoip: module relocated to archive (PR #3978)
by Victor Seva 05 Feb '25

05 Feb '25

related #3886 You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/3978 -- Commit Summary -- * geoip: module relocated to archive -- File Changes -- M src/Makefile.groups (8) D src/modules/geoip/Makefile (9) D src/modules/geoip/README (166) D src/modules/geoip/doc/Makefile (4) D src/modules/geoip/doc/geoip.xml (42) D src/modules/geoip/doc/geoip_admin.xml (199) D src/modules/geoip/geoip_mod.c (157) D src/modules/geoip/geoip_pv.c (421) D src/modules/geoip/geoip_pv.h (40) -- Patch Links -- https://github.com/kamailio/kamailio/pull/3978.patch https://github.com/kamailio/kamailio/pull/3978.diff -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3978 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3978(a)github.com>

4 6

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev December 2024