sr-users January 2025

sr-users@lists.kamailio.org

40 participants
45 discussions

Kamailio crash
by Mitesh Thakkar 07 Jan '25

07 Jan '25

Hi, I have recently migrated from Kamailio 5.2.5 to Kamailio 5.5.7. After a migration, the Kamailio crashed. Find the details below. Thanks in advance. Back trace: ========= Core was generated by `/usr/local/sbin/kamailio -DD -E -m 1941 -M 970 -f /etc/kamailio/kamailio.cfg --'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f8e27a2be15 in OPENSSL_cleanse () from /lib/x86_64-linux-gnu/libcrypto.so.3 (gdb) bt #0 0x00007f8e27a2be15 in OPENSSL_cleanse () from /lib/x86_64-linux-gnu/libcrypto.so.3 #1 0x00007f8e278faa8a in CRYPTO_clear_free () from /lib/x86_64-linux-gnu/libcrypto.so.3 #2 0x00007f8e27838175 in BUF_MEM_free () from /lib/x86_64-linux-gnu/libcrypto.so.3 #3 0x00007f8e27bc0c98 in SSL_free () from /lib/x86_64-linux-gnu/libssl.so.3 #4 0x00007f8e27c8cd6e in tls_h_tcpconn_clean_f (c=0x7f8db0fa1e90) at tls_server.c:701 #5 0x000055f7f42cc6e1 in _tcpconn_free (c=0x7f8db0fa1e90) at core/tcp_main.c:1541 #6 0x000055f7f42e2f3c in tcpconn_put_destroy (tcpconn=0x7f8db0fa1e90) at core/tcp_main.c:3285 #7 0x000055f7f42e8759 in handle_tcp_child (tcp_c=0x7f8e27d88078, fd_i=-1) at core/tcp_main.c:3722 #8 0x000055f7f42f506f in handle_io (fm=0x7f8e27db1578, ev=1, idx=-1) at core/tcp_main.c:4539 #9 0x000055f7f42b6e49 in io_wait_loop_epoll (h=0x55f7f45ae240 <io_h>, t=5, repeat=0) at core/io_wait.h:1070 #10 0x000055f7f42f8bc3 in tcp_main_loop () at core/tcp_main.c:4824 #11 0x000055f7f4057fc2 in main_loop () at main.c:1856 #12 0x000055f7f4062670 in main (argc=10, argv=0x7ffc6d583528) at main.c:3052 OS: Ubuntu 22.04.5 LTS \n \l # kamailio --version version: kamailio 5.5.7 (x86_64/linux) 272fdd 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: 272fdd compiled on 14:21:35 Oct 21 2024 with gcc 11.4.0 # dpkg -l |grep openssl ii openssl 3.0.2-0ubuntu1.18 amd64 Secure Sockets Layer toolkit - cryptographic utility Regards.

3 3

children monitoring
by Sergey Safarov 06 Jan '25

06 Jan '25

If TCP children are busy, Please correct me if I am wrong if the remote IP is not responding via TCP protocol, this leads to a timeout and this child is busy. If many remote endpoints are not reachable via TCP this can lead to the case when half or more children are by timeout operations. I think required to monitor how many children are busy. Is it possible to get such info using kamcmd utility, statistics module, or xprom module. Sergey

4 7

Crash on dialog_publish.
by satyaprakash ch 06 Jan '25

06 Jan '25

Hi, The kamailio version we are using is "5.7.4", We are facing a kamailio crash recently and it has generated the core-dump. Below is the backtrace for the coredump. Could you please assist with this crash. *Bachtrace:* #0 0x00007fa6b051748a in dialog_publish (state=0x7fa6b0519505 "terminated", ruri=0x7069734030783532, entity=0x7ffcdfb16510, peer=0x7ffcdfb16520, callid=0x7fa5b0527cb8, initiator=1, lifetime=10, localtag=0x0, remotetag=0x0, localtarget=0x7fa5b0527ce8, remotetarget=0x7ffcdfb16500, do_pubruri_localcheck=0, uuid=0x7fa5b0527d18) at dialog_publish.c:302 body = 0x0 uri = {s = 0x0, len = 0} publ = 0x0 size = 0 content_type = {s = 0x0, len = -1288318368} ruri_uri = {user = {s = 0x0, len = 0}, passwd = {s = 0x0, len = 0}, host = {s = 0x0, len = 0}, port = {s = 0x0, len = 0}, params = {s = 0x0, len = 0}, sip_params = {s = 0x0, len = 0}, headers = {s = 0x0, len = 0}, port_no = 0, proto = 0, type = ERROR_URI_T, flags = (unknown: 0), transport = {s = 0x0, len = 0}, ttl = {s = 0x0, len = 0}, user_param = {s = 0x0, len = 0}, maddr = {s = 0x0, len = 0}, method = {s = 0x0, len = 0}, lr = {s = 0x0, len = 0}, r2 = {s = 0x0, len = 0}, gr = {s = 0x0, len = 0}, transport_val = {s = 0x0, len = 0}, ttl_val = {s = 0x0, len = 0}, user_param_val = {s = 0x0, len = 0}, maddr_val = {s = 0x0, len = 0}, method_val = {s = 0x0, len = 0}, lr_val = {s = 0x0, len = 0}, r2_val = {s = 0x0, len = 0}, gr_val = {s = 0x0, len = 0}} __func__ = "dialog_publish" #1 0x00007fa6b0518f89 in dialog_publish_multi (state=0x7fa6b0519505 "terminated", ruris=0x7069734030783532, entity=0x7ffcdfb16510, peer=0x7ffcdfb16520, callid=0x7fa5b0527cb8, initiator=1, lifetime=10, localtag=0x0, remotetag=0x0, localtarget=0x7fa5b0527ce8, remotetarget=0x7ffcdfb16500, do_pubruri_localcheck=0, uuid=0x7fa5b0527d18) at dialog_publish.c:412 __func__ = "dialog_publish_multi" #2 0x00007fa6b0506944 in __dialog_sendpublish (dlg=0x7fa5b046a850, type=64, _params=0x7fa6b0437620 <params>) at pua_dialoginfo.c:402 tag = {s = 0x0, len = 0} uri = { s = 0x7fa5b0527d41 "sip:+1248XXXXXXX@10.XXX.X.Xm6ka0542f9v0lmjjc4npkamailio954739148rdb2847sip :XXXXXX.com:5060sip:521XXXx0;tgrp=51;trunk-context=198.X.XXX.XXX@10.XXX.XX.XX:5060padi-6761ad46-154e-1560padi\300\300\300\300", len = 29} identity_local = { s = 0x7fa5b0527d28 "sip:413XXXx0@10.XXX.X.XXsip :+1248XXXXXXXX@10.XXX.X.XXm6ka0542f9v0lmjjc4npkamailio954739148rdb2847sip :XXXXXX.com:5060sip:415XXXx0;tgrp=51;trunk-context=198.X.XXX.XXX@10.XXX.XX.XX:5060padi-6761ad46-154e-"..., len = 25} target = {s = 0x0, len = 0} dlginfo = 0x7fa5b0527c90 request = 0x7fa6b3361b58 __func__ = "__dialog_sendpublish" Thanks.

1 2

record_route() adding wrong sips URI when transport is missing (defaulting to UDP)
by Benoit Panizzon 06 Jan '25

06 Jan '25

Hi Gang A quick search via google did not reveal any useful hits. Kamailio 5.7.6 CPE (TLS) => SBC (UDP) => Registrar (UDP) => Core CPE uses a sips contact URI to register, no transport attribute! sips:315996608@172.29.255.11:5061 SBC uses Path functionality. Situation: Call to CPE I see the registrar adding this Record-Route: Record-Route: <sips:registrar-ip;lr;ftag=6159862378> The SBC is adding a r2=on Record-Route to indicate the change between UDP and TLS. The Route-Set received by the CPE then is: INVITE sips:315996608@172.29.255.11:5061 SIP/2.0 Record-Route: <sips:sbc-ip:5061;transport=tls;r2=on;lr;ftag=6159862378> Record-Route: <sips:sbc-ip;r2=on;lr;ftag=6159862378> Record-Route: <sips:registrar-ip;lr;ftag=6159862378> Record-Route: <sip:core-ip;lr;ftag=6159862378> 180 Ringing req 100rel is making it back as the Via header look right. But when the remote side is sending a PRACK, is has to follow the Routeset which if I am not mistaking, is not making it back because because the CORE does not know how to send this via TLS to the Registrar. Core logging: prepare_new_uac(): can't fwd to af 2, proto 3 (no corresponding listening socket) IMHO already the 2nd Record-Route added by the Registrar should not contain a sips: URI but a sip: URI (reflecting the transport attribute not being present, defaulting to UDP) Is this a known issue? Mit freundlichen Grüssen -Benoît Panizzon- -- I m p r o W a r e A G - Leiter Commerce Kunden ______________________________________________________ Zurlindenstrasse 29 Tel +41 61 826 93 00 CH-4133 Pratteln Fax +41 61 826 93 01 Schweiz Web http://www.imp.ch ______________________________________________________

3 4

Guidance Required for Kamailio Load Balancer Behavior in Attended Transfer Scenarios
by Kotappa Gandudi 03 Jan '25

03 Jan '25

Dear Kamailio Team, I hope this email finds you well. I am currently working on a project where Kamailio is being utilized as a load balancer to distribute calls across multiple FreeSWITCH instances. I am using the round-robin technique for load distribution, and it is working perfectly for regular call scenarios. However, I am encountering an issue when handling attended transfer calls. Specifically, for a normal call, Kamailio assigns one FreeSWITCH instance, but during the attended transfer call, it assigns another FreeSWITCH instance. This behavior disrupts the continuity of the call handling. My requirement is for Kamailio to use the same FreeSWITCH instance for the entire call, including any attended transfers. I believe maintaining the same FreeSWITCH instance for the entire call flow would ensure consistency and avoid potential issues. Could you please guide me on how to configure Kamailio to achieve this behavior? I would greatly appreciate any suggestions, configurations, or modules that can help resolve this issue. Thank you for your time and assistance. Looking forward to your response. Best regards, Kotappa Y Gandudi

4 4

2026

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 January 2025