sr-users January 2025

sr-users@lists.kamailio.org

37 participants
34 discussions

Module snmpstats reporting inconsistent call success metrics on intense peaks of failed calls

by Igor Potjevlesch

Hello! We are plotting the call success rate on each of our proxies. Using the Kamailio snmpstats module, we try to obtain three counters to plot them on a graph: Total Calls Active Calls Error Calls Most of the time, everything works well, and we obtain sensible values: snmpwalk -c mycommunity -v 2c W.X.Y.Z 1.3.6.1.4.1.34352.3.1.3.1.3.2 -O n .1.3.6.1.4.1.34352.3.1.3.1.3.2.1.0 = Gauge32: 309 -> Total Calls .1.3.6.1.4.1.34352.3.1.3.1.3.2.2.0 = Gauge32: 95 -> Active Calls .1.3.6.1.4.1.34352.3.1.3.1.3.2.3.0 = Gauge32: 214 -> Error calls However, when our proxies are facing intense peaks of failed calls in a short time span, sometimes, the "Error Calls" counter returns a value higher than "Total Calls". As a result, "Active Calls" suddenly reaches a value close to the maximum of a Gauge32 (because T o t a l C a l l s − E r r o r C a l l s < 0 ). snmpwalk -c mycommunity -v 2c W.X.Y.Z 1.3.6.1.4.1.34352.3.1.3.1.3.2 -O n .1.3.6.1.4.1.34352.3.1.3.1.3.2.1.0 = Gauge32: 153 -> Total Calls .1.3.6.1.4.1.34352.3.1.3.1.3.2.2.0 = Gauge32: 4294967226 -> Active Calls .1.3.6.1.4.1.34352.3.1.3.1.3.2.3.0 = Gauge32: 223 -> Error calls As a result, our graphs make no more sense. We are currently running kamailio 5.6.4. Any idea if it's a bug or a configuration issue? Regards, Igor. -- Cet e-mail a été vérifié par le logiciel antivirus d'Avast. www.avast.com

3 weeks

Branching 6.0 series

by Daniel-Constantin Mierla

Hello, I am trying to figure out what would be the best date to branch 6.0 in the git repo. To allow a bit of time after returning from the winter holidays to tune more the cmake and packaging, I would think that January 15, 2025 could be a good choice. If nobody comes with other opinions/suggestions, then we will go for it. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com

3 weeks

kamcmd tls.reload issue

by Yuriy Nasida

Hello, I am using letsencrypt cert and key and do not want to restart kamailio every 3 months to load new ones. I know that there is: kamcmd tls.reload method but it has an error for me. error: 500 - Error while fixing TLS configuration (consult server log) I am checking the logs and see: kamailio[3865480]: INFO: tls [tls_domain.c:345]: ksr_tls_fill_missing(): TLSs<default>: tls_method=3 kamailio[3865480]: INFO: tls [tls_domain.c:357]: ksr_tls_fill_missing(): TLSs<default>: certificate='/etc/kamailio/certs/my_cert.crt' kamailio[3865480]: INFO: tls [tls_domain.c:364]: ksr_tls_fill_missing(): TLSs<default>: ca_list='(null)' kamailio[3865480]: INFO: tls [tls_domain.c:371]: ksr_tls_fill_missing(): TLSs<default>: ca_path='(null)' kamailio[3865480]: INFO: tls [tls_domain.c:378]: ksr_tls_fill_missing(): TLSs<default>: crl='(null)' kamailio[3865480]: INFO: tls [tls_domain.c:382]: ksr_tls_fill_missing(): TLSs<default>: require_certificate=0 kamailio[3865480]: INFO: tls [tls_domain.c:390]: ksr_tls_fill_missing(): TLSs<default>: cipher_list='(null)' kamailio[3865480]: INFO: tls [tls_domain.c:397]: ksr_tls_fill_missing(): TLSs<default>: private_key='/etc/kamailio/certs/private.key' kamailio[3865480]: INFO: tls [tls_domain.c:401]: ksr_tls_fill_missing(): TLSs<default>: verify_certificate=0 kamailio[3865480]: INFO: tls [tls_domain.c:406]: ksr_tls_fill_missing(): TLSs<default>: verify_depth=9 kamailio[3865480]: INFO: tls [tls_domain.c:410]: ksr_tls_fill_missing(): TLSs<default>: verify_client=0 kamailio[3865480]: NOTICE: tls [tls_domain.c:1168]: ksr_tls_fix_domain(): registered server_name callback handler for socket [:0], server_name='<default>' ... kamailio[3865480]: ERROR: tls [tls_domain.c:590]: load_cert(): TLSs<default>: Unable to load certificate file '/etc/kamailio/certs/my_cert.crt' kamailio[3865480]: ERROR: tls [tls_util.h:49]: tls_err_ret(): load_cert:error:03000072:digital envelope routines::decode error (sni: unknown) kamailio[3865480]: ERROR: tls [tls_util.h:49]: tls_err_ret(): load_cert:error:0A00018F:SSL routines::ee key too small (sni: unknown) Any advice ? It's interesting that there are not any errors in case I restart kamailio. I can make TLS calls without problems. deb 12.5 version: kamailio 5.7.4 (x86_64/linux)

