- sr-users - kamailio.org

Error when sending NOTIFYs to disconnected websocket clients
by Flavio Grossi 20 Jan '25

20 Jan '25

Hi, i have some SIP websocket clients (built using the SIP.js library) SUBSCRIBEd to other clients via kamailio v5.8.2. If one of the watchers suddenly disappears (e.g. the web page is reloaded), another connection is made and a new watcher appears in kamailio without the old one disappearing. For example: # kamctl rpc presence.watcher_list basic sip:1001@example.voismart.com { "jsonrpc": "2.0", "result": [ { "pres_uri": "sip:1001@example.com", "to_user": "1001", "watcher_user": "1000", "contact": "sip:1000@mfp0h2dhhmq2.invalid;transport=ws;alias=192.168.56.10~34166~5", "callid": "1o9b499kj6l65if0p30t", "user_agent": "sip.js/1.12.1", "expires": 1736422494, ... }, { "pres_uri": "sip:1001@example.com", "to_user": "1001", "watcher_user": "1000", "contact": "sip:1000@0j7qoabnv827.invalid;transport=ws;alias=192.168.56.10~34156~5", "callid": "8mjhrqifgm39up9t2qq3", "user_agent": "sip.js/1.12.1", "expires": 1736422492, ... } ], "id": 11753 } you can see the duplicated watcher in which the old connection is now invalid because the websocket client disappeared. In this situation, issuing a pres_refresh_watchers() call will fail to send any notify (even to the valid connection) because of this error: WARNING: <core> [core/msg_translator.c:3007]: via_builder(): TCP/TLS connection (id: 0) for WebSocket could not be found ERROR: tm [t_msgbuilder.c:1423]: assemble_via(): via building failed ERROR: tm [t_msgbuilder.c:1614]: build_uac_req(): error while assembling Via ERROR: tm [uac.c:552]: t_uac_prepare(): Error while building message ERROR: presence [notify.c:1734]: send_notify_request(): in function tm t_request_within() ERROR: presence [notify.c:1829]: notify(): sending Notify not successful ERROR: presence [notify.c:1585]: query_db_notify(): Could not send notify for [event]=dialog ERROR: presence [presence.c:739]: pres_refresh_watchers(): sending Notify requests in which the building of the notify message fails because it cannot find a valid connection when building the via header. Is this a wanted behaviour? shouldn't it just fail the sending of the single message? Is there anything i can do to fix this? Trying to reproduce the same problem with a regular tcp client, it seems that the other notifys are correctly sent and only a timeout error is sent for the single message: ERROR: <core> [core/tcp_main.c:4622]: handle_tcpconn_ev(): connect 192.168.56.10:21994 failed which i think is the correct behaviour. Related question: is it possible to remove active watchers when the connection goes down? Thanks for the help on this.

2 5

Performance issues with KEMI
by Daniel W. Graham 20 Jan '25

20 Jan '25

Testing out KEMI functionality and running into performance issues. If I exceed 150 calls per second the network receive queue grows and Kamailio is unable to keep up with requests and they begin dropping. KEMI script for testing is just doing a stateless reply to invites. Using python3s module. I've played with Kamailio child processes and memory allocations, but there is no impact. I've also attempted some buffer / memory tweaking at the OS level, again with no impact. Increasing CPU cores and even running the test on bare metal results in the same. Example of receive queue at 150 calls per second - Netid State Recv-Q Send-Q Local Address:Port udp UNCONN 337280 0 x.x.x.x:5060 Just wondering if anyone has experienced similar issues or has an example of the performance they are seeing before I continue down this path. Thanks, - dan

5 9

Need help with serial branching using: t_load_contacts(1)
by Benoît Panizzon 20 Jan '25

20 Jan '25

