sr-users January 2025

sr-users@lists.kamailio.org

29 participants
20 discussions

Error when sending NOTIFYs to disconnected websocket clients

by Flavio Grossi

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.

1 hour, 28 minutes

Need help with serial branching using: t_load_contacts(1)

by Benoît Panizzon

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 days, 14 hours

Issue with ACK on INVITE

by Barry Flanagan

Hi folks, Trying to hook up a new endpoint but am having an issue. Kamailio is in front of an Asterisk box. They send an INVITE, we send 100, then 200 OK. However, when they send their ACK, the RURI is not set to the Contact of the 200, instead it is<number>@<proxy ip>. This causes the ACK to get routed to the proxy itself and the call fails. 82.160.190.100:5060 = Kamailio IP Port 198.201.240.242:5080 = Asterisk IP/Port 182.33.174.10:5060 = Provider endpoint The far endpoint say they cannot fix the RURI - should I be able to handle this ACK below? My understanding is the ACK's RURI should be the Contact of the 200 OK. 200 OK sent from us to the Provider (Contact shows correct URI) ========================================================= 2025/01/15 17:14:49.470634 82.160.190.100:5060 -> 182.33.174.10:5060 SIP/2.0 200 OK Via: SIP/2.0/UDP 182.33.174.10;branch=z9hG4bKefc7.ad07f2d3.0 Via: SIP/2.0/UDP 182.33.174.39:5060;received=182.33.174.39;branch=z9hG4bK5bbf9591;rport=5060 Record-Route: <sip:1800715080@82.160.190.100:5061;r2=on;lr=on;ftag=as0b42eef3;did=f2e.ade2;nat=yes> Record-Route: <sip:1800715080@82.160.190.100;r2=on;lr=on;ftag=as0b42eef3;did=f2e.ade2;nat=yes> Record-Route: <sip:182.33.174.10;lr;ftag=as0b42eef3> From: "0737965510" <sip:0737966610@182.33.174.39>;tag=as0b42eef3 To: <sip:1800715080@82.160.190.100>;tag=as4133584e Call-ID: 480dc17b3f88516f364778dc4b2528da@182.33.174.39:5060 CSeq: 102 INVITE Server: Asterisk PBX 18.9.0 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces *Contact: <sip:1800715080@198.201.240.242:5080>* Content-Type: application/sdp Content-Length: 314 , ACK Reply from Provider to Us (RURI points to Kamailio ip:port now =========================================================== 2025/01/15 17:14:49.478119 182.33.174.10:5060 -> 82.160.190.100:5060 *ACK sip:1800715080@82.160.190.100:5060 *SIP/2.0 Via: SIP/2.0/UDP 182.33.174.10;branch=z9hG4bKefc7.ad07f2d3.2 Via: SIP/2.0/UDP 182.33.174.39:5060;received=182.33.174.39;branch=z9hG4bK55656469;rport=5060 Route: <sip:1800715080@82.160.190.100;r2=on;lr=on;ftag=as0b42eef3;did=f2e.ade2;nat=yes>,sip:1800715080@82.160.190.100:5061;r2=on;lr=on;ftag=as0b42eef3;did=f2e.ade2;nat=yes> Max-Forwards: 69 From: "0737965510" <sip:0737966610@182.33.174.39>;tag=as0b42eef3 To: <sip:1800715080@82.160.190.100>;tag=as4133584e Contact: <sip:0737965510@182.33.174.39:5060> Call-ID: 480dc17b3f88516f364778dc4b2528da@182.33.174.39:5060 CSeq: 102 ACK Thanks -Barry

3 days, 15 hours

Kamailio IMS, used with IPv6?

by Valentin Christoph

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

3 days, 16 hours

Asynchttp failover

by Sergio Charrua

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*

4 days, 22 hours

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

5 days

Performance issues with KEMI

by Daniel W. Graham

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 days, 3 hours

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

5 days, 3 hours

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)

5 days, 10 hours

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

5 days, 17 hours

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