3 weeks

FOSDEM VoIP Dinner

by Torrey Searle

Hello all, As in previous years, I'm organising the VoIP dinner for FOSDEM (1 Feb @ 19:00) However unlike previous years (since the restaurant got upset about splitting the bill 30 ways). I will ask everyone to order their meal and pay in advance. (and I will pay the bill to the restaurant with my card) If you are wanting to attend the dinner please fill out the following form and follow the instructions for payment. https://form.jotform.com/250012543310033 Contact details are also in the form if you want to reach out to me with any further questions. Kind regards Torrey

3 weeks

ims_diameter_server not freeing shared memory

by marpett365＠gmail.com

Hi, I have run in to an issue when sending diameter requests using the ims_diameter_server module. Shared memory keeps increasing and are not being freed until restart of kamailio. This leads to all shared memory is being used and no more are able to be allocated. This only happens when the request is sent synchronously. When sent asynchronously shared memory is being freed as far as I can see. have anyone ran into this issue and found a remedy or can give some pointers how to proceed? Following functions have been used for sending requests. diameter_request([peer], appid, commandcode, message) diameter_request_async([peer], appid, commandcode, message) route[CHECK_LOCATION] { diameter_request("hss.ims.test.local", "16777217", "306", "[ " + "{ \"avpCode\":260, \"vendorId\":0, \"Flags\":64, \"list\":[ { \"avpCode\":266, \"vendorId\":0, \"Flags\":64, \"int32\":10415 }, { \"avpCode\":258, \"vendorId\":0, \"Flags\":64, \"int32\":16777217 } ] }, " + "{ \"avpCode\":277, \"vendorId\":0, \"Flags\":64, \"int32\":1 }, " + "{ \"avpCode\":283, \"vendorId\":0, \"Flags\":64, \"string\":\"ims.test.local\"}, " + "{ \"avpCode\":706, \"vendorId\":10415, \"Flags\":192, \"int32\":0 }, " + "{ \"avpCode\":700, \"vendorId\":10415, \"Flags\":192, \"list\": [ { \"avpCode\":601, \"vendorId\":10415, \"Flags\":192, \"string\":\"tel:" + $fU + "\" }]}, " + "{ \"avpCode\":707, \"vendorId\":10415, \"Flags\":192, \"int32\":0 }, " + "{ \"avpCode\":703, \"vendorId\":10415, \"Flags\":192, \"int32\":14 } ]"); xlog("L_INFO", "Sent Diameter request"); } Shared memory after restart kamcmd mod.stats cdp shm Module: cdp { save_peer_applications(779): 144 make_send_pipe(126): 320 dp_add_pid(92): 216 AAAAddRequestHandler(69): 40 cb_add(183): 8 cb_add(177): 32 cdp_sessions_init(178): 8 cdp_sessions_init(173): 8 cdp_sessions_init(165): 1024 cdp_sessions_init(157): 3072 cdp_sessions_init(149): 8 cdp_trans_init(67): 8 cdp_trans_init(60): 24 add_timer(150): 24 add_timer(145): 144 new_peer(77): 16 new_peer(75): 16 new_peer(72): 16 new_peer(69): 80 new_peer(66): 96 new_peer(60): 384 peer_manager_init(84): 8 peer_manager_init(83): 8 peer_manager_init(82): 8 peer_manager_init(79): 8 peer_manager_init(76): 16 worker_init(101): 16 worker_init(94): 128 worker_init(89): 32 worker_init(87): 32 worker_init(84): 8 worker_init(82): 48 timer_cdp_init(182): 8 timer_cdp_init(179): 16 diameter_peer_init_real(137): 8 diameter_peer_init_real(131): 16 diameter_peer_init_real(122): 16 diameter_peer_init_real(115): 8 diameter_peer_init_real(108): 8 diameter_peer_init_real(101): 8 diameter_peer_init_real(94): 8 new_routing_entry(88): 64 parse_dp_config(447): 16 parse_dp_config(348): 8 parse_dp_config(340): 16 parse_dp_config(333): 40 parse_dp_config(326): 144 quote_trim_dup(96): 456 new_dp_config(52): 184 Total: 7024 } Shared memory after 10 diameter requests Module: cdp { save_peer_applications(779): 144 AAACreateAVP(137): 5072 AAATranslateMessage(500): 1320 do_receive(600): 7392 make_send_pipe(126): 320 dp_add_pid(92): 216 AAAAddRequestHandler(69): 40 cb_add(183): 8 cb_add(177): 32 cdp_sessions_init(178): 8 cdp_sessions_init(173): 8 cdp_sessions_init(165): 1024 cdp_sessions_init(157): 3072 cdp_sessions_init(149): 8 cdp_trans_init(67): 8 cdp_trans_init(60): 24 add_timer(150): 24 add_timer(145): 144 new_peer(77): 16 new_peer(75): 16 new_peer(72): 16 new_peer(69): 80 new_peer(66): 96 new_peer(60): 384 peer_manager_init(84): 8 peer_manager_init(83): 8 peer_manager_init(82): 8 peer_manager_init(79): 8 peer_manager_init(76): 16 worker_init(101): 16 worker_init(94): 128 worker_init(89): 32 worker_init(87): 32 worker_init(84): 8 worker_init(82): 48 timer_cdp_init(182): 8 timer_cdp_init(179): 16 diameter_peer_init_real(137): 8 diameter_peer_init_real(131): 16 diameter_peer_init_real(122): 16 diameter_peer_init_real(115): 8 diameter_peer_init_real(108): 8 diameter_peer_init_real(101): 8 diameter_peer_init_real(94): 8 new_routing_entry(88): 64 parse_dp_config(447): 16 parse_dp_config(348): 8 parse_dp_config(340): 16 parse_dp_config(333): 40 parse_dp_config(326): 144 quote_trim_dup(96): 456 new_dp_config(52): 184 Total: 20808 } Shared memory after 170k requests do_receive(600): 131363752 AAATranslateMessage(500): 32326656 AAACreateAVP(137): 110067152 Total: 273764840 Br Martin