Hi Gang I guess, I don't completely understand who to properly perform serial branching. I did try to follow the examples from: https://www.kamailio.org/docs/modules/devel/modules/tm.html#tm.f.t_next_con… This is, stripped down, the relevant config used. modparam("tm", "contacts_avp", "tm_contacts") modparam("tm", "contact_flows_avp", "tm_contact_flows") route[LOCATION] { lookup_to_dset("location", "$var(lookupuri)"); if (!t_load_contacts(1)) { xlog("L_ERR", "$cfg(route): ######### load_contacts failed\n"); sl_send_reply("500", "Server Internal Error - Cannot load contacts"); exit; } xlog("L_INFO", "$cfg(route): Contacts loaded: $cnt($xavp(tm_contacts))\n"); => Confirms, there is more than one contact loaded. if (!t_next_contacts()) { send_reply("480", "Not registered"); } t_set_fr(5000,1500); # Set 5 second timeout for LAB testing to quickly try the next contact. t_on_branch("BR_TO_CUST"); t_on_branch_failure("BR_TO_CUST_FAILURE"); exit; } event_route[tm:branch-failure:BR_TO_CUST_FAILURE] { xlog("BRANCH FAILED $T_reply_code to $rm message\n"); t_on_branch("BR_TO_CUST"); t_on_branch_failure("BR_TO_CUST_FAILURE"); if (t_next_contact_flow()) { xlog("BRANCH FAILED, Try Next\n"); t_relay(); } else { xlog("L_INFO", "No more flows\n"); t_reply("408", "Branch Timeout"); exit; } } What happens is: INVITE is sent to the first contact, who is replying RINGING. After 5 seconds the timeout is reached and the branch-failure route engaged. Jan 17 15:01:15 dev-cpereg01 kamailio[3599432]: ERROR: <script>: BRANCH FAILED 408 to INVITE message Jan 17 15:01:15 dev-cpereg01 kamailio[3599432]: INFO: <script>: No more flows Jan 17 15:01:15 dev-cpereg01 kamailio[3599432]: CRITICAL: tm [tm.c:1554]: ki_t_reply(): w_t_reply entered in unsupported mode To my understanding, t_next_contact_flow() should have loaded the next ds, but this does not seem to happen. What am I missing? -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- 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 ______________________________________________________

2 3

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

deb-archive.kamailio.org unreachable
by Floimair Florian 08 Jan '25

08 Jan '25

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

2 2

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

how to call loose_route() after adding route header without using msg_apply_changes?
by Benoît Panizzon 31 Dec '24

31 Dec '24

Hi List To handle CPE which can only handle a limited number of route header (PacketCable SIP specification), I need to store and restore the route header (limited topology hiding only affecting Route Header) to present the CPE only one Route or RR header. I pass the ID of the stored route-set via RR param. So when I get a message back from the CPE is: * Take ID from RR param and pull stored route set from cache. * remove_hf("Route"); * insert_hf("Route: $avp(stored-routeset)\r\n"); * msg_apply_changes(); * loose_route(); I found loose_route() only to be able to correctly determine the next hop, if I first did apply the changes. But after adding rtpengine to the mix, I got back into the known situation that calling rtpengine (on the branch route) after calling msg_apply_changes() results in duplicate SDP. Is there a way to get loose_route() to operate on freshly added header without calling msg_apply_changes? -- Mit freundlichen Grüssen -Benoît Panizzon- @ HomeOffice und normal erreichbar -- 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 ______________________________________________________

8 28

Async HTTP request is sent but response is incorrectly processed
by Sergio Charrua 30 Dec '24

30 Dec '24

