sr-users

sr-users@lists.kamailio.org

35 participants
37507 discussions

kamailio tls module not loading
by Timothy Delin 16 Jun '25

16 Jun '25

Hi everyone, I am facing an issue where I cannot load the TLS module in my Kamailio server. I keep receiving this error message "0(1) ERROR: <core> [core/sr_module.c:529]: ksr_locate_module(): could not find module <tls> in </usr/local/lib64/kamailio/modules> 0(1) CRITICAL: <core> [core/cfg.y:4015]: yyerror_at(): parse error in config file /etc/kamailio/modules/tls.cfg, line 1, column 12-19: failed to load module" The Kamailio that I run has this configuration version: kamailio 5.8.6 (x86_64/linux) 6c71d5 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: 6c71d5 compiled on 04:12:34 Jun 6 2025 with gcc 12.2.1 ------------------------------------------------------------------- #global.cfg debug=2 log_stderror=no memdbg=5 memlog=5 log_facility=LOG_LOCAL0 log_prefix="{$mt $hdr(CSeq) $ci} " /* number of SIP routing processes */ children=2 /* Defining interfaces */ #!substdef "!PUBLICIP!$env(PUBLICIP)!" #!substdef "!UDPPORT!$env(UDPPORT)!" #!substdef "!PUBLIC_UDP_SOCKET!udp:PUBLICIP:UDPPORT!" /* Need for TLS Support */ #!substdef "!PUBLIC_TLS_SOCKET!TLS:PUBLICIP:5061!" #!substdef "!COREIP!$env(COREIP)!" #!substdef "!UDPPORT!$env(UDPPORT)!" #!substdef "!CORE_UDP_SOCKET!udp:COREIP:UDPPORT!" #!substdefs "!CORESUBNET!$env(CORESUBNET)!" /* listen addresses */ listen=PUBLIC_UDP_SOCKET listen=CORE_UDP_SOCKET /* Need for TLS Support */ listen=tls:0.0.0.0:5061 #!substdef "!DBUSERNAME!$env(DBUSERNAME)!" #!substdef "!DBPASSWORD!$env(DBPASSWORD)!" #!substdef "!DBHOST!$env(DBHOST)!" #!substdef "!DBNAME!$env(DBNAME)!" #!define DBURL "mysql://DBUSERNAME:DBPASSWORD@DBHOST/DBNAME" #!define HTTP_API_ROUTING_ENDPOINT "http://172.16.254.30:5000/api/routing" ---------------------------------------------------------------- #kamailio.cfg ####### Enable TLS ######## enable_tls=yes ####### Core Modules Section ######## include_file "/etc/kamailio/modules-core.cfg" ####### Global Parameters ######### include_file "/etc/kamailio/globals.cfg" ####### Other Modules Section ######## include_file "/etc/kamailio/modules.cfg" ####### Custom Parameters ######### /* These parameters can be modified runtime via RPC interface * - see the documentation of 'cfg_rpc' module. * * Format: group.id = value 'desc' description * Access: $sel(cfg_get.group.id) or @cfg_get.group.id */ ####### Routing Logic ######## include_file "/etc/kamailio/routes.cfg"

3 2

hfl not working as well
by ale Gural 14 Jun '25

14 Jun '25

Does anyone know why using $(hfl(Diversion)[0]) cuts off the last part of the value, while hdr doesn't? Thanks!

4 10

Fwd: RFC3261 rules
by Sergey Safarov 14 Jun '25

14 Jun '25

Could you look at the attached PCAP with OPTIONS message. When OPTIONS message is received, then Kamailio generates error logs like dropping insane message from 10.140.6.38:60083 After checking the PCAP, I see extra %x00 characters after the OPTIONS message in the same UDP frame. Example [image: image.png] I have checked RFC3261 and do not see a definition of "x00" chars. Also in the same RFC, present a reference to the RFC2234 <https://datatracker.ietf.org/doc/html/rfc2234> where is described "space chars", "white space". According to RFC2223, char %x00 cannot be treated as "space" and should be treated as control (CTL) char. Also, RFC3261 does not use "CTL" chars. Using these two RFC, I can conclude, OPTIONS in the attached PCAP breaks RFC requirements, and we can request partner fix this issue on their equipment. Is anything else in the RFC can be used to justify that the given examples of OPTIONS messages violate RFCs? Sergey

5 4

rtpengine error: no rtpp_set_list->rset_first
by disa_369＠msn.com 11 Jun '25

11 Jun '25