3 weeks, 5 days

evapi not processing received messages

by Sergio Charrua

Hi all! I have implemented evapi module on Kamailio 5.8.4, calling a python script. Python script is listening to a socket. It receives messages (JSON) from Kamailio, makes an HTTP request somewhere, and sends the response back to Kamailio. The Python script is working fine: it connects to Kamailio, sends HTTP requests, and forwards a response back to Kamailio: I have confirmed using TCPDump that, in fact, the data is received and forwarded back. However, despite showing messages that the Python client script is correctly connected to Kamailio, the event_route[evapi:message-received] is never executed. Probably there is some detail that I am missing, but the docs and online info for evapi are very rare, and they all show very similar configuration. And as I wrote, I have confirmed using TCPDump that the data is received from Python client script to Kamailio node. What am I missing? This is my Kamailio cfg: [loads modules] [sets modparams] modparam("evapi","bind_addr","10.20.20.1:8888") debug=2 children=16 log_facility=LOG_LOCAL0 log_prefix="{$mt $hdr(CSeq) $ci} " disable_sctp = yes force_rport = yes rundir="/tmp" request_route { if ( is_method("ACK") ) { if ( t_check_trans() ) { t_relay(); } exit; } if(is_method("OPTIONS")){ sl_reply("200", "OK"); exit; } if(is_method("CANCEL")){ sl_reply("200","OK"); sl_reply("487","Request Terminated"); exit; } route(TOEVAPI); exit; } event_route[evapi:connection-new] { xlog("LINFO","new connection from [$evapi(srcaddr):$evapi(srcport)]\n"); if($evapi(srcaddr)!="10.20.0.1") { evapi_close(); exit; } } event_route[evapi:connection-closed] { xlog("LINFO","connection closed by $evapi(srcaddr):$evapi(srcport)\n"); } event_route[evapi:message-received] { xlog("LINFO","received [$evapi(msg)] from $evapi(srcaddr):$evapi(srcport)\n"); jansson_get("t-index", "$evapi(msg)", "$var(t-index)"); jansson_get("t-label", "$evapi(msg)", "$var(t-label)"); $var(evmsg) = $evapi(msg); xlog("L_INFO", "preparing to resume transaction for processing: $var(tindex) / $var(tlabel)\n"); t_continue("$var(tindex)", "$var(tlabel)", "EVAPIRESPONSE"); } route[EVAPIRESPONSE] { xlog("L_INFO", "resumed transaction for processing: $T(id_index) / $T(id_label)\n"); [do stuff] } route[TOEVAPI]{ xlog("L_INFO", "suspended transaction: $T(id_index) / $T(id_label)\n"); evapi_async_relay( [some JSON string] ); exit; } Thanks in advance! Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua*

3 weeks, 5 days

Kamailio and Faxing

by Temilolu Fayomi

Hello, I am having some issues ensuring t38 faxes are being received reliably. I am currently using kamailio as an inbound sbc with freepbx as the endpoint. I understand that potentially stripping other codecs except for g711a/u makes inbound faxes reliable, but beyond that I am having trouble determining how to ensure reliable faxing. Is this something kamailio can handle (such as an error correction mode or pass through setting or module?) I would appreciate any insight as I have hit a wall when it comes to this issue. Thank you, Temi

3 weeks, 6 days

Re: WS and rtpengine_manage

by Knserbrave

test

3 weeks, 6 days

deb-archive.kamailio.org unreachable

by Floimair Florian

Hi! It seems that deb-archive.kamailio.org is currently down. It resolves to IP 76.9.245.162 on my system Can someone with access to that please have a look. Thank you FLORIAN FLOIMAIR Software Development - Symphony Cloud Services Commend International GmbH Saalachstrasse 51 5020 Salzburg, Austria [signature_2459749227] commend.com LG Salzburg / FN 178618z

4 weeks

Kamailio crash

by Mitesh Thakkar

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.

4 weeks

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