- sr-users - kamailio.org

DMQ read message too large
by Calvin E. 31 Mar '25

31 Mar '25

We are seeing errors like this when synchronizing htables over DMQ: ERROR: <core> [core/udp_server.c:677]: udp_rcv_loop(): read message too large: 60793 We have no issues with other UDP fragments caused by STIR/SHAKEN headers. Our socket buffers are sufficiently large (SO_RCVBUF is initially 26214400). Does DMQ have a receive message size limit less than what it can send? Is DMQ intended for htables under a certain total size? We tried to configure DMQ to use a TCP listener with ;transport=tcp on the notification and server address, but the DMQ traffic was still sent as UDP. The example in the documentation shows TLS, but we haven't tried that. -Calvin E.

2 3

Intermediate CDRs
by Sergio Charrua 31 Mar '25

31 Mar '25

Hi all! I have been googling, and reading documentation, but I could not find any solution. How can I implement intermediate CDRs with Kamailio ACC module (or any other module) ? For example, on long duration calls, I 'm required to save call status on a CDR, resulting in intermediate CDR lines for the call (which will result in multiple CDR lines per long duration calls). Any clue on how to implement this? Did anyone achieved that with Kamailio ACC module? Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua*

4 3

Multiple code modules
by David Cunningham 28 Mar '25

28 Mar '25

Hello, We have a requirement to load two code modules for use by kamailio.cfg, the reason being that we can't (won't, for business reasons) modify the first module and so need to add a second for our own code. Ideally we would load two Perl modules instead of the single module that's currently loaded like this: modparam( "app_perl", "filename", "/path/to/our/custom/Kamailio.pm" ) But I'm not sure how to load two modules like this. Otherwise, does anyone know if it's safe to load both a Perl module and a Python module? Then we could at least implement both required parts, one in Perl and one in Python. Thanks in advance for any help. -- David Cunningham, Voisonics Limited http://voisonics.com/ USA: +1 213 221 1092 New Zealand: +64 (0)28 2558 3782

1 0

[ratelimit module] doubts about behavior
by juliofabian6385＠hotmail.es 26 Mar '25

26 Mar '25

I am reading https://kamailio.org/docs/modules/devel/modules/ratelimit.html and I want Kamailio, before an avalanche of calls (INVITE), to start discarding calls that exceed a threshold in 1 second, for example. So in summary I have prepared the module as follows: loadmodule "ratelimit.so" modparam("ratelimit", "timer_interval",1) modparam("ratelimit", "pipe", "1:TAILDROP:10") request_route { . . if (is_method("INVITE")) { if (!rl_check_pipe("1")) { sl_send_reply("503","Limiting"); exit; } } . . } As I understand from the documentation, this gives me a counter (one per INVITE) equal to 10, which resets after 1 second. In other words, if I receive 30 INVITES in 1 second, it will discard 20. From here, I have two questions between what I understand and what I see in the logs. FIRST QUESTION: I've made several SIPP calls in one second. I've run several tests, and the first reset of the counter always happens approximately timer_interval/2. From then on, the counter resets exactly every timer_interval. Am I doing something wrong? ########## RUNNING LOGS ########## 2025-03-26T18:59:20.509696381Z 0(1) DEBUG: <core> [core/cfg.y:2165]: yyparse(): loading module ratelimit.so 2025-03-26T18:59:20.509698675Z 0(1) DEBUG: <core> [core/sr_module.c:533]: ksr_locate_module(): found module to load </usr/lib/kamailio/modules/ratelimit.so> 2025-03-26T18:59:20.509702249Z 0(1) DEBUG: <core> [core/sr_module.c:587]: ksr_load_module(): trying to load </usr/lib/kamailio/modules/ratelimit.so> 2025-03-26T18:59:20.509704682Z 0(1) DEBUG: <core> [core/kemi.c:3463]: sr_kemi_modules_add(): adding module: ratelimit 2025-03-26T18:59:20.509707031Z 0(1) DEBUG: <core> [core/cfg.lex:2095]: pp_define(): defining id: MOD_ratelimit 2025-03-26T18:59:20.509815384Z 0(1) DEBUG: <core> [core/modparam.c:112]: set_mod_param_regex(): 'ratelimit' matches module 'ratelimit' 2025-03-26T18:59:20.509817770Z 0(1) DEBUG: <core> [core/sr_module.c:850]: find_param_export(): found <timer_interval> in module ratelimit [/usr/lib/kamailio/modules/ratelimit.so] 2025-03-26T18:59:20.509820319Z 0(1) DEBUG: <core> [core/modparam.c:135]: set_mod_param_regex(): found <timer_interval> in module ratelimit [/usr/lib/kamailio/modules/ratelimit.so] 2025-03-26T18:59:20.509822755Z 0(1) DEBUG: <core> [core/modparam.c:112]: set_mod_param_regex(): 'ratelimit' matches module 'ratelimit' 2025-03-26T18:59:20.509825068Z 0(1) DEBUG: <core> [core/sr_module.c:850]: find_param_export(): found <pipe> in module ratelimit [/usr/lib/kamailio/modules/ratelimit.so] 2025-03-26T18:59:20.509827468Z 0(1) DEBUG: <core> [core/modparam.c:135]: set_mod_param_regex(): found <pipe> in module ratelimit [/usr/lib/kamailio/modules/ratelimit.so] 2025-03-26T18:59:20.509829943Z 0(1) DEBUG: ratelimit [ratelimit.c:925]: parse_pipe_params(): pipe: [1|TAILDROP|10] 2025-03-26T18:59:20.510800378Z 0(1) DEBUG: <core> [core/sr_module.c:758]: find_mod_export_record(): found export of <rl_check_pipe> in module ratelimit [/usr/lib/kamailio/modules/ratelimit.so] 2025-03-26T18:59:20.519776933Z 0(1) DEBUG: <core> [core/sr_module.c:1031]: init_mod(): ratelimit ########## LOGS WHEN APPLY RATELIMIT ########## 2025-03-26T19:01:02.095676663Z 1(7) DEBUG: {1 1 INVITE 1-1(a)192.168.100.15} ratelimit [ratelimit.c:861]: w_rl_check_forced_pipe(): trying pipe 1 2025-03-26T19:01:02.095679040Z 1(7) DEBUG: {1 1 INVITE 1-1(a)192.168.100.15} ratelimit [ratelimit.c:830]: rl_check(): meth=INVITE queue=0 pipe=1 algo=2 limit=10 pkg_load=0 counter=1 load=0.0 network_load=0 => ACCEPT . . 2025-03-26T19:01:02.272879226Z 2(8) DEBUG: {1 1 INVITE 10-1(a)192.168.100.15} ratelimit [ratelimit.c:861]: w_rl_check_forced_pipe(): trying pipe 1 2025-03-26T19:01:02.272881671Z 2(8) DEBUG: {1 1 INVITE 10-1(a)192.168.100.15} ratelimit [ratelimit.c:830]: rl_check(): meth=INVITE queue=0 pipe=1 algo=2 limit=10 pkg_load=0 counter=10 load=0.0 network_load=0 => ACCEPT 2025-03-26T19:01:02.292599816Z 2(8) DEBUG: {1 1 INVITE 11-1(a)192.168.100.15} ratelimit [ratelimit.c:861]: w_rl_check_forced_pipe(): trying pipe 1 2025-03-26T19:01:02.292602425Z 2(8) DEBUG: {1 1 INVITE 11-1(a)192.168.100.15} ratelimit [ratelimit.c:830]: rl_check(): meth=INVITE queue=0 pipe=1 algo=2 limit=10 pkg_load=0 counter=11 load=0.0 network_load=0 => DROP . . 2025-03-26T19:01:02.492680874Z 1(7) DEBUG: {1 1 INVITE 21-1(a)192.168.100.15} ratelimit [ratelimit.c:861]: w_rl_check_forced_pipe(): trying pipe 1 2025-03-26T19:01:02.492694107Z 1(7) DEBUG: {1 1 INVITE 21-1(a)192.168.100.15} ratelimit [ratelimit.c:830]: rl_check(): meth=INVITE queue=0 pipe=1 algo=2 limit=10 pkg_load=0 counter=21 load=0.0 network_load=0 => DROP 2025-03-26T19:01:02.513079779Z 2(8) DEBUG: {1 1 INVITE 22-1(a)192.168.100.15} ratelimit [ratelimit.c:861]: w_rl_check_forced_pipe(): trying pipe 1 2025-03-26T19:01:02.513088852Z 2(8) DEBUG: {1 1 INVITE 22-1(a)192.168.100.15} ratelimit [ratelimit.c:830]: rl_check(): meth=INVITE queue=0 pipe=1 algo=2 limit=10 pkg_load=0 counter=22 load=0.0 network_load=0 => DROP 2025-03-26T19:01:02.532804253Z 1(7) DEBUG: {1 1 INVITE 23-1(a)192.168.100.15} ratelimit [ratelimit.c:861]: w_rl_check_forced_pipe(): trying pipe 1 2025-03-26T19:01:02.532808087Z 1(7) DEBUG: {1 1 INVITE 23-1(a)192.168.100.15} ratelimit [ratelimit.c:830]: rl_check(): meth=INVITE queue=0 pipe=1 algo=2 limit=10 pkg_load=2 counter=1 load=0.1 network_load=0 => ACCEPT When the countdown restarts, it's "19:01:02.53" hours, and when it started, it was "19:01:02.09" hours. It doesn't reach the second. The drop system works well, but if my limit was 25 calls, I would have accepted the 22 I counted in the first second, plus the other 25 from the second number 2. Second question: There's a warning about a performance penalty in Kamailio when timer_interval is too small, so I've decided to set it to 2 just for practical purposes. So what should happen is that the counter would accept up to 10 calls in 2 seconds. But in the logs, what I see is the opposite: it accepts 20 calls in 2 seconds. Maybe it's supposed to work that way, and I'm misunderstanding the documentation? As optional information: Kamailio is running on a Google virtual machine, 12MB of RAM, 3 processors, 2 of which are dedicated. I'm using SIPP for load testing, and different call rates have been validated before testing the module. Sorry if my first post in this community was too long or is there more information missing :) . Thanks in advance