Hi all! still struggling with Async HTTP Client ... My current configuration is very simple: #!define HTTP_API_ROUTING_ENDPOINT_MAIN " http://MY_HTTP_REST_API:18085/Endpoint" include_file "listen.cfg" loadmodule "pv" loadmodule "tm" loadmodule "http_async_client" loadmodule "xlog" loadmodule "tmx" loadmodule "sl" loadmodule "textops" loadmodule "cfgutils" loadmodule "siputils" loadmodule "rr" loadmodule "ctl" loadmodule "jsonrpcs.so" loadmodule "jansson.so" modparam("pv", "shvset", "http_async=i:8"); modparam("http_async_client", "workers", 1); modparam("http_async_client", "connection_timeout", 500) modparam("http_async_client", "curl_verbose", 1) # for debug purpose #modparam("tm", "fr_timer", 750) #modparam("tm", "fr_inv_timer", 20000) #modparam("tm", "remap_503_500", 0) modparam("tm", "failure_reply_mode", 3) modparam("tm", "max_inv_lifetime",5000) # ----- jsonrpcs params ----- modparam("jsonrpcs", "pretty_format", 1) /* set the path to RPC fifo control file */ modparam("jsonrpcs", "fifo_name", "/tmp/kamailio_rpc.fifo") /* set the path to RPC unix socket control file */ modparam("jsonrpcs", "dgram_socket", "/tmp/kamailio_rpc.sock") debug=2 children=16 log_facility=LOG_LOCAL0 log_prefix="{$mt $hdr(CSeq) $ci} " disable_sctp = yes force_rport = yes rundir="/tmp" request_route { $avp(REQUEST_URL) = HTTP_API_ROUTING_ENDPOINT_MAIN; 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; } jansson_set("string","from" , $hdr(From) , "$var(req)"); jansson_set("string","to" , $hdr(To) , "$var(req)"); jansson_set("string","r-uri" , $ru , "$var(req)"); jansson_set("string","contact" , $hdr(Contact) , "$var(req)"); jansson_set("string","call-id" , $ci , "$var(req)"); xinfo("MAIN-ROUTE - Setting From=$hdr(From) To=$hdr(To) Contact=$hdr(Contact) ci=$ci \n"); if ( is_present_hf("Identity") ) jansson_set("string","identity" , $hdr(Identity) , "$var(req)"); if ( is_present_hf("P-Identity-Bypass") ) jansson_set("string","p-identity-bypass" , $hdr(P-Identity-Bypass) , "$var(req)"); if ( is_present_hf("P-Asserted-Identity") ) jansson_set("string","p-asserted-identity" , $hdr(P-Asserted-Identity) , "$var(req)"); if ( is_present_hf("P-STSH-UC") ) jansson_set("string","p-stsh-uc" , $hdr(P-STSH-UC) , "$var(req)"); jansson_set("string", "request-time" , $avp(requestTime), "$var(req)"); ## Create transaction before http_async_query; if (is_method("INVITE")){ t_newtran(); xinfo("MAIN-ROUTE - Sending request [$var(req)]\n"); route(HTTP_ASYNC_REQUEST); } exit; } route[HTTP_ASYNC_REQUEST] { xinfo("HTTP_ASYNC_REQUEST - Sending request [$var(req)]\n"); $http_req(all) = $null; $http_req(suspend) = 1; $http_req(timeout) = 1500; # 1 second timeout $http_req(method) = "POST"; $http_req(hdr) = "Content-Type: application/json"; $http_req(body) = $var(req); if ( !http_async_query($avp(REQUEST_URL), "HTTP_REPLY") ) { xinfo("HTTP_ASYNC_REQUEST - http_async_query $ci FAILED. Return is [$rc]\n"); }else{ send_reply("503", "Server Error"); exit; } } route[HTTP_REPLY] { xinfo("HTTP_REPLY - Xphere Response Code $http_rs - $ci\n"); if ( $http_ok && $http_rs==200) { xinfo("HTTP_REPLY - $ci reply ok\n"); jansson_xdecode($http_rb, "json"); xinfo("HTTP_REPLY - HTTP JSON Response: $http_rb \n"); if ( $xavp(json=>sip-response-code) == 300 ){ remove_hf("Contact"); append_to_reply("Contact: $xavp(json=>contact)\r\n"); ## "touch" the ruri to add the contact header for 3xx: $ru = $ru; send_reply("300", "Multiple Choice"); exit; }else{ xinfo("HTTP_REPLY - $ci Error Replied $xavp(json=>sip-response-code) - $xavp(json=>sip-response-text) \n"); send_reply("$xavp(json=>sip-response-code)","$xavp(json=>sip-response-text)"); exit; } } else { xinfo("HTTP_REPLY - HTTP Response Code $ci - $http_rs and error $http_err \n"); if (!$http_ok){ sl_reply("503", "No Connection to HTTP"); exit; }else if ($http_rs>=500){ sl_reply("503", "HTTP Processing Error"); exit; } else{ sl_reply("503", "Cannot Connect to HTTP"); exit; } } exit; } The configuration is based on Ben Kaufman's kamailio_http_async <https://github.com/whosgonna/kamailio_http_async> example, but I have extended it a bit. Currently all the requests are being sent to the HTTP REST API. I can't find queue/buffering issues... What I am experiencing is that , using SNGREP, I get this flow: 10.240.12.209:5060 10.242.17.146:5060 ----------*---------- ----------*---------- 17:33:46.689852 x INVITE (SDP) x +0.000530 x --------------------------> x 17:33:46.690382 x 100 trying -- your call is x +1.499822 x <-------------------------- x 17:33:48.190204 x 503 No Connection to HTTP x +0.000029 x <-------------------------- x 17:33:48.190233 x 500 I'm terribly sorry, se x +0.002130 x <-------------------------- x 17:33:48.192363 x ACK x +0.485836 x --------------------------> x 17:33:48.678199 x 500 I'm terribly sorry, se x +0.004881 x <<<------------------------ x 17:33:48.683080 x ACK x +0.973295 x ------------------------>>> x 17:33:49.656375 x 500 I'm terribly sorry, se x +0.004105 x <<<------------------------ x 17:33:49.660480 x ACK x +1.995420 x ------------------------>>> x 17:33:51.655900 x 500 I'm terribly sorry, se x +0.005361 x <<<-------------------------x 17:33:51.661261 x ACK x x ------------------------>>> x I suspected issues with the HTTP REST service, but when using tcpdump, I can find the Request from Kamailio and a reply back from the REST API service, so doesn't seem to be a problem on the HTTP REST service So my questions are: - why is Kamailio sending a "SIP 500 I'm terribly sorry..." error after a 503 No Connection to HTTP is sent and an "exit" command is executed? - how can I get rid of these messages? - Why Kamailio keeps sending responses back to SBC after the ACK when it is set to just "exit"? - Why is Kamailio not processing the response from HTTP REST API when it is correctly received? Logs are also weird: - I find a lot of these warnings: "Dec 29 17:38:34 ire-nprod-sip1 /usr/local/sbin/kamailio[590864]: WARNING: http_async_client [http_async_client_mod.c:529]: ah_get_status(): an async variable was read after http error, use $http_ok to check the request's status" and "Dec 29 17:38:34 ire-nprod-sip1 /usr/local/sbin/kamailio[590864]: ERROR: http_async_client [http_multi.c:621]: check_multi_info(): handle 0x7f375f786b30 returned error 7:" (I am still not using EVAPI module, that will be my next step, after the holiday season) (I suspect, however, that the REST API is not being able to handle the load in this test environment (between 400 to 600 CAPS), but that is another matter.) In attach, TCPDUMP, if anyone wishes to analyse. Atenciosamente / Kind Regards / Cordialement / Un saludo, *Sérgio Charrua*

