sr-users

sr-users@lists.kamailio.org

36 participants
37509 discussions

Kamailio IMS, used with IPv6?
by Valentin Christoph 16 Jan '25

16 Jan '25

Anybody experiences with Kamailio IMS modules (ims_registrar_scscf, ims_usrloc_scscf, ims_isc, ........) and the use of IPv6 addresses? Any pitfalls? DNS issues? Thanks, Christoph

2 2

Asynchttp failover
by Sergio Charrua 15 Jan '25

15 Jan '25

Hello all! just wondering if anyone knows a good way to failover with the HTTP Async module. The standard HTTP Client module (synchronous) does implement some nice functionalities for failover between URL addresses, but the HTTP Async doesn't have any failover functionality... I have implemented some functions (within kamailio.cfg) for failover upon HTTP requests, but despite it working fine, it would be better to have that functionality on the HTTP Async module, just like HTTP Client has... Any technical reason for HTTP Async module not having failover functionalities? Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua*

2 2

Module snmpstats reporting inconsistent call success metrics on intense peaks of failed calls
by Igor Potjevlesch 15 Jan '25

15 Jan '25

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 7

Branching 6.0 series
by Daniel-Constantin Mierla 15 Jan '25

15 Jan '25

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

1 1

kamcmd tls.reload issue
by Yuriy Nasida 14 Jan '25

14 Jan '25

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)

4 5

FOSDEM VoIP Dinner
by Torrey Searle 14 Jan '25

14 Jan '25

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

5 4

ims_diameter_server not freeing shared memory
by marpett365＠gmail.com 09 Jan '25

09 Jan '25

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

2 5

evapi not processing received messages
by Sergio Charrua 09 Jan '25

09 Jan '25

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 6

Kamailio and Faxing
by Temilolu Fayomi 09 Jan '25

09 Jan '25

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 3

Re: WS and rtpengine_manage
by Knserbrave 08 Jan '25

08 Jan '25

test

2 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