sr-dev July 2025

sr-dev@lists.kamailio.org

17 participants
267 discussions

[kamailio/kamailio] "dns_hash_put(): unlinked item" downgrade of the WARN messages to INFO (Issue #4287)
by hubgurujr 01 Jul '25

01 Jul '25

hubgurujr created an issue (kamailio/kamailio#4287) Seeing a lot of warning messages in logs, running version: kamailio 5.8.4 (x86_64/linux) 1e6738, but I think this is false positive and should be informational, not a warning. Jun 10 14:14:17 siprouter1-pve186 /usr/local/sbin/kamailio[8111]:WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item 0x7fa0f9b9fcc0 Jun 10 14:14:19 siprouter1-pve186 /usr/local/sbin/kamailio[8122]:WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe():unlinked item 0x7fa0f9b9fcc0 This is occurring when a DNS URL changes IP but I see no processing issues with SIP Messages. [emal-thread.txt](https://github.com/user-attachments/files/20776557/emal-th… -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4287 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4287(a)github.com>

2 16

[kamailio/kamailio] branch_failure_route does not handle reply while wt_timer period (Issue #4266)
by IgorG 01 Jul '25

01 Jul '25

IgorrG created an issue (kamailio/kamailio#4266) ### Description While implementing mid-register inspired by pull request (https://github.com/kamailio/kamailio/pull/3360) we found the case when it goes impossible to handle responses for registrar servers. In case some of registrars busy and respond with 401 after 200ok received - it is not possible using any routes and configuration options to handle responses received in branch transactions. According to documentation I think that setting wt_timer should allow to absorb and handle responses on failure-route while transaction kept in memory. In fact wt_timer does not affect handling responses in any way. ![Image](https://github.com/user-attachments/assets/14feb472-91ea-4028-8780-1fee1d4ee0e8) ### Troubleshooting To reproduce this case we have configured sipp to response instant with 200ok on registration request. #### Reproduction To reproduce issue SIPP could be setup as one of the dispatcher nodes with instant 200ok reply to register. Kamailio should use following configuration snippet: https://github.com/ovoshlook/kamailio-mid-registrar-config-snippets/blob/ma… #### Log Messages REGISTER|401tm [t_lookup.c:912]: t_reply_matching(): t_reply_matching: hash 12337 label 0 branch 1 REGISTER|401tm [t_lookup.c:986]: t_reply_matching(): reply (0x7f1fc67f83a8) matched an active transaction (T=0x7f1fc0f0f740)! REGISTER|401tm [t_lookup.c:1122]: t_check_msg(): msg (0x7f1fc67f83a8) id=13/1915035 global id=13/1915035 T end=0x7f1fc0f0f740 REGISTER|401tm [t_reply.c:2363]: reply_received(): transaction found - T:0x7f1fc0f0f740 branch:1 REGISTER|401tm [t_reply.c:2376]: reply_received(): original status uas=200, uac[1]=0 local=0 is_invite=0) REGISTER|401tm [t_reply.c:1363]: t_should_relay_response(): ->>>>>>>>> T_code=200, new_code=401 REGISTER|401tm [t_reply.c:1374]: t_should_relay_response(): final reply already sent REGISTER|401tm [t_reply.c:1625]: t_should_relay_response(): finished with rps discarded - uas status: 200 ### Possible Solutions  ### Additional Information * **Kamailio Version** ``` version: kamailio 5.6.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, 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 on 16:35:08 Jun 5 2023 with gcc 10.2.1 ``` * **Operating System**: ``` No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux 11 (bullseye) Release: 11 Codename: bullseye Linux pbxKamaTest 5.10.0-23-amd64 #1 SMP Debian 5.10.179-1 (2023-05-12) x86_64 GNU/Linux ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/4266 You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/issues/4266(a)github.com>

3 2

git:master:fee83561: core: dns cache - destroy the item directly on remove
by Daniel-Constantin Mierla 01 Jul '25

01 Jul '25

Module: kamailio Branch: master Commit: fee835616425723f81b433b561aba54fbfd17045 URL: https://github.com/kamailio/kamailio/commit/fee835616425723f81b433b561aba54… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: 2025-07-01T14:43:01+02:00 core: dns cache - destroy the item directly on remove --- Modified: src/core/dns_cache.c --- Diff: https://github.com/kamailio/kamailio/commit/fee835616425723f81b433b561aba54… Patch: https://github.com/kamailio/kamailio/commit/fee835616425723f81b433b561aba54… --- diff --git a/src/core/dns_cache.c b/src/core/dns_cache.c index 2ed1b21f143..cb343a81184 100644 --- a/src/core/dns_cache.c +++ b/src/core/dns_cache.c @@ -508,7 +508,8 @@ inline static void _dns_hash_remove_entry( LM_DBG("item %p with high refcnt %d (%s:%u)\n", e, atomic_get_int(&e->refcnt), fpath, line); } - dns_hash_put(e); + /* item unlinked - destroy it */ + dns_destroy_entry(e); } #define _dns_hash_remove(e) _dns_hash_remove_entry(e, __FILE__, __LINE__)

1 0

git:master:5108e3c5: core: dns cache - lower the log levels for put and remove operations
by Daniel-Constantin Mierla 01 Jul '25

01 Jul '25

Module: kamailio Branch: master Commit: 5108e3c529790b1bc97e160ae841f238aa1bda4a URL: https://github.com/kamailio/kamailio/commit/5108e3c529790b1bc97e160ae841f23… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: 2025-07-01T13:11:22+02:00 core: dns cache - lower the log levels for put and remove operations --- Modified: src/core/dns_cache.c --- Diff: https://github.com/kamailio/kamailio/commit/5108e3c529790b1bc97e160ae841f23… Patch: https://github.com/kamailio/kamailio/commit/5108e3c529790b1bc97e160ae841f23… --- diff --git a/src/core/dns_cache.c b/src/core/dns_cache.c index 6c5f8c38e1b..2ed1b21f143 100644 --- a/src/core/dns_cache.c +++ b/src/core/dns_cache.c @@ -180,7 +180,7 @@ void dns_hash_put_entry( /* atomic_sub_long(dns_cache_total_used, e->total_size); */ dns_destroy_entry(e); } else if(e->next == NULL && e->prev == NULL) { - LM_WARN("unlinked item %p rc %d (%s:%u)\n", e, + LM_INFO("unlinked item %p rc %d (%s:%u)\n", e, atomic_get_int(&e->refcnt), fpath, line); } } @@ -505,7 +505,7 @@ inline static void _dns_hash_remove_entry( e->last_used_lst.next = e->last_used_lst.prev = 0; *dns_cache_mem_used -= e->total_size; if(atomic_get_int(&e->refcnt) > 1) { - LM_INFO("item %p with high refcnt %d (%s:%u)\n", e, + LM_DBG("item %p with high refcnt %d (%s:%u)\n", e, atomic_get_int(&e->refcnt), fpath, line); } dns_hash_put(e);

1 0

git:master:40837145: microhttpd: rework resetting the data field
by Daniel-Constantin Mierla 01 Jul '25

01 Jul '25

Module: kamailio Branch: master Commit: 4083714575e2cb7500c67fb8a0b99ff371bf8576 URL: https://github.com/kamailio/kamailio/commit/4083714575e2cb7500c67fb8a0b99ff… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: 2025-07-01T13:05:43+02:00 microhttpd: rework resetting the data field --- Modified: src/modules/microhttpd/microhttpd_mod.c --- Diff: https://github.com/kamailio/kamailio/commit/4083714575e2cb7500c67fb8a0b99ff… Patch: https://github.com/kamailio/kamailio/commit/4083714575e2cb7500c67fb8a0b99ff… --- diff --git a/src/modules/microhttpd/microhttpd_mod.c b/src/modules/microhttpd/microhttpd_mod.c index ff486ac7dd6..7bc6586aaf3 100644 --- a/src/modules/microhttpd/microhttpd_mod.c +++ b/src/modules/microhttpd/microhttpd_mod.c @@ -535,14 +535,10 @@ static enum MHD_Result ksr_microhttpd_request(void *cls, if(_ksr_mhttpd_ctx.data.s != NULL) { free(_ksr_mhttpd_ctx.data.s); } + _ksr_mhttpd_ctx.data.s = NULL; + _ksr_mhttpd_ctx.data.len = 0; if(cstream->data.len > 0) { - if(_ksr_mhttpd_ctx.data.s != NULL) { - free(_ksr_mhttpd_ctx.data.s); - } _ksr_mhttpd_ctx.data = cstream->data; - } else { - _ksr_mhttpd_ctx.data.s = NULL; - _ksr_mhttpd_ctx.data.len = 0; } free(cstream); _ksr_mhttpd_ctx.cinfo = MHD_get_connection_info(

1 0

Issues with Kamailio + RTPEngine Integration: ACK Handling and Media Flow in WSS Scenario
by Roman Dcoz 01 Jul '25

01 Jul '25

Hello community, We're currently facing a couple of issues in our setup involving Kamailio (v6.1.0-dev1), RTPEngine, and FreeSWITCH, primarily with WebRTC/WSS endpoints and media handling. I would appreciate any guidance or suggestions to help resolve them. Issue 1: ACK Dropped Due to .invalid Hostname – Call Drops After 32s We are experiencing a problem when using t_on_reply() where ACKs fail to route correctly, resulting in the following error: <core> [core/resolve.c:1773]: sip_hostport2su(): could not resolve hostname: "2f3d6480-4e78-11f0-a25d-ad05fd2deba0.invalid" <core> [core/forward.c:536]: forward_request_mode(): bad host name 2f3d6480-4e78-11f0-a25d-ad05fd2deba0.invalid, dropping packet sl [sl_funcs.c:430]: sl_reply_error(): stateless error reply used: Unresolvable destination (478/SL) This causes ACKs to fail and calls to drop after 32 seconds (likely due to lack of ACK for 200 OK). Here is my WITHINDLG function. route[WITHINDLG] { if (has_totag()) { if (is_method("ACK")) { # Fix invalid domains before forwarding if ($du =~ ".invalid") { xlog("L_WARN", "Fixing ACK destination for invalid domain: $ru\n"); handle_ruri_alias(); } xlog("L_INFO", "Processing ACK for call ID: $ci $ru\n"); if (t_check_trans()) { xlog("L_INFO", "Stateful ACK - relaying\n"); route(RELAY); exit; } else { xlog("L_WARN", "Stateless ACK - relaying anyway to ensure call stability $proto $ru\n"); route(RELAY); exit; } } if (loose_route()) { xlog("L_INFO", "Loose routing enabled for $rm\n"); if ($du == "") { if (!handle_ruri_alias()) { xlog("L_ERR", "Bad alias <$ru>\n"); sl_send_reply("400", "Bad Request"); exit; } } route(DLGURI); if (is_method("BYE")) { setflag(FLT_ACC); # Do accounting setflag(FLT_ACCFAILED); # Even if the transaction fails } if (is_method("NOTIFY")) { record_route(); } route(RELAY); exit; } else { if (is_method("SUBSCRIBE") && uri == myself) { xlog("L_INFO", "Processing in-dialog SUBSCRIBE request\n"); exit; } if (is_method("ACK")) { xlog("L_WARN", "Standalone ACK detected, ignoring\n"); exit; } sl_send_reply("404", "Not Here"); exit; } } } Questions: Is there a more reliable way to handle .invalid hostnames in $du/$ru caused by upstream or downstream Contact headers? Should I forcibly rewrite $du/$ru or avoid using t_on_reply() for certain scenarios? Issue 2: Media Not Flowing Correctly – RTPEngine Flags for WSS ➝ Freeswitch ➝ WSS We’re testing a WebRTC (WSS) → Freeswitch → WebRTC (WSS) flow, where Freeswitch is generating media with media_webrtc=true. The general flow is: Device Registred on Kamailio (WSS client) → Freeswitch → Kamailio/RTPEngine → WSS client Our branch logic is as follows: route[LOCATION] { t_on_branch("BRANCH_MEDIA"); lookup("location"); t_relay(); exit; } branch_route[BRANCH_MEDIA] { if (is_method("INVITE")) { xlog("L_INFO", "BRANCH_MEDIA.......................................\n"); xlog("L_INFO", "Request for $proto $ru $du"); if ($ru =~ "transport=ws") { xlog("L_INFO", "This is a WSS phone call request to $proto $ru"); if (sdp_with_transport_like("RTP/SAVPF")) { rtpengine_offer("ICE=force-relay replace-origin DTLS=passive"); xlog("L_INFO", "[REPLY_WS_TO_WS]Request to REPLY_WS_TO_WS"); t_on_reply("REPLY_WS_TO_WS"); }else { rtpengine_offer("trust-address replace-origin replace-session-connection ICE=force RTP/SAVPF SDES-off rtcp-mux-offer"); xlog("L_INFO", "[REPLY_FROM_WS]Request to REPLY_FROM_WS"); t_on_reply("REPLY_FROM_WS"); } } else if ($proto =~ "ws") { $var(rtpengine_offer_flags) = "trust-address replace-origin replace-session-connection rtcp-mux-demux ICE=remove UDP/TLS/RTP/SAVP"; t_on_reply("REPLY_TO_WS"); rtpengine_offer("$var(rtpengine_offer_flags)"); } else { $var(rtpengine_offer_flags) = "trust-address replace-origin replace-session-connection rtcp-mux-demux ICE=remove RTP/AVP"; t_on_reply("MANAGE_CLASSIC_REPLY"); rtpengine_offer("$var(rtpengine_offer_flags)"); } } route(NATMANAGE); } onreply_route[REPLY_WS_TO_WS] { if(status=~"[12][0-9][0-9]") { rtpengine_answer("ICE=force-relay replace-origin DTLS=passive"); route(NATMANAGE); } if (nat_uac_test("1")) { fix_nated_contact(); } } onreply_route[REPLY_TO_WS] { if (is_method("INVITE") && has_totag() && t_check_status("200")) { xlog("L_INFO", "[REPLY_TO_WS]Reply from webrtc client: $rs"); $var(rtpengine_REPLY_TO_WS_flags) = "trust-address replace-origin replace-session-connection SDES-off ICE=force"; route(NATMANAGE); xlog("L_INFO","[REPLY_TO_WS] RTP Engine Flags Answer--------->: $var(rtpengine_REPLY_TO_WS_flags)\n"); rtpengine_answer("$var(rtpengine_REPLY_TO_WS_flags)"); } if (nat_uac_test("1")) { fix_nated_contact(); } } onreply_route[REPLY_FROM_WS] { if(status=~"[12][0-9][0-9]") { rtpengine_answer("trust-address replace-origin replace-session-connection DTLS=passive ICE=remove RTP/AVP rtcp-mux-demux label=$fU"); xlog("L_INFO", "----- $fU | Change RTP sources for WS reply $rs in REPLY_FROM_WS- M=$rm R=$ru F=$fu T=$tu IP=$pr:$si:$sp -----\n"); route(NATMANAGE); } if (nat_uac_test("1")) { fix_nated_contact(); } } onreply_route[MANAGE_CLASSIC_REPLY] { if (is_method("INVITE") && has_totag() && t_check_status("200")) { xlog("L_INFO", "[MANAGE_CLASSIC_REPLY]Boring reply from softphone: $rs"); $var(rtpengine_flags) = "rtcp-mux-demux DTLS=off SDES-on ICE=remove RTP/SAVP inject-DTMF"; route(NATMANAGE); xlog("L_INFO","[MANAGE_CLASSIC_REPLY] RTP Engine Flags Answer--------->: $var(rtpengine_flags)\n"); rtpengine_answer("$var(rtpengine_flags)"); } if (nat_uac_test("1")) { fix_nated_contact(); } } Despite this, media is not flowing properly between WSS clients, and we're suspecting either the wrong RTPEngine flags or SDP modifications. Questions: Is this the correct way to differentiate flags based on WSS versus UDP endpoints? Is it recommended to split branch_route vs onreply_route in this manner? Any help or suggestions from the community would be greatly appreciated. Thanks in advance! Best regards,

1 0

git:master:1f179a52: etc/kamailio.cfg: define option to relay RTP always
by Daniel-Constantin Mierla 01 Jul '25

01 Jul '25

Module: kamailio Branch: master Commit: 1f179a5288b356d003ffbfca64afb2a55cb1027c URL: https://github.com/kamailio/kamailio/commit/1f179a5288b356d003ffbfca64afb2a… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: 2025-07-01T07:19:11+02:00 etc/kamailio.cfg: define option to relay RTP always - skip the NAT condition for RTP relaying, can be helpful for ALGs that fix the signaling but leave direct RTP streams blocked --- Modified: etc/kamailio.cfg --- Diff: https://github.com/kamailio/kamailio/commit/1f179a5288b356d003ffbfca64afb2a… Patch: https://github.com/kamailio/kamailio/commit/1f179a5288b356d003ffbfca64afb2a… --- diff --git a/etc/kamailio.cfg b/etc/kamailio.cfg index 4cdd0091cb3..43c16b796b2 100644 --- a/etc/kamailio.cfg +++ b/etc/kamailio.cfg @@ -53,6 +53,7 @@ # *** To enable nat traversal execute: # - define WITH_NAT # - option for NAT SIP OPTIONS keepalives: WITH_NATSIPPING +# - option to relay RTP always (with RTPProxy or RTPEngine): WITH_RTPRELAY # - install RTPProxy: http://www.rtpproxy.org # - start RTPProxy: # rtpproxy -l _your_public_ip_ -s udp:localhost:7722 @@ -897,7 +898,10 @@ route[NATMANAGE] { } } } + +#!ifndef WITH_RTPRELAY if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) return; +#!endif #!ifdef WITH_RTPENGINE if(nat_uac_test("8")) {

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev July 2025