3 5

http sync / async final tests
by Alexis Fidalgo 26 Dec '24

26 Dec '24

Just to share, and thanks for your valuable help. My conclusion after tests (on my scenario) is http backend: is a golang http server with a 250ms delay to answer, and answering back a json, running in 10 replicas inside a K8 with 4 nodes. test (from kamailio perspective): receive INVITE send 100 call the http, get the result, get a key from the result and set it as the value of Contact header send 302 receive ACK (discard on sync scenario because it’s stateless, use it in async to end transaction) Kamailio host: 1vcpu kamailio 3.8.4 bookworm running inside containerd (with podman) 16GB RAM sipp: run from the K8 nodes hosts (directly from OS) (everything is LAN connected on 2 different physical servers, hypervisor is VMWare i guess 7.0.3) using http_client (sync with stateless): 8 children -M8 -m64 no more than 60 calls/sec (15cps on each sipp instance) until sipp start to retransmit the INVITES using async_http_client: 8 children -M8 -m2048 it’s been ~36 hours now at 250cps each sipp instance with 0 errors 0 retransmission and the kamailio host is userlab@sblb1:~$ vmstat 1 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 4 0 0 10285460 364684 5444240 0 0 0 22 36 68 0 0 100 0 0 1 0 0 10285460 364684 5444240 0 0 0 0 5284 6822 27 14 58 0 0 4 0 0 10285460 364684 5444240 0 0 0 0 5306 6752 29 15 57 0 0 3 0 0 10285460 364684 5444240 0 0 0 0 5304 6823 26 16 57 0 0 2 0 0 10285460 364684 5444240 0 0 0 12 5287 6761 26 16 57 0 0 2 0 0 10285460 364684 5444240 0 0 0 0 5337 6838 27 14 58 0 0 1 0 0 10285460 364684 5444240 0 0 0 0 5101 6724 25 17 59 0 0 3 0 0 10285460 364684 5444240 0 0 0 0 5066 6650 26 14 60 0 0 1 0 0 10285460 364684 5444240 0 0 0 0 5306 6829 23 17 59 0 0 1 0 0 10285460 364684 5444240 0 0 0 0 5219 6725 23 19 58 0 0 1 0 0 10285460 364684 5444240 0 0 0 0 5274 6770 26 13 61 0 0 1 0 0 10285460 364684 5444240 0 0 0 0 5295 6756 26 18 56 0 0 1 0 0 10285460 364684 5444240 0 0 0 0 5235 6786 22 16 62 0 0 1 0 0 10285460 364684 5444240 0 0 0 0 5315 6833 21 20 59 0 0 at least for my scenario, it worths to pay the price of the memory tradeoff. again, Ben, Alex, Sergio, all, thanks for your help. regards