Hello to everyone. I deployed Kamailio on Debian system. Install was successfull. I have the task to use Kamailio as proxy between Avaya PBX and Videoconference System. Outgoing calls only from IPPhone ----- Avaya PBX ---sip----> Kamailio -----sip----> Video System-IVR Now Im trying setup rtpengine for proxy media . Kamailio has some errors by starting service. ERROR: rtpengine [rtpengine.c:3131]: select_rtpp_set(): no rtpp_set_list->rset_first Jun 06 12:07:00 zaks-sbc01-op /usr/sbin/kamailio[635658]: NOTICE: rtpengine [rtpengine.c:1815]: mod_init(): Default rtpp set 0 NOT found Missed out on something in config?

2 5

dns_hash_put(): unlinked item errors
by JR Richardson 10 Jun '25

10 Jun '25

Hey Folks, Running kamailio 5.8.4, haven't needed or used DNS functions previously but recently completed clearip integration, which requires sip request to use URL instead of IP and resolve where to send request. Within hours of adding URL lookups I started getting dns_hash unlinked errors. I correlated the log errors to when the URL changed IP. I assume the caching is working because kamailio sends to the same IP for a few minutes, then switches IP, sends to new IP for a few minutes, then switches IP again and this activity continues. Here are some log errors: switch IP 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 switch IP Jun 10 14:15:00 siprouter1-pve186 /usr/local/sbin/kamailio[8111]: WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item 0x7fa0f9b9ee00 Jun 10 14:15:03 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): unlinked item 0x7fa0f9b9ee00 switch IP Jun 10 14:15:33 siprouter1-pve186 /usr/local/sbin/kamailio[8110]: WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item 0x7fa0f9b8e640 Jun 10 14:15:33 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): unlinked item 0x7fa0f9b8e640 switch IP Jun 10 14:20:37 siprouter1-pve186 /usr/local/sbin/kamailio[8109]: WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item 0x7fa0f9b3eb60 switch IP Jun 10 14:21:12 siprouter1-pve186 /usr/local/sbin/kamailio[8117]: WARNING: <core> [core/dns_cache.c:170]: dns_hash_put(): unlinked item 0x7fa0f9b830f0 Jun 10 14:21:23 siprouter1-pve186 /usr/local/sbin/kamailio[8122]: WARNING: <core> [core/dns_cache.c:185]: dns_hash_put_shm_unsafe(): unlinked item 0x7fa0f9b830f0 Here are my DNS config parameters, nothing I've changed made any difference. And as far as I can tell I'm not dropping any clearip queries. dns=no rev_dns=no use_dns_failover=on dns_try_ipv6=no I did find a patch update for this error back from 2023 and the patch is in my /src/core/dns_cache.c as expected but still getting errors. Any guidance in clearing this error? Thanks. JR

2 1

get ip status from dispatcher
by ale Gural 10 Jun '25

10 Jun '25

Hello, There is a way to get the status of specific ip of dispatcher in kamailio.cfg? not using kamcmd dispatcher.list, thanks!

3 2

How to detect originating and terminating?
by James Morrison 09 Jun '25

09 Jun '25

I'm trying to find a way to differentiate between originating and terminating legs. Currently in kex module, in core_stats.c I'm adding new counters for more response codes, I want to have two sets of counters, one for originating and one for terminating. In ims_getters.c file, I found a function called cscf_has_originating, which by description "Finds if the message contains the orig parameter in the first Route header" I'm calling it like the following: static int km_cb_rpl_stats_by_method(struct sip_msg *msg, unsigned int flags, void *param) { int originating = cscf_has_originating(msg); .... However it always returns CSCF_RETURN_FALSE (or -1). I added a log message and increased log level for core module: DEBUG: <core> [ims_getters.c:561]: cscf_has_originating(): I_originating: Header Route not found ERROR: kex [core_stats.c:424]: km_cb_rpl_stats_by_method(): In kex module received rpls, the return value of cscf_has_originating is: -1 That's because cscf_has_originating function is calling parse_headers function, trying to get msg->route but that route property is not set correctly in the previous step: if(parse_headers(msg, HDR_ROUTE_F, 0) < 0) { LM_DBG("I_originating: error parsing headers\n"); return CSCF_RETURN_FALSE; } so it returns -1 after checking msg->route value. Do you know any alternative solution? or do you know why msg->route value is 0 or NULL?

3 6

siptrace module not respecting send_sock after kamailio 5.6.6
by Daniel Donoghue 09 Jun '25

09 Jun '25

