sr-users November 2024

sr-users@lists.kamailio.org

38 participants
35 discussions

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)

1 week, 5 days

Freezing development for 6.0.x series

by Daniel-Constantin Mierla

Hello, I propose to aim freezing the development for 6.0.x series at the end of the 16th of December 2024 (Monday). New features that one wants to get in this release series have to be pushed to git repository or pull requests made for them. Afterwards usually follows a 4-6 weeks of testing till the first release 6.0.0. Unfreezing will happen earlier, after the first weeks of testing when the 6.0 branch will be created. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com

1 month, 1 week

Updated: Online devel meeting on matrix - 15:00 UTC, Dec 9, 2024

by Daniel-Constantin Mierla

Hello, we should consider an online devel meeting sometime soon to summarize what was done at (and still needs to be done after) devel meeting in Dusseldorf and plan a bit the targets for next major release 6.0. If considered useful, I propose Dec 9, 2024 (Monday) at 15:00UTC (16:00 Berlin/Paris/Madrid/Rome), but we can also look for other dates as well. Topics to be discussed can be added at: - https://github.com/kamailio/kamailio-wiki/blob/main/docs/devel/irc-meetings… Pull requests can be made by users without git access. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

1 month, 2 weeks

Potential Bug in Kamailio: Base64 Decode Transformation Not Working in Lua but Works in kamailio.cfg

by Dirk Brouwers | CM.com

Dear Kamailio Developers, I am writing to report a potential bug in Kamailio's handling of base64 decoding when using the Lua scripting interface (app_lua). It appears that base64 decoding behaves inconsistently between Lua scripts and kamailio.cfg. When using `$(var(encoded_json){s.decode.base64t})` in kamailio.cfg, where $var(encoded_json) contains the encoded base64 string: `eyJmb28iOiJiYXIifQ` it decodes to the correct `{"foo":"bar"}`. But when using the same transformation in Lua `KSR.xlog.xinfo("Decoded in Lua: ".. KSR.pv.get("$(var(encoded_json){s.decode.base64t})"))` it logs a corrupted encoded base64 string: `Decoded in Lua: ..]..#035z{b.?...#036..-....` Thank you in advance for looking into this issue. Please let me know if you need additional details or test cases. Kind regards, Dbrcm

1 month, 4 weeks

"Intermittent Issue: Kamailio Presence Server Not Generating NOTIFY Packets"

by satyaprakash ch

Hi We have FreeSWITCH and Kamailio presence servers set up. FreeSWITCH sends XML RPC messages to the Kamailio presence servers for PUBLISH operations, and we receive 200 OK responses in return. These responses include the SIP-ETag and Expires headers. However, the Kamailio presence server is not consistently generating NOTIFY packets. This issue seems to occur randomly. Can you please suggest this for presence servers. Thank you in advance.

2 months

record_route() adds empty route header if enable_double_rr is 1

by Benoit Panizzon

Hi Gang How is record_route() determining if it needs to add two RR Header? Kamailio 5.8.4 I'm attempting to perform route header hiding by by rebuilding some of the topos functionality with perl. So towards the CPE I'm removing all existing RR header and want to replace them with one header containing an attribute which the CPE is then sending back and allows me to restore the Route header. But I came across an issue which an empty RR header being created with this (simplified) script: modparam("rr", "enable_double_rr", 1) perl_exec("hide_route"); # Stores Route-Set and sets $avp(rrattr) as id remove_hf("Record-Route"); msg_apply_changes(); loose_route(); # Required for record_route()? add_rr_param(";rr=$avp(rrattr)"); # Add Param to identify saved route set record_route(); I end up with: Record-Route: <sip:;r2=on;lr;rr=id007> Record-Route: <sip:157.161.x.x;r2=on;lr;rr=id007> The first header missing the IP address, the message being dropped by the CPE There is no transport change. If I set enable_double_rr to 0 only the 2nd RR header is created and this works as expected but I am not sure if some situations would need double RR. What causes the double RR to be created in my case? 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 ______________________________________________________

2 months

app_perl add/remove HF?

by Benoît Panizzon

Hi List I'm looking into the perl module. Am I right, that I can not add or remove HF from an app_perl subroutine? I would need to pass an AVP from perl to tell Kamailio what to do? Goal is an attempt to re-build part of the topos functionality in perl but only handling RR and Route Header only on one leg, not on both. -- 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 months

tcp_accept_haproxy option

by Wolter Eldering

Hi, I noticed that if I enable tcp_accept_haproxy kamailio still can accept connections without the PROXY-protocol header. The documentation on the wiki has the following note: "Please note that enabling this option will reject any inbound TCP connection that does not conform to the PROXY-protocol spec." https://www.kamailio.org/wiki/cookbooks/devel/core#tcp_accept_haproxy This could be true up until a specific version of kamalio but from 5.7.4+ this limitation is seems to be removed. Enabling tcp_accept_haproxy is breaking the outbound/rr module because it con’t find the socket based on the address and port from the flow token. The flow tokens created by a REGISTER on a connection without a PROXY header can be used. Flow tokens created from a connection with PROXY-protocol header will fail with "cannot find socket from flow-token” once loose_route is invoked. loose.c:561 /* First, force the local socket */ si = find_si(&rcv->dst_ip, rcv->dst_port, rcv->proto); if(si) set_force_socket(_m, si); else { LM_INFO("cannot find socket from flow-token\n"); return -1; } I’m not sure if the address and/or port values stored in the flow token are incorrect or the problem lies in the matiching in find_is(…). Wolter

2 months

RTC DevRoom at FOSDEM 2025

by Daniel-Constantin Mierla

Hello, FOSDEM'25 will host again a RTC DevRoom during the afternoon of February 1, 2025 (Saturday) -- more details and the call for presentation can be read at: - https://lists.fosdem.org/pipermail/fosdem/2024q4/003584.html I am not sure if I can participate (chances are more towards no, than to yes), but if anyone considers to go to the event, it will be good to submit a proposal to cover a bit Kamailio as well (it doesn't have to be entirely about Kamailio). Note that FOSDEM imposes a strict deadline this time for submissions (Dec 1, 2024), thus is no much time left. Should anyone in these groups plans to submit a proposal, let us know, so the others have an idea about it. Cheers, Daniel -- Daniel-Constantin Mierla (@ asipto.com) twitter.com/miconda -- linkedin.com/in/miconda Kamailio Consultancy, Training and Development Services -- asipto.com

2 months

TM-Module, ignoring

by Christian Berger

Hi, we would like to replicate a SIP-message ("REGISTER" in our case) to a set of nodes for further asynchronous processing. The message is already processed on the local Kamailio. We thought about using the tm-module in conjunction with the dispatcher module so we can reliably forward the message. This seems to work, however we get a new problem: Kamailio forwards the response it gets from those nodes. When we drop the response in the reply_route, it gets dropped before TM can see it. When we drop the response in the on_reply_route, it still will be forwarded. (adding or removing a header here works, however) $du is set to $null. Is there any clean way to suppress that response being forwarded back to the original requester? Best regards Christian Berger -- Christian Berger - berger(a)sipgate.de Telefon: +49 (0)211-63 55 55-0 Telefax: +49 (0)211-63 55 55-22 sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois Steuernummer: 106/5724/7147, Umsatzsteuer-ID: DE219349391 www.sipgate.de - www.sipgate.co.uk

2 months, 1 week

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 November 2024