1 0

help on how to get ACK
by Alexis Fidalgo 24 Dec '24

24 Dec '24

Hello all, moving just a bit aside of the http and async_http. After all the real useful and interesting thread on that topic what helped me, im facing a problem i cant deal with and need a hint at least. Scenario INVITE -> Kamailio on request_route ... if(is_method("INVITE")){ t_newtran(); http_async_query("http://nuc:8080", "HTTP_REPLY"); } … Kamailio -> 100 - Trying then route[HTTP_REPLY] { if ($http_ok) { xlog("L_INFO", "route[HTTP_REPLY]: status $http_rs\n"); xlog("L_INFO", "route[HTTP_REPLY]: body $http_rb\n"); t_reply(302,"Redirect"); } else { xlog("L_INFO", "route[HTTP_REPLY]: error $http_err)\n"); } } Kamailio -> 302 Redirect ACK -> Kamailio This last ACK, how can i read it and use it to terminate the transaction? because Kamailio keeps transmitting the 302 message 3 more times until the transaction is finished by a timer 42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted. buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3 42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted. buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3 42(44) DEBUG: tm [t_reply.c:1723]: t_retransmit_reply(): reply retransmitted. buf=0x7f4c44f9d680: SIP/2.0 3..., shmem=0x7f4c3fce7900: SIP/2.0 3 42(44) DEBUG: tm [timer.c:642]: wait_handler(): finished transaction: 0x7f4c3fcd35a0 (p:0x7f4c3fad85d0/n:0x7f4c3fad85d0) 42(44) DEBUG: tm [h_table.c:133]: free_cell_helper(): freeing transaction 0x7f4c3fcd35a0 from timer.c:651 in request_route i have if(is_method("ACK")){ if(!t_check_trans()){ t_release(); } exit; }

4 26

append_branch
by Alexis Fidalgo 24 Dec '24

24 Dec '24

Hello all, how can avoid to append_branch do this call to call SIP/2.0 302 Redirect Via: SIP/2.0/UDP 192.168.86.250:5060;branch=z9hG4bK-65665-5-0 From: sipp <sip:sipp@192.168.86.250:5060>;tag=65665SIPpTag005 To: 123456 <sip:123456@192.168.86.128:5060>;tag=a6a1c5f60faecf035a1ae5b6e96e979a-deb8da2e Call-ID: 5-65665(a)192.168.86.250 CSeq: 1 INVITE Contact: <sip:4093823670@otherdomain.com>, <sip:8888576523@otherdomain.com>, <sip:9719533197@otherdomain.com>, <sip:5302579529@otherdomain.com>, <sip:4972010218@otherdomain.com> Server: kamailio (5.8.4 (x86_64/linux)) Content-Length: 0 What i mean with “avoid”, call to call, contact should have only 1 branch, no a stack of previous. thanks

2 1

Transactions help
by Alexis Fidalgo 24 Dec '24

24 Dec '24

Hello, after the discussion regarding http and http_async, I started some labs to make a comparison and see what’s the trade off and the associated cost. Main problem (to me) is im not clear on how transactions behave. Im running some fast tests now before I start to deploy the final scenarios and 1. A new transaction is created before the http_async call (as the module example shows for http_async_query function 2. The http_async_query call is executed, receives a response and the HTTP_REPLY route for http_async_query is executed. 3. As we need to redirect the call, im adding Contact information with append_to_reply and then calling t_reply(302,”Redirect) Up to here INVITE is received, a 100 is answered and then the 302 with the expected Contact information (collected and built from the http_async_query response), problem is that the 302 is retransmitted 3 more times. So, im not even sure that im doing the correct actions to process the call this way. Is there a document/book/reference I can read to understand transactions better? By now I can not handle the call to be processed correctly (without the retransmissions) and finish the transaction the correct way. Any help, link, guide, will be appreciated. Regards.

6 17

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