Hello, I have been using the siptrace module on a multihomed kamailio setup for some time now, with kamailio 5.5.7 and 5.6.6, without incident. I am listening to my external interface using something like: listen=tls:external_ip:5061 listen=tcp:external_ip:5060 Listen=tcp:internal_ip:5000 name "homer" And for siptrace... modparam("siptrace", "duplicate_uri", "sip:homer_ip:9060;transport=tcp") modparam("siptrace", "send_sock_name", "homer") I have also used send_sock_addr and force_send... This works as expected. I recently deployed this same setup using kamailio 6.0.1 and discovered that the send_sock is not being respected, even though the logs say it has been selected. Instead, tcpdump and careful examination of all the file descriptors for the kamailio processes reveal it is sending with the source set to my external_ip instead of the internal_ip. I have verified this on the same server, ruling out os level issues routing issues and have tried manually connecting using nc with the internal ip address for the source, which works. I tried downgrading, and found that the same is true for kamailio 5.7.6, 5.8.6 and 6.0.1 This issue only appears to affect siptrace as other sockets appear to use the correct source ip to, for example, connect to a database. I had a look at the change logs and documentation and cant see anything obvious that I need to change from a configuration perspective. Could anybody help? I would prefer to be running 6.0+ in my new production environment but wont be able to if this cannot be solved quickly. Many thanks for your help. With every blessing, -- Daniel Donoghue

2 2

TCP pings from dispatcher
by Alex Balashov 07 Jun '25

07 Jun '25

Does anyone know offhand if dispatcher has access to existing TCP connections from the core for its OPTIONS pings to TCP dispatcher gateways, or whether it generates its own proprietary TCP connections for this specific purpose? -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com, https://www.csrpswitch.com Tel: +1-706-510-6800

2 1

Kamailio Deployment in AWS
by gcampos＠momenta.network 06 Jun '25

06 Jun '25

Hi community, I'm not sure if anyone has ever tried that before, but I'm trying to run Kamailio in AWS with RTPengine. I successfully installed both Kamailio and RTPengine on my EC2 instance and I'm able to make my devices register to it. However, when I make a call from one of my devices, the call is muted. As I analyze my kamailio.cfg file, I see that the "route[NATMANAGE]" is likely the cause of the mute call. I think that none of the conditions below are met, therefore, the flags are not set. Because of that, the last condition is met, thus triggering the "return" and exiting from the route[NATMANAGE] prematurely without even reaching the section where I define the RTPengine modifications. Not only that, but if I remove/comment out the "return", then the RTPengine is triggered, but there call doesn't connect. I wonder why this is happening and if there's any known workaround. # RTP relaying management and signaling updates for NAT traversal route[NATMANAGE] { xlog("L_INFO", "NATMANAGE path was followed\n"); #!ifdef WITH_NAT xlog("L_INFO", "WITH_NAT Triggered\n"); if (is_request()) { xlog("L_INFO", "is_request path was followed\n"); if (has_totag()) { xlog("L_INFO", "has_totag path was followed\n"); if (check_route_param("nat=yes")) { xlog("L_INFO", "nat=yes param detected, setting FLB_NATB\n"); setbflag(FLB_NATB); } } if (nat_uac_test("3")) { xlog("L_INFO", "nat_uac_test(3) matched, setting FLT_NATS + FLB_NATB\n"); setflag(FLT_NATS); setbflag(FLB_NATB); } } if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) { xlog("L_INFO", "No NAT flags set, skipping NAT handling\n"); return; } #!ifdef WITH_RTPENGINE xlog("L_INFO", "WITH_RTPENGINE Path followed\n"); if (has_body("application/sdp")) { if (is_method("INVITE")) { xlog("L_INFO", "IS_METHOD_INVITE Path Followed\n"); rtpengine_manage("replace-origin replace-session-connection trust-address direction=internal"); } else if (is_reply()) { xlog("L_INFO", "IS_Reply Path Followed\n"); rtpengine_manage("replace-origin replace-session-connection trust-address direction=internal"); } } #!else if(nat_uac_test("8")) { rtpproxy_manage("co"); } else { rtpproxy_manage("cor"); } #!endif if (is_request()) { if (!has_totag()) { if(t_is_branch_route()) { add_rr_param(";nat=yes"); } } } if (is_reply()) { if(isbflagset(FLB_NATB)) { if(is_first_hop()) set_contact_alias(); } } if(isbflagset(FLB_NATB)) { # no connect message in a dialog involving NAT traversal if (is_request()) { if(has_totag()) { set_forward_no_connect(); } } } #!endif return; }

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users