1 0

kamailio call redirect
by fabienbrou＠alcall.net 26 Mar '25

26 Mar '25

Hello everyone. I'm trying to redirect a call directly through kamailio by modifying the $ru variable. Just wondering if this is the right method or if there is a better way to do it. thanks

4 13

is possible empty actions?
by Sergey Safarov 26 Mar '25

26 Mar '25

I want to use contributions like route[PROXY_MEDIA] { if (is_method("BYE|CANCEL")) { # passing message for RTPengine processing } else if (!sdp_content()) { return; } # more instructions here ... rtpengine_manage(); } Now Kamailio cannot start because first if block has empty actions. How does nothing in the actions? I want to avoid not needed log messages and do not use constructions like if (!sdp_content() and ! is_method("BYE|CANCEL")) { return; }

3 2

Seeking advices on redesigning our VoIP system for scalability and manageability
by Francesco 26 Mar '25

26 Mar '25

Dear all, I hope this email finds you well. I am reaching out to gather insights and suggestions regarding a potential redesign of our VoIP system to improve scalability, ease of management, and upgradeability. *Current Setup:* - Our system is *not multi-tenant* and is based on *Kamailio and FreeSWITCH* in a distributed architecture (as example of distributed architecture, see: https://ufdcimages.uflib.ufl.edu/UF/E0/04/92/89/00001/THOMPSON_C.pdf). - Everything runs inside *LXC containers* across multiple nodes. - One of the challenges we face is *OS upgrades*, which are cumbersome and require significant manual intervention. - At the moment the code for voip is done with ansible Given these challenges, I am considering whether a *microservices-based architecture* could be a viable option. However, I have some concerns regarding: - *SIP and RTP handling with NATed containers* (e.g., Kubernetes, Docker Swarm) and potential issues with media traversal. - *Performance impact* when shifting real-time traffic handling to containerized environments. - *Upgrade and deployment strategies*—how to achieve smoother, rolling upgrades without service interruptions. - *Alternative approaches* that might be more effective, such as a hybrid model combining LXC with containerized microservices for specific functions. If anyone has experience transitioning a VoIP system to microservices or has insights on best practices for *scalable, maintainable VoIP architectures*, I would greatly appreciate your thoughts. What worked for you? What pitfalls should we be aware of?Do you have any documentation that I can check? Looking forward to learning from your experiences. Thank you. .: Francesco Colista .: Francesco Colista

3 2

TOPOS Issue with Response Handling on two different Interfaces
by Vinayak Makwana 25 Mar '25

25 Mar '25

Hello all, We are facing an issue while configuring TOPOS in Kamailio P-CSCF (running under Docker). Our objective is to strip Via, Record-Route, and Route headers for both INVITE and 180 Ringing responses. However, we observe unexpected behavior when handling the 180 Ringing/200 OK responses. Call Flow & Issue Description: Note: Public IP and Private IP mapping using the below configuration. listen=udp:Local_IP:5060 name "internal" listen=udp:Local_IP:6070 advertise Public_IP:6070 name "external" Call Flow (INVITE): A-Party --> Kamailio P-CSCF (Public IP) --> Kamailio P-CSCF (Private IP) --> Kamailio S-CSCF (Private IP) --> Kamailio P-CSCF (Private IP) --> Kamailio P-CSCF (Public IP) --> B-Party For an incoming *INVITE* (A-Party → B-Party), TOPOS successfully strips the headers when the message flows through the P-CSCF, ensuring proper privacy of routing information. *Issue* : When B-Party sends a 180 Ringing, we observe that Kamailio P-CSCF (Private IP) adds a Record-Route header before forwarding the message to A-Party. Call Flow (180 Ringing): B-Party --> Kamailio P-CSCF (Public IP) --> Kamailio P-CSCF (Private IP) --> Kamailio S-CSCF (Private IP) We need to ensure that the Record-Route and Via headers are stripped properly in both directions. Please guide us how to achieve and what we are doing wrong. TOPOS module is configured as follows: modparam("ndb_redis", "server", "name=srv1;addr=127.0.0.1;port=6379") modparam("topos_redis", "serverid", "srv1") modparam("topos", "storage", "redis") modparam("topos", "contact_mode", 1) modparam("topos", "rr_update", 1) RR module is configured as follows: modparam("rr", "enable_full_lr", 1) modparam("rr", "append_fromtag", 1) configured the below event_route: event_route[topos:msg-outgoing] { xlog("L_INFO","[topos:msg-outgoing]"); if(is_request() and $sndto(ip)=="SCSCF_PRIVATE_IP") { xlog("L_INFO","[topos:msg-outgoing] TOPOS \n"); drop; } } Thanks, Vinayak Makwana -- *Disclaimer* In addition to generic Disclaimer which you have agreed on our website, any views or opinions presented in this email are solely those of the originator and do not necessarily represent those of the Company or its sister concerns. Any liability (in negligence, contract or otherwise) arising from any third party taking any action, or refraining from taking any action on the basis of any of the information contained in this email is hereby excluded. *Confidentiality* This communication (including any attachment/s) is intended only for the use of the addressee(s) and contains information that is PRIVILEGED AND CONFIDENTIAL. Unauthorized reading, dissemination, distribution, or copying of this communication is prohibited. Please inform originator if you have received it in error. *Caution for viruses, malware etc.* This communication, including any attachments, may not be free of viruses, trojans, similar or new contaminants/malware, interceptions or interference, and may not be compatible with your systems. You shall carry out virus/malware scanning on your own before opening any attachment to this e-mail. The sender of this e-mail and Company including its sister concerns shall not be liable for any damage that may incur to you as a result of viruses, incompleteness of this message, a delay in receipt of this message or any other computer problems.

1 1

Running Kamailio in kubernetes
by sagar agarwal 25 Mar '25

25 Mar '25

Hi team, I am looking for some guidance to run Kamailio as part of our Kubernetes cluster. I don't see any official or well maintained helm chart out there to install Kamailio on K8s. If there is a recommendation from your side on a helm chart please let me know. Also would be interesting to know if you foresee any issues with running Kamailio on k8s or do you feel its better to stick with ec2 based installations. Regards Sagar Agarwal

4 3

Problem with ipsec setting of Via for outgoing message
by Minello, Loredana 24 Mar '25

24 Mar '25

Hello, I'm using Kamailio ver. 5.8.4. I configured the ims_ipsec_pcscf with modparam("ims_ipsec_pcscf", "ipsec_max_connections", 1) and call ipsec_forward with flag = IPSEC_FORWARD_FLAGS where : # - IPSEC_SEND_FORCE_SOCKET 1 # - IPSEC_FORWARD_USEVIA 256 #!define IPSEC_FORWARD_FLAGS 257 For the UE REGISTRATION I have the following flow UE PCSCF_GM_IMS REGISTER (32133) ------------------> (5060) 100 Trying (32133) <------------------ (5060) 401 Unauthorized (32133) <------------------ (5060) REGISTER (TCP) (PORT_UC) ------------------> (PORT_PS) 100 Trying (TCP) (PORT_UC) <------------------ (PORT_PS) 200 OK (TCP) (PORT_UC) <------------------ (PORT_PS) ------------------------------------------------------------------ SUBSCRIBE (UDP) (PORT_UC) ------------------> (PORT_PS) 200 Subscription (UDP) (PORT_US) <------------------ (PORT_PC) NOTIFY (UDP) (PORT_US) <------------------ (PORT_PC) 200 OK (UDP) (PORT_UC) ------------------> (PORT_PC) NOTIFY (UDP) (PORT_US) <------------------ (PORT_PC) 200 OK (UDP) (PORT_UC) ------------------> (PORT_PC) NOTIFY (UDP) (PORT_US) <------------------ (PORT_PC) 200 OK (UDP) (PORT_UC) ------------------> (PORT_PC) The SUBSCRIBE behavior is correct : PCSCF receives message on PORT_PS and sends on PORT_PC The NOTIFY behavior is wrong: PCSCF send from PORT_PC (correct), but UE respond towards PORT_PC, defined in the Via of the NOTIFY. I know I can use the set_advertised_port() function, and in this case can work, but the function is taking a constant as a parameter, not a variable. This is causing a problem when ipsec_max_connections > 1. In that case it won't be easy to pass the correct port. I was wondering if the ipsec module should properly set the VIA port to the correct PORT_PS, rather than leaving the setting of the correct port by the kamailio.cfg. Do you have any hints on that? Thanks

1 0

Re: send_fd(): sendmsg failed sending 55 on 52: Too many references: cannot splice (109)
by Mathias Schneuwly 24 Mar '25

24 Mar '25

Thank you, I've already changed the value, but that didn't solve my issue with the blocking Kamailio. I did some tests with an older Yocto image which contains Kamailio 5.5.4 and OpenSSL 1.1.1w. With this combination I was not able to reproduce the deadlock. Am Fr., 21. März 2025 um 16:49 Uhr schrieb Harald Kapper <hk(a)kapper.net>: > Hi > > fyi – in case you need this: > > systemctl edit kamailio.service > > > > add: > > ### Editing /etc/systemd/system/kamailio.service.d/override.conf > > ### Anything between here and the comment below will become the contents > of the drop-in file > > > > [Service] > > LimitNOFILE=40960 > > > > ### Edits below this comment will be discarded > > > > (or whatever number you’d like) > > saving saves the override for systemd into (like) > /etc/systemd/system/kamailio.service.d/override.conf > > > > Afterwards you have to restart the service (systemctl restart > kamailio.service) > > > > And you should be fine. > > > > Regards, hk > > > > *Von:* Henning Westerholt via sr-users <sr-users(a)lists.kamailio.org> > *Gesendet:* Donnerstag, 20. März 2025 14:25 > *An:* Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org> > *Cc:* Mathias Schneuwly <mathias(a)schneuwlys.ch>; Henning Westerholt < > hw(a)gilawa.com> > *Betreff:* [SR-Users] Re: send_fd(): sendmsg failed sending 55 on 52: Too > many references: cannot splice (109) > > > > Hello Mathias, > > > > yes, you can set the open files e.g. in the systemd unit file for Kamailio. > > > > Cheers, > > > > Henning > > > > *From:* Mathias Schneuwly via sr-users <sr-users(a)lists.kamailio.org> > *Sent:* Donnerstag, 20. März 2025 13:43 > *To:* sr-users(a)lists.kamailio.org > *Cc:* Mathias Schneuwly <mathias(a)schneuwlys.ch> > *Subject:* [SR-Users] Re: send_fd(): sendmsg failed sending 55 on 52: Too > many references: cannot splice (109) > > > > > I'll also give a try with 6.0.1 later. > > Meanwhile, I've tested 5.8.6 and 6.0.1 and both show the same issue. > > > > Am Do., 20. März 2025 um 10:21 Uhr schrieb Mathias Schneuwly < > mathias(a)schneuwlys.ch>: > > Hi Henning > > > > > Maybe also check the actual limits by “cat /proc/$kamailio-pid/limits” > Not 100% if its related, but if you are looking to scale this would be for > sure required. > > The limit was > > Max open files 1024 524288 files > > and I changed it now to > > Max open files 65536 65536 files > > > > Are there some recommendations for the limit? Would it make sense to > change that in the provided systemd file if you say that 1024 is not that > much? > > > > But anyway, it fails with 1024 and with 65536. > > > > I've also updated to 5.8.5 and it shows the same issue. I'll also give a > try with 6.0.1 later. > > > > > About the tls_thread_mode – you should use mode 2 if you are running > with openssl 3.x, otherwise you probably will observe random crashes. > > We are running OpenSSL 3.2.3 and tls_thread_mode is set to 2. But it still > blocks. > > > > Best regards > > Mathias > > > > Am Do., 20. März 2025 um 08:42 Uhr schrieb Henning Westerholt < > hw(a)gilawa.com>: > > Hello Mathias, > > > > 1024 open files are not that much, you should increase it for the kamailio > user. Maybe also check the actual limits by “cat > /proc/$kamailio-pid/limits” > > Not 100% if its related, but if you are looking to scale this would be for > sure required. > > > > About the tls_thread_mode – you should use mode 2 if you are running with > openssl 3.x, otherwise you probably will observe random crashes. > > > > If you are seeing the mentioned problem with 15 phones, this is clearly a > problem and should be further investigated. > > > > Cheers, > > > > Henning > > > > > > *From:* Mathias Schneuwly via sr-users <sr-users(a)lists.kamailio.org> > *Sent:* Donnerstag, 20. März 2025 08:07 > *To:* sr-users(a)lists.kamailio.org > *Cc:* Mathias Schneuwly <mathias(a)schneuwlys.ch> > *Subject:* [SR-Users] Re: send_fd(): sendmsg failed sending 55 on 52: Too > many references: cannot splice (109) > > > > Hi > > > > Thanks for the reply. We are using the following limits and I guess they > are the default values > > real-time non-blocking time (microseconds, -R) unlimited > core file size (blocks, -c) unlimited > data seg size (kbytes, -d) unlimited > scheduling priority (-e) 0 > file size (blocks, -f) unlimited > pending signals (-i) 15666 > max locked memory (kbytes, -l) 8192 > max memory size (kbytes, -m) unlimited > open files (-n) 1024 > pipe size (512 bytes, -p) 8 > POSIX message queues (bytes, -q) 819200 > real-time priority (-r) 0 > stack size (kbytes, -s) 8192 > cpu time (seconds, -t) unlimited > max user processes (-u) 15666 > virtual memory (kbytes, -v) unlimited > file locks (-x) unlimited > > > > But to me, it looks more like a deadlock somewhere around SSL_accept. > According to the stack trace generated with "kamctl trap", all 8 TCP > receiver processes are waiting in "#1 0x00007fa14ca04830 in > pthread_rwlock_wrlock () from /usr/lib/libc.so.6". I guess the message "Too > many references: cannot splice (109)" is just the consequence as the main > process is no longer able to dispatch jobs to the child workers. > > > > Meanwhile, I'm able to reproduce the issue. It requires a bit of brute > force, but it deadlocks reliably after a few seconds. > > > > I'm flooding Kamailio with register messages using sipexer. I'm running > the following command 3 times in parallel and always after a few seconds, > Kamailio is completely blocked. > > watch -n 0.1 "./sipexer -register -vl 3 -co -com -ex 3600 -fu "2" -au "2" > -ap "test" -tk <path to key>.key -tc <path to cert>.cer -ti -sd -ru > sip:<domain> -cu sip:2@<domain> tls:<fqdn>:5061;sleep 0.1;./sipexer > -register -vl 3 -co -com -ex 0 -fu "2" -au "2" -ap "test" -tk <path to > key>.key -tc <path to cert>.cer -ti -sd -ru sip:<domain> -cu sip:2@<domain> > tls:<fqdn>:5061" > > > > I played a bit with the parameters "modparam("tls", "init_mode", 1)" and > "tls_threads_mode = 2", but it didn't seem to change anything. > > > > Please have in mind that we usually do not stress Kamailio that much. We > have seen the issue a couple of times with around 5 to 15 SIP phones > registered. But in this usual setup, the problem does not occur reliably. > > > > Best regards > > Mathias > > > > Am Di., 18. März 2025 um 21:53 Uhr schrieb Henning Westerholt < > hw(a)gilawa.com>: > > Hello, > > > > check the ulimit settings for the kamailio user and general resource usage > on that system. In development branch there is also a feature present to > print the actual ulimits on startup. > > > > Cheers, > > > > Henning > > > > *From:* Mathias Schneuwly via sr-users <sr-users(a)lists.kamailio.org> > *Sent:* Montag, 17. März 2025 13:41 > *To:* sr-users(a)lists.kamailio.org > *Cc:* Mathias Schneuwly <mathias(a)schneuwlys.ch> > *Subject:* [SR-Users] send_fd(): sendmsg failed sending 55 on 52: Too > many references: cannot splice (109) > > > > Hi > > > > We are using kamailio 5.8.4. > > > > Recently, we noticed, that after a few days, we see the following messages > from Kamailio `2025 Mar 17 10:22:11 ttel CRITICAL: <core> > [core/pass_fd.c:193]: send_fd(): sendmsg failed sending 55 on 52: Too many > references: cannot splice (109)`. > > > > When this happens, devices are no longer able to register. At the moment > we have no idea what might be wrong. > > > > Unfortunately, the internet does not reveal much information regarding > this issue. In one issue related to Kamailio ( > https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio…), > I found the command `kamctl trap` and when I execute that, I see one issue, > which might be related, but I'm just guessing... > > > > ``` > > ---start 1782236 ----------------------------------------------------- > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/usr/lib/libthread_db.so.1". > 0x00007fa14c9fb1c6 in ?? () from /usr/lib/libc.so.6 > $1 = 26 > $2 = {pid = 1782236, unix_sock = 36, idx = 0, status = 1, rank = 17, desc > = "tcp receiver (generic) child=0", '\000' <repeats 97 times>} > #0 0x00007fa14c9fb1c6 in ?? () from /usr/lib/libc.so.6 > No symbol table info available. > #1 0x00007fa14ca04830 in pthread_rwlock_wrlock () from /usr/lib/libc.so.6 > No symbol table info available. > #2 0x00007fa14ac20b49 in CRYPTO_THREAD_write_lock () from > /usr/lib/libcrypto.so.3 > No symbol table info available. > #3 0x00007fa14adbd5da in ?? () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #4 0x00007fa14adbd9ca in ?? () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #5 0x00007fa14adbc907 in ?? () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #6 0x00007fa14adbd26c in ?? () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #7 0x00007fa14adbd68e in ?? () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #8 0x00007fa14abe75c6 in ?? () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #9 0x00007fa14abe840b in EVP_RAND_generate () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #10 0x00007fa14acf9282 in RAND_bytes_ex () from /usr/lib/libcrypto.so.3 > No symbol table info available. > #11 0x00007fa14b06cce8 in ?? () from /usr/lib/libssl.so.3 > No symbol table info available. > #12 0x00007fa14b05bdf7 in ?? () from /usr/lib/libssl.so.3 > No symbol table info available. > #13 0x00007fa14b0ef036 in tls_accept (c=c@entry=0x7fa1475c0dc0, > error=error@entry=0x7ffebd9443b8) at tls_server.c:457 > ret = <optimized out> > ssl = warning: could not convert 'ssl_st' from the host encoding > (ANSI_X3.4-1968) to UTF-32. > This normally should not happen, please file a bug report. > 0x7fa147668bd0 > cert = <optimized out> > tls_c = 0x7fa14768f490 > tls_log = <optimized out> > __func__ = "tls_accept" > #14 0x00007fa14b0f7540 in tls_h_read_f (c=0x7fa1475c0dc0, > flags=0x7ffebd9647d0) at tls_server.c:1153 > r = 0x7fa1475c0ee8 > bytes_free = 16383 > bytes_read = <optimized out> > read_size = <optimized out> > ssl_error = 0 > ssl_read = 0 > ssl = 0x7fa147668bd0 > rd_buf = > "\026\003\003\004\016\v\000\004\n\000\004\a\000\004\0040\202\004\0000\202\002\350\240\003\002\001\002\002\002\026\0270\r\006\t*\206H\206\367\r\001\001\v\005\0000b1\v0\t\006\003U\004\006\023\002CH1\r0\v\006\003U\004\b\f\004Bern1\r0\v\006\003U\004\a\f\004Bern1\r0\v\006\003U\004\n\f\004RUAG1\0200\016\006\003U\004\v\f\aDefence1\0240\022\006\003U\004\003\f\versaimfs.ch0\036\027\r230302163519Z\027\r291230163519Z0`1\v0\t\006\003U\004\006\023\002CH1\r0\v\006\003"... > wr_buf = > "\026\003\003\000A\002\000\000=\003\003\371\204\326\361\262-9\300\344gV\2316\373\235D\314\225u8\v}\215\254DOWNGRD\001\000\3000\000\000\025\377\001\000\001\000\000\v\000\004\003\000\001\002\000#\000\000\000\027\000\000\026\003\003\a\267\v\000\a\263\000\a\260\000\004\0040\202\004\0000\202\002\350\240\003\002\001\002\002\002\r>0\r\006\t*\206H\206\367\r\001\001\v\005\0000b1\v0\t\006\003U\004\006\023\002CH1\r0\v\006\003U\004\b\f\004Bern1\r0\v\006\003U\004\a\f\004Bern1\r0\v\006\003U\004\n\f\004RUAG1\0200\016\006\003U\004\v\f\aDefence1\0240\022\006"... > rd = {buf = 0x7ffebd944480 "\026\003\003\004\016\v", pos = 1405, > used = 1405, size = 65536} > wr = {buf = 0x7ffebd954480 "\026\003\003", pos = 0, used = 0, size > = 65536} > tls_c = 0x7fa14768f490 > enc_rd_buf = <optimized out> > n = 0 > flush_flags = 0 > err_src = <optimized out> > ip_buf = '\000' <repeats 63 times> > x = <optimized out> > tls_dbg = <optimized out> > __func__ = "tls_h_read_f" > redo_read = <optimized out> > continue_ssl_read = <optimized out> > __llevel = <optimized out> > __kld = <optimized out> > __llevel = <optimized out> > __kld = <optimized out> > #15 0x000055d2519871b4 in tcp_read_headers (c=c@entry=0x7fa1475c0dc0, > read_flags=read_flags@entry=0x7ffebd9647d0) at core/tcp_read.c:445 > bytes = <optimized out> > remaining = <optimized out> > p = <optimized out> > r = 0x7fa1475c0ee8 > mc = <optimized out> > body_len = <optimized out> > tvnow = {tv_sec = 1742100857, tv_usec = 944923} > tvdiff = <optimized out> > mfline = <optimized out> > mtransid = <optimized out> > __func__ = "tcp_read_headers" > #16 0x000055d251989cef in tcp_read_req (con=0x7fa1475c0dc0, > bytes_read=bytes_read@entry=0x7ffebd9647c8, read_flags=read_flags@entry=0x7ffebd9647d0) > at core/tcp_read.c:1509 > bytes = <optimized out> > total_bytes = 0 > resp = 1 > size = <optimized out> > req = 0x7fa1475c0ee8 > dst = {send_sock = 0x55d251a91020, to = {s = {sa_family = 52024, > sa_data = "\257Q\322U\000\000\002\000\000\000\376\177\000"}, sin = > {sin_family = 52024, sin_port = 20911, sin_addr = {s_addr = 21970}, > sin_zero = "\002\000\000\000\376\177\000"}, sin6 = {sin6_family = 52024, > sin6_port = 20911, sin6_flowinfo = 21970, sin6_addr = {__in6_u = > {__u6_addr8 = > "\002\000\000\000\376\177\000\000\030\000\000\000\000\000\000", __u6_addr16 > = {2, 0, 32766, 0, 24, 0, 0, 0}, __u6_addr32 = {2, 32766, 24, 0}}}, > sin6_scope_id = 0}, sas = {ss_family = 52024, __ss_padding = > "\257Q\322U\000\000\002\000\000\000\376\177\000\000\030", '\000' <repeats > 23 times>, > "\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\262+\226Q\001 > \000\000\200,5L\241\177\000\000 \020\251Q\322U\000\000 > \020\251Q\322U\000\000\200\303\257Q\322U\000\00009SG\241\177\000\000\330G\226\275\376\177\000\000\b\000\000\000\000\000\000", > __ss_align = 20}}, id = 1, send_flags = {f = 1, blst_imask = 0}, proto = 14 > '\016', proto_pad0 = 0 '\000', proto_pad1 = 0} > c = <optimized out> > ret = <optimized out> > again = <optimized out> > __func__ = "tcp_read_req" > #17 0x000055d25198ebec in handle_io (fm=fm@entry=0x7fa14c352c80, > events=events@entry=1, idx=idx@entry=-1) at core/tcp_read.c:1906 > ret = 8 > n = 0 > read_flags = RD_CONN_SHORT_READ > con = 0x7fa1475c0dc0 > s = 14 > resp = <optimized out> > t = <optimized out> > ee = 0x0 > __func__ = "handle_io" > error = <optimized out> > #18 0x000055d25199469b in io_wait_loop_epoll (repeat=repeat@entry=0, t=2, > h=0x55d251c49d60 <io_w>) at core/io_wait.h:1075 > n = 1 > r = 0 > fm = 0x7fa14c352c80 > revents = 1 > __func__ = "io_wait_loop_epoll" > #19 0x000055d251994e87 in tcp_receive_loop (unix_sock=<optimized out>) at > core/tcp_read.c:2026 > __func__ = "tcp_receive_loop" > #20 0x000055d25197e72c in tcp_init_children (woneinit=woneinit@entry=0x7ffebd964d1c) > at core/tcp_main.c:5391 > r = <optimized out> > i = <optimized out> > reader_fd_1 = 39 > pid = <optimized out> > si_desc = "tcp receiver > (generic)\000\000`M\226\275\376\177\000\000\001\000\000\000\000\000\000\000\210\035\223Q\322U\000\000 > \020\251Q\322U\000\000\220\315\257Q\322U\000\000\220\242/L\241\177\000\000\025\000\000\000\000\000\000\000\004\000\000\000\000\000\000\000%\020\251Q\322U\000\000HU\257Q\322U\000\000e\005\000\000\000\000\000\000 > \020\251Q\322U\000\000\3750\235Q\322U\000" > si = <optimized out> > __func__ = "tcp_init_children" > error = <optimized out> > #21 0x000055d2517c6c7e in main_loop () at main.c:1950 > i = <optimized out> > pid = <optimized out> > si = <optimized out> > si_desc = "udp receiver child=7 sock=10.0.90.1:5060\000\000\000\000\322U\000\000?\342\017K\241\177\000\000\022\000\000\000\377\377\377\377\200\006\265L\241\177\000\000\253m\237L\241\177\000\000\361|\003\000\000\000\000\000\t\000\000\000\000\000\000\000Sat > Mar 15 05:25:32 2025\n\000\264L\241\177\000" > nrprocs = <optimized out> > woneinit = 1 > __func__ = "main_loop" > error = <optimized out> > #22 0x000055d2517bc151 in main (argc=<optimized out>, argv=<optimized > out>) at main.c:3256 > cfg_stream = <optimized out> > c = <optimized out> > r = <optimized out> > tmp = 0x7ffebd966e7f "" > tmp_len = 32673 > port = 5060 > proto = 0 > aproto = 0 > ahost = 0x0 > aport = 0 > options = 0x55d251aa74b8 > ":f:cm:M:dVIhEeb:B:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" > ret = -1 > seed = 3209119183 > rfd = <optimized out> > debug_save = <optimized out> > debug_flag = <optimized out> > dont_fork_cnt = 0 > n_lst = <optimized out> > p = <optimized out> > st = {st_dev = 24, st_ino = 46237, st_nlink = 2, st_mode = 16888, > st_uid = 899, st_gid = 899, __pad0 = 0, st_rdev = 0, st_size = 40, > st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1742012732, tv_nsec = > 217328715}, st_mtim = {tv_sec = 1742012732, tv_nsec = 217328715}, st_ctim = > {tv_sec = 1742012732, tv_nsec = 217328715}, __glibc_reserved = {0, 0, 0}} > l1 = <optimized out> > tbuf = '\000' <repeats 32 times>, > "\030\202\237\275\376\177\000\000@\002\000\000@\003\000\000\001", '\000' > <repeats 23 times>, "@\003\000\000@\003\000\000@\003\000\000@\003\000\000@ > \003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@ > \003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@ > \003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@ > \003\000\000@\003\000\000@\003", '\000' <repeats 11 times>, "\001", > '\000' <repeats 118 times>... > option_index = 12 > long_options = {{name = 0x55d251a9230b "help", has_arg = 0, flag = > 0x0, val = 104}, {name = 0x55d251a937a4 "version", has_arg = 0, flag = 0x0, > val = 118}, {name = 0x55d251a9826a "alias", has_arg = 1, flag = 0x0, val = > 1024}, {name = 0x55d251a92310 "subst", has_arg = 1, flag = 0x0, val = > 1025}, {name = 0x55d251a92316 "substdef", has_arg = 1, flag = 0x0, val = > 1026}, {name = 0x55d251a9231f "substdefs", has_arg = 1, flag = 0x0, val = > 1027}, {name = 0x55d251a92329 "server-id", has_arg = 1, flag = 0x0, val = > 1028}, {name = 0x55d251a92333 "loadmodule", has_arg = 1, flag = 0x0, val = > 1029}, {name = 0x55d251a9233e "modparam", has_arg = 1, flag = 0x0, val = > 1030}, {name = 0x55d251a92347 "log-engine", has_arg = 1, flag = 0x0, val = > 1031}, {name = 0x55d251a938c1 "debug", has_arg = 1, flag = 0x0, val = > 1032}, {name = 0x55d251a92352 "cfg-print", has_arg = 0, flag = 0x0, val = > 1033}, {name = 0x55d251a9235c "atexit", has_arg = 1, flag = 0x0, val = > 1034}, {name = 0x55d251a92363 "all-errors", has_arg = 0, flag = 0x0, val = > 1035}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} > __func__ = "main" > [Inferior 1 (process 1782236) detached] > ---end 1782236 ------------------------------------------------------- > > ``` > > > > Does anybody have an idea what this could be? I never saw that with > previous versions, and now we can see it on several instances, but we are > yet unable to reproduce. > > > > Not sure if this might be related, but we also see many messages like `Mar > 17 13:39:03 ttel /usr/sbin/kamailio[2882127]: CRITICAL: <core> > [core/tcp_main.c:5558]: tcp_timer_check_connections(): message processing > timeout on connection id: 402 (state: 0) - closing` > > > > Best regards > > Mathias > >

1 0

Dispatcher module resets URI parameters
by Marat Gareev 22 Mar '25

22 Mar '25

Hello, I encountered a problem that ds_select_domain function does not save URI parameters. I found workaround: if (!ds_select_domain( "1", 4, 3 )) { send_reply("502", "Bad Gateway"); exit; } if (!strempty($(ou{uri.params}))) { $ru = $ru+";"+$(ou{uri.params}); } But this can lead to duplicates if the URI in the dispatcher list contains the same parameter. Is there any other reliable way to keep original URI parameters while using the dispatcher? Thanks

2 1

send_fd(): sendmsg failed sending 55 on 52: Too many references: cannot splice (109)
by Mathias Schneuwly 20 Mar '25

20 Mar '25

Hi We are using kamailio 5.8.4. Recently, we noticed, that after a few days, we see the following messages from Kamailio `2025 Mar 17 10:22:11 ttel CRITICAL: <core> [core/pass_fd.c:193]: send_fd(): sendmsg failed sending 55 on 52: Too many references: cannot splice (109)`. When this happens, devices are no longer able to register. At the moment we have no idea what might be wrong. Unfortunately, the internet does not reveal much information regarding this issue. In one issue related to Kamailio ( https://lists.kamailio.org/mailman3/hyperkitty/list/sr-users@lists.kamailio…), I found the command `kamctl trap` and when I execute that, I see one issue, which might be related, but I'm just guessing... ``` ---start 1782236 ----------------------------------------------------- [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib/libthread_db.so.1". 0x00007fa14c9fb1c6 in ?? () from /usr/lib/libc.so.6 $1 = 26 $2 = {pid = 1782236, unix_sock = 36, idx = 0, status = 1, rank = 17, desc = "tcp receiver (generic) child=0", '\000' <repeats 97 times>} #0 0x00007fa14c9fb1c6 in ?? () from /usr/lib/libc.so.6 No symbol table info available. #1 0x00007fa14ca04830 in pthread_rwlock_wrlock () from /usr/lib/libc.so.6 No symbol table info available. #2 0x00007fa14ac20b49 in CRYPTO_THREAD_write_lock () from /usr/lib/libcrypto.so.3 No symbol table info available. #3 0x00007fa14adbd5da in ?? () from /usr/lib/libcrypto.so.3 No symbol table info available. #4 0x00007fa14adbd9ca in ?? () from /usr/lib/libcrypto.so.3 No symbol table info available. #5 0x00007fa14adbc907 in ?? () from /usr/lib/libcrypto.so.3 No symbol table info available. #6 0x00007fa14adbd26c in ?? () from /usr/lib/libcrypto.so.3 No symbol table info available. #7 0x00007fa14adbd68e in ?? () from /usr/lib/libcrypto.so.3 No symbol table info available. #8 0x00007fa14abe75c6 in ?? () from /usr/lib/libcrypto.so.3 No symbol table info available. #9 0x00007fa14abe840b in EVP_RAND_generate () from /usr/lib/libcrypto.so.3 No symbol table info available. #10 0x00007fa14acf9282 in RAND_bytes_ex () from /usr/lib/libcrypto.so.3 No symbol table info available. #11 0x00007fa14b06cce8 in ?? () from /usr/lib/libssl.so.3 No symbol table info available. #12 0x00007fa14b05bdf7 in ?? () from /usr/lib/libssl.so.3 No symbol table info available. #13 0x00007fa14b0ef036 in tls_accept (c=c@entry=0x7fa1475c0dc0, error=error@entry=0x7ffebd9443b8) at tls_server.c:457 ret = <optimized out> ssl = warning: could not convert 'ssl_st' from the host encoding (ANSI_X3.4-1968) to UTF-32. This normally should not happen, please file a bug report. 0x7fa147668bd0 cert = <optimized out> tls_c = 0x7fa14768f490 tls_log = <optimized out> __func__ = "tls_accept" #14 0x00007fa14b0f7540 in tls_h_read_f (c=0x7fa1475c0dc0, flags=0x7ffebd9647d0) at tls_server.c:1153 r = 0x7fa1475c0ee8 bytes_free = 16383 bytes_read = <optimized out> read_size = <optimized out> ssl_error = 0 ssl_read = 0 ssl = 0x7fa147668bd0 rd_buf = "\026\003\003\004\016\v\000\004\n\000\004\a\000\004\0040\202\004\0000\202\002\350\240\003\002\001\002\002\002\026\0270\r\006\t*\206H\206\367\r\001\001\v\005\0000b1\v0\t\006\003U\004\006\023\002CH1\r0\v\006\003U\004\b\f\004Bern1\r0\v\006\003U\004\a\f\004Bern1\r0\v\006\003U\004\n\f\004RUAG1\0200\016\006\003U\004\v\f\aDefence1\0240\022\006\003U\004\003\f\versaimfs.ch0\036\027\r230302163519Z\027\r291230163519Z0`1\v0\t\006\003U\004\006\023\002CH1\r0\v\006\003"... wr_buf = "\026\003\003\000A\002\000\000=\003\003\371\204\326\361\262-9\300\344gV\2316\373\235D\314\225u8\v}\215\254DOWNGRD\001\000\3000\000\000\025\377\001\000\001\000\000\v\000\004\003\000\001\002\000#\000\000\000\027\000\000\026\003\003\a\267\v\000\a\263\000\a\260\000\004\0040\202\004\0000\202\002\350\240\003\002\001\002\002\002\r>0\r\006\t*\206H\206\367\r\001\001\v\005\0000b1\v0\t\006\003U\004\006\023\002CH1\r0\v\006\003U\004\b\f\004Bern1\r0\v\006\003U\004\a\f\004Bern1\r0\v\006\003U\004\n\f\004RUAG1\0200\016\006\003U\004\v\f\aDefence1\0240\022\006"... rd = {buf = 0x7ffebd944480 "\026\003\003\004\016\v", pos = 1405, used = 1405, size = 65536} wr = {buf = 0x7ffebd954480 "\026\003\003", pos = 0, used = 0, size = 65536} tls_c = 0x7fa14768f490 enc_rd_buf = <optimized out> n = 0 flush_flags = 0 err_src = <optimized out> ip_buf = '\000' <repeats 63 times> x = <optimized out> tls_dbg = <optimized out> __func__ = "tls_h_read_f" redo_read = <optimized out> continue_ssl_read = <optimized out> __llevel = <optimized out> __kld = <optimized out> __llevel = <optimized out> __kld = <optimized out> #15 0x000055d2519871b4 in tcp_read_headers (c=c@entry=0x7fa1475c0dc0, read_flags=read_flags@entry=0x7ffebd9647d0) at core/tcp_read.c:445 bytes = <optimized out> remaining = <optimized out> p = <optimized out> r = 0x7fa1475c0ee8 mc = <optimized out> body_len = <optimized out> tvnow = {tv_sec = 1742100857, tv_usec = 944923} tvdiff = <optimized out> mfline = <optimized out> mtransid = <optimized out> __func__ = "tcp_read_headers" #16 0x000055d251989cef in tcp_read_req (con=0x7fa1475c0dc0, bytes_read=bytes_read@entry=0x7ffebd9647c8, read_flags=read_flags@entry=0x7ffebd9647d0) at core/tcp_read.c:1509 bytes = <optimized out> total_bytes = 0 resp = 1 size = <optimized out> req = 0x7fa1475c0ee8 dst = {send_sock = 0x55d251a91020, to = {s = {sa_family = 52024, sa_data = "\257Q\322U\000\000\002\000\000\000\376\177\000"}, sin = {sin_family = 52024, sin_port = 20911, sin_addr = {s_addr = 21970}, sin_zero = "\002\000\000\000\376\177\000"}, sin6 = {sin6_family = 52024, sin6_port = 20911, sin6_flowinfo = 21970, sin6_addr = {__in6_u = {__u6_addr8 = "\002\000\000\000\376\177\000\000\030\000\000\000\000\000\000", __u6_addr16 = {2, 0, 32766, 0, 24, 0, 0, 0}, __u6_addr32 = {2, 32766, 24, 0}}}, sin6_scope_id = 0}, sas = {ss_family = 52024, __ss_padding = "\257Q\322U\000\000\002\000\000\000\376\177\000\000\030", '\000' <repeats 23 times>, "\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\262+\226Q\001 \000\000\200,5L\241\177\000\000 \020\251Q\322U\000\000 \020\251Q\322U\000\000\200\303\257Q\322U\000\00009SG\241\177\000\000\330G\226\275\376\177\000\000\b\000\000\000\000\000\000", __ss_align = 20}}, id = 1, send_flags = {f = 1, blst_imask = 0}, proto = 14 '\016', proto_pad0 = 0 '\000', proto_pad1 = 0} c = <optimized out> ret = <optimized out> again = <optimized out> __func__ = "tcp_read_req" #17 0x000055d25198ebec in handle_io (fm=fm@entry=0x7fa14c352c80, events=events@entry=1, idx=idx@entry=-1) at core/tcp_read.c:1906 ret = 8 n = 0 read_flags = RD_CONN_SHORT_READ con = 0x7fa1475c0dc0 s = 14 resp = <optimized out> t = <optimized out> ee = 0x0 __func__ = "handle_io" error = <optimized out> #18 0x000055d25199469b in io_wait_loop_epoll (repeat=repeat@entry=0, t=2, h=0x55d251c49d60 <io_w>) at core/io_wait.h:1075 n = 1 r = 0 fm = 0x7fa14c352c80 revents = 1 __func__ = "io_wait_loop_epoll" #19 0x000055d251994e87 in tcp_receive_loop (unix_sock=<optimized out>) at core/tcp_read.c:2026 __func__ = "tcp_receive_loop" #20 0x000055d25197e72c in tcp_init_children (woneinit=woneinit@entry=0x7ffebd964d1c) at core/tcp_main.c:5391 r = <optimized out> i = <optimized out> reader_fd_1 = 39 pid = <optimized out> si_desc = "tcp receiver (generic)\000\000`M\226\275\376\177\000\000\001\000\000\000\000\000\000\000\210\035\223Q\322U\000\000 \020\251Q\322U\000\000\220\315\257Q\322U\000\000\220\242/L\241\177\000\000\025\000\000\000\000\000\000\000\004\000\000\000\000\000\000\000%\020\251Q\322U\000\000HU\257Q\322U\000\000e\005\000\000\000\000\000\000 \020\251Q\322U\000\000\3750\235Q\322U\000" si = <optimized out> __func__ = "tcp_init_children" error = <optimized out> #21 0x000055d2517c6c7e in main_loop () at main.c:1950 i = <optimized out> pid = <optimized out> si = <optimized out> si_desc = "udp receiver child=7 sock=10.0.90.1:5060\000\000\000\000\322U\000\000?\342\017K\241\177\000\000\022\000\000\000\377\377\377\377\200\006\265L\241\177\000\000\253m\237L\241\177\000\000\361|\003\000\000\000\000\000\t\000\000\000\000\000\000\000Sat Mar 15 05:25:32 2025\n\000\264L\241\177\000" nrprocs = <optimized out> woneinit = 1 __func__ = "main_loop" error = <optimized out> #22 0x000055d2517bc151 in main (argc=<optimized out>, argv=<optimized out>) at main.c:3256 cfg_stream = <optimized out> c = <optimized out> r = <optimized out> tmp = 0x7ffebd966e7f "" tmp_len = 32673 port = 5060 proto = 0 aproto = 0 ahost = 0x0 aport = 0 options = 0x55d251aa74b8 ":f:cm:M:dVIhEeb:B:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" ret = -1 seed = 3209119183 rfd = <optimized out> debug_save = <optimized out> debug_flag = <optimized out> dont_fork_cnt = 0 n_lst = <optimized out> p = <optimized out> st = {st_dev = 24, st_ino = 46237, st_nlink = 2, st_mode = 16888, st_uid = 899, st_gid = 899, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1742012732, tv_nsec = 217328715}, st_mtim = {tv_sec = 1742012732, tv_nsec = 217328715}, st_ctim = {tv_sec = 1742012732, tv_nsec = 217328715}, __glibc_reserved = {0, 0, 0}} l1 = <optimized out> tbuf = '\000' <repeats 32 times>, "\030\202\237\275\376\177\000\000@ \002\000\000@\003\000\000\001", '\000' <repeats 23 times>, "@\003\000\000@ \003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@ \003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@ \003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@ \003\000\000@\003\000\000@\003\000\000@\003\000\000@\003\000\000@\003", '\000' <repeats 11 times>, "\001", '\000' <repeats 118 times>... option_index = 12 long_options = {{name = 0x55d251a9230b "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x55d251a937a4 "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x55d251a9826a "alias", has_arg = 1, flag = 0x0, val = 1024}, {name = 0x55d251a92310 "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x55d251a92316 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x55d251a9231f "substdefs", has_arg = 1, flag = 0x0, val = 1027}, {name = 0x55d251a92329 "server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x55d251a92333 "loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x55d251a9233e "modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x55d251a92347 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x55d251a938c1 "debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x55d251a92352 "cfg-print", has_arg = 0, flag = 0x0, val = 1033}, {name = 0x55d251a9235c "atexit", has_arg = 1, flag = 0x0, val = 1034}, {name = 0x55d251a92363 "all-errors", has_arg = 0, flag = 0x0, val = 1035}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} __func__ = "main" [Inferior 1 (process 1782236) detached] ---end 1782236 ------------------------------------------------------- ``` Does anybody have an idea what this could be? I never saw that with previous versions, and now we can see it on several instances, but we are yet unable to reproduce. Not sure if this might be related, but we also see many messages like `Mar 17 13:39:03 ttel /usr/sbin/kamailio[2882127]: CRITICAL: <core> [core/tcp_main.c:5558]: tcp_timer_check_connections(): message processing timeout on connection id: 402 (state: 0) - closing` Best regards Mathias

2 6

Kamailio v5.8.6 Released
by Daniel-Constantin Mierla 20 Mar '25

20 Mar '25

Hello, Kamailio SIP Server v5.8.6 stable release is out. This is a maintenance release of the latest stable branch, 5.8, that includes fixes since the release of v5.8.5. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.8.x. Deployments running previous v5.8.x versions are strongly recommended to be upgraded to v5.8.6. For more details about version 5.8.6 (including links and guidelines to download the tarball or from GIT repository), visit: * https://www.kamailio.org/w/2025/03/kamailio-v5-8-6-released/ RPM, Debian/Ubuntu packages will be available soon as well. Note that 5.8.x is currently the previous stable release series, the latest is 6.0.x and v6.0.1 was released on March 10, 2025. Many thanks to all contributing and using Kamailio! Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio Advanced Training, March 24-28, 2025 -- asipto.com Kamailio World Conference, May 12-13, 2025, Berlin -- kamailioworld.com

1 0

Releasing v5.8.6
by Daniel-Constantin Mierla 20 Mar '25

20 Mar '25

Hello, I am considering to release Kamailio v5.8.6 (out of branch 5.8) on Thursday, March 20, 2025. If anyone is aware of issues not yet on the bug tracker, report them there asap in order to have a better chance to be fixed. The most of the commits are backported, should any be found missing, reply to sr-dev mailing list. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com Kamailio Advanced Training, March 24-28, 2025 -- asipto.com Kamailio World Conference, May 12-13, 2025, Berlin -- kamailioworld.com

1 1

Issue with async_cdp_callback() of MAR diameter message
by Minello, Loredana 18 Mar '25

18 Mar '25

Hello, I have an issue during the registration phase with the Diameter MAR procedure. The issue is as follows: 1. I perform a registration. 2. The MAR is correctly sent using the function: ims_www_challenge("REG_MAR_REPLY", "$var(auth_realm)"); 3. Upon receiving the MAA, after executing async_cdp_callback(), the execution does not return to the Kamailio reply route indicated (REG_MAR_REPLY). I tried replacing t_continue with t_continue_skip_timer in the async_cdp_callback() function of the MAR (see below), and everything works correctly. //tmb.t_continue(data->tindex, data->tlabel, data->act); tmb.t_continue_skip_timer(data->tindex, data->tlabel, data->act); free_saved_transaction_data(data); return; Note: When I send the SAR, I do not have this issue, but I noticed that in the corresponding async_cdp_callback(), the t_continue_skip_timer function is used. Do you think the modification I made to async_cdp_callback() for the MAR is correct? Why does t_continue not work? Thanks.

1 0

dispatcher not distributing well?
by David Villasmil 17 Mar '25

17 Mar '25

Hello guys, i have a kamilio with a dispatcher list in db like +------------------------------------------------+----------------------------------------------+----------------------------+ | id | setid | destination | flags | priority | attrs | description | register_datetime | +------+-------+---------------------+-------+----------+------------------------------+---------------+---------------------+ | 3239 | 430 | sip:gateway-08:5080 | 0 | 10 | duid=gateway-08;weight=50 | gateway-08 | 2023-03-21 00:19:44 | | 3246 | 430 | sip:gateway-11:5080 | 0 | 10 | duid=gateway-11;weight=50 | gateway-11 | 2023-05-15 23:00:28 | | 3247 | 430 | sip:gateway-12:5080 | 0 | 10 | duid=gateway-12;weight=50 | gateway-12 | 2023-05-15 23:06:57 | | 3249 | 430 | sip:gateway-14:5080 | 0 | 10 | duid=gateway-14;weight=50 | gateway-14 | 2023-05-15 23:24:44 | | 3276 | 430 | sip:gateway-15:5080 | 0 | 10 | duid=gateway-15;weight=50 | gateway-15 | 2024-05-01 19:43:19 | | 3277 | 430 | sip:gateway-16:5080 | 0 | 10 | duid=gateway-16;weight=50 | gateway-16 | 2024-05-01 19:51:16 | | 3278 | 430 | sip:gateway-1:5080 | 0 | 10 | duid=gateway-17;weight=50 | gateway-17 | 2024-05-01 19:58:13 | | 3279 | 430 | sip:gateway-17:5080 | 0 | 10 | duid=gateway-18;weight=50 | gateway-18 | 2024-05-01 20:06:44 | | 3280 | 430 | sip:gateway-3:5080 | 0 | 10 | duid=gateway-19;weight=50 | gateway-19 | 2024-05-01 20:14:50 | | 3281 | 430 | sip:gateway-2:5080 | 0 | 10 | duid=gateway-20;weight=50 | gateway-20 | 2024-05-01 20:23:25 | +------+-------+---------------------+-------+----------+------------------------------+---------------+---------------------+ and i'm dispatching with if(!ds_select_dst("$var(dispatcher_id)", "10")) { xlog("[DISPATCH]: ds_select_dst FAILED!'\n"); send_reply("404", "No destination"); exit; } still kamailio isn't distributing at all but for some reason is favoring high-description gateways: kamctl rpc dlg.list 5 gateway-20:5080;transport=udp" 2 gateway-19:5080;transport=udp" it's forwarding calls mostly to gateway-20, gateway-19, gateway-18, gateway-17... in descending order... Why is kamailio doing that? i'd expected it to distribute to all based on the call load on each gateway. Thanks all! Regards, David Villasmil email: david.villasmil.work(a)gmail.com

3 4

Recommendations for paid work
by Anthony Ford 14 Mar '25

14 Mar '25

Hi Can anyone recommend someone that can help us upgrade our 2 Kamailio servers please. After several failed attempts to do this ourselves, it is time to call in the professionals. 5.6.0-dev to the latest The current set up is 2 servers working in tandem, redis and mysql plus nebula. We do have a test server also attached, that can be used for testing. Thanks Tony

6 5

add_contact_alias modifies only one Contact address
by James Browne 13 Mar '25

13 Mar '25

- https://kamailio.org/docs/modules/5.8.x/modules/nathelper.html#nathelper.f.… This add_contact_alias() function changes only the first Contact address in a REGISTER request, even though it's normal (RFC3261, 10.2) for a REGISTER to have multiple Contact addresses. This seems to me to be a kamailio bug. For example, a user might remove one binding while adding a second, in a REGISTER request. If kamailio relays this while adding an alias to only the expires=0 binding, then the new binding may be stored incorrectly in the registrar. James

2 4

Server selecting TCP transport
by Jon Bonilla (Manwe) 13 Mar '25

13 Mar '25

Hi all Using 5.8.4 I have a trunk with a permanent registration created by rpc in the location table. It looks like this: kamcmd> ul.lookup location sbc.mydomain.com { AoR: sbc.mydomain.com Contacts: { Contact: { Address: sip:xxx@sbc.mydomain.com Expires: -102739 Q: 1 Call-ID: dfjrewr12386fd6-343(a)kamailio.rpc CSeq: 1 User-Agent: kamailio SIP Router - RPC Server Received: [not set] Path: <sip:192.168.255.202:5060;lr> State: CS_SYNC Flags: 0 CFlags: 0 Socket: [not set] Methods: 0 Ruid: ulcx-67c9e2ff-19f8-1 Instance: [not set] Reg-Id: 0 Server-Id: 0 Tcpconn-Id: -1 Keepalive: 0 Last-Keepalive: 1741899218 KA-Roundtrip: 0 Last-Modified: 0 } } } In this situation the proxy sends the request to 192.168.255.202 which is a kamailio load balancer which is responsible for sending the call to the customer. The problem is that kamailio, when relaying this request, first performs TCP srv lookup and tries to send the request via TCP. There's no transport=tcp in the address. The lb's dns settings are: dns_try_ipv6=no dns_retr_time=1 dns_retr_no=1 dns_use_search_list=no use_dns_cache=on use_dns_failover=on dns_srv_lb=on dns_try_naptr=no dns_sctp_pref=1 dns_tcp_pref=1 dns_tls_pref=1 dns_udp_pref=1 Seems like this kamailio tries TCP SRV first, and then TLS and then UDP if the previous doesn't bring results. But no NAPTR is enabled. I don't know why it will choose TCP over UDP in this case. -- PekePBX, the multitenant PBX solution https://pekepbx.com

1 0

SDP Truncation When Relaying from WebSocket to UDP – Expected Behavior?
by Pavan Kumar 13 Mar '25

13 Mar '25

Hello Kamailio Community, I recently encountered an interesting behavior when using Kamailio to relay SIP messages from a WebSocket client to FreeSWITCH over UDP. *Observed Behavior:* - The WebSocket client sends an *INVITE* with a large SDP. - Kamailio forwards this request over UDP to FreeSWITCH. - Upon inspection, the *SDP in the relayed message appears truncated*. (Probably MTU limit) - *Surprisingly, the call still establishes successfully*, and there are no noticeable issues with audio or call setup. *My Questions:* 1. *Is this expected behavior?* Should Kamailio automatically truncate SDP when relaying from WebSocket to UDP? 2. *Could this be working accidentally?* For example, is FreeSWITCH handling the partial SDP gracefully by default? 3. *Should I be concerned about potential failures in different scenarios?* (e.g., ICE candidate loss, missing codec negotiation) I would appreciate any insights from the community on whether this is a known or expected behavior in Kamailio, or if it might be a configuration issue. Thanks in advance for your help! Best regards, Pavan Kumar

4 5

Need help using Kamailio IMS and Open5GS for 5G core
by Pete Kay 13 Mar '25

13 Mar '25

Hi I am able to compile Kamailio IMS and Open5GS. The instruction in https://open5gs.org/open5gs/docs/tutorial/02-VoLTE-setup/ is for 4G using Diameter. For 5G, we need to use HTTP protocol. Does anyone know if there is any guide on how to configure Kamailio IMS and Open5GS on 5G core using HTTP protocol for PCRF ? Thanks for millions for all your help. Pete

2 1

Re: upgrading process
by Anthony Ford 12 Mar '25

12 Mar '25

Thanks Ben Really appreciate your response Tony From: Ben Kaufman via sr-users <sr-users(a)lists.kamailio.org> Reply to: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org> Date: Wednesday, 12 March 2025 at 16:20 To: "sr-users(a)lists.kamailio.org" <sr-users(a)lists.kamailio.org> Cc: Ben Kaufman <bkaufman(a)bcmone.com> Subject: [SR-Users] Re: upgrading process Luckily there usually aren't a lot of breaking changes in Kamailio updates, and config files are mostly back compatible. That doesn't mean that there are never changes, but it does mean that the number of issues to resolve is usually small. * wanted to know if I can run make install on every iteration i.e. 5.6.1, the 5.6.2 etc There shouldn't really be any changes needed to config for the patch/fix versions like that (third decimal place) so those should be fine (and is good practice if you're not able to quickly update to a supported version for any reason), but it shouldn't be necessary to touch every incremental version to upgrade Kamailio. Every major release has an upgrade guide from the pervious version, so in your case: * 5.6 to 5.7: https://www.kamailio.org/wikidocs/install/upgrade/5.6.x-to-5.7.0/ * 5.7 to 5.8: https://www.kamailio.org/wikidocs/install/upgrade/5.7.x-to-5.8.0/ * 5.8 to 6.0: https://www.kamailio.org/wikidocs/install/upgrade/5.8.x-to-6.0.0/ It still shouldn't be necessary to touch each individual version while upgrading. I'd recommend reading through these docs in order taking note of the following: * Look for potentially breaking changes in the core. I don't see any in those documents, but a good example would be if upgrading from 4.x to 5.x how fifo was deprecated. * Look for modules changes. Mostly you'll see things like new features which shouldn't be breaking. A few modules were deprecated/archived in 5.8 ( app_sqlang, and auth_identity). Sometimes modules have small breaking changes in them as well, for example in 6.0 the dialog module dropped support for the dlg_flag parameter. Check your kamailio configs to see if any of these listed changes will impact you. * Follow any DB upgrade changes. These are usually simple changes - things like adding an index to a column, or changing a varchar(n) datatype to be varchar(n+y) which won't break your existing config. Another reply correctly points out that you should watch for changes to the version table. This is possibly a situation where a conflict could arise: The version required for one table might be 1 in 5.6 and 2 in 6.0. It might be worth while to copy the existing version table to a new table (like version_60 for example), and use kamailio's version_table parameter to use the new version table on the updated config. (note: The upgrade guides don't show any table version changes, so you probably don't need to do this). Finally, as a recommendation, smoke test your config in docker. You might not have the container setup in a way to actually receive SIP messages, but "does the config file load correctly" is a nice thing to have resolved ahead of time. * Regards, Kaufman ________________________________ From: Anthony Ford via sr-users <sr-users(a)lists.kamailio.org> Sent: Wednesday, March 12, 2025 9:30 AM To: sr-users(a)lists.kamailio.org <sr-users(a)lists.kamailio.org> Cc: Anthony Ford <tony.ford(a)apalo.co.uk> Subject: [SR-Users] upgrading process CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi I need some help please. I am very inexperienced with Kamailio, and am trying to work out how to upgrade without rewriting any of the current config. I am going from 5.6.0 to 6.0.0 and wanted to know if I can run make install on every iteration i.e. 5.6.1, the 5.6.2 etc. until I need to make a bigger step, and may have to change tables etc. In the document for upgrading 5.6.x to 5.7.x it says make change to Watch table, but I have no watch table. Very confused. Thanks Tony

1 0

CANCEL suspension and forking
by Alex Balashov 12 Mar '25

12 Mar '25

Hi, When a CANCEL is received and matches a known INVITE transaction, it is forked to all existing branches of that INVITE transaction, at least with these settings: modparam("tm", "cancel_b_method", 2) modparam("tm", "failure_reply_mode", 3) I have a mobile endpoint that is slow to be pushed awake and reregister, tsilo-style, and by the time it finally appears on the scene, the underlying INVITE transaction has been terminated. Accordingly, that endpoint receives no CANCEL. You might ask why that's a problem, if it also didn't receive a forked INVITE. The problem is that Apple's CallKit requires interactive presentation of VoIP APNS notifications as though they are "calls", leading to the phenomenon of what might be called "ghost calls" extrinsically to the actual mobile application. Anyway, I am aware of numerous possible solutions to this problem in principle; most involve sending an out-of-band SIP message to signify an alternative cancellation of the call. However, wonder if I am missing some best-practical approach, perhaps through an overlooked TM facility, or some way of keeping the transaction alive longer than the CANCEL from the UAC would ordinarily require? I don't see how that would work, but thought better to ask. Thanks! -- Alex -- Alex Balashov Principal Consultant Evariste Systems LLC Web: https://evaristesys.com Tel: +1-706-510-6800

3 4

upgrading process
by Anthony Ford 12 Mar '25

12 Mar '25

Hi I need some help please. I am very inexperienced with Kamailio, and am trying to work out how to upgrade without rewriting any of the current config. I am going from 5.6.0 to 6.0.0 and wanted to know if I can run make install on every iteration i.e. 5.6.1, the 5.6.2 etc. until I need to make a bigger step, and may have to change tables etc. In the document for upgrading 5.6.x to 5.7.x it says make change to Watch table, but I have no watch table. Very confused. Thanks Tony

3 3

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