Can you try with
kamailio ... --atexit=no
On Tue, 14 May 2024, 13:13 Marat Gareev via sr-users, <
sr-users@lists.kamailio.org> wrote:
> Hello again,
>
> I've updated Kamailio to 5.7.5, set tls_threads_mode=2 and got another
> segfault:
>
> Program terminated with signal SIGSEGV,
Check how libssl3 is configured in /etc/ssl/openssl.cnf.
You may need:
[system_default_sect]
MinProtocol = TLSv1.0
CipherString = ALL@SECLEVEL=0
From:
https://serverfault.com/questions/1143995/tls-1-0-broken-with-newer-debian-openssl
Regards
Richard
In the method can you put
return 1
at the end. KEMI python is very strict on an int return value.
On Tue, 5 Mar 2024, 07:08 Marrold via sr-users,
wrote:
> Hi all,
>
> I am using Kamailio 5.7.4 on a Debian 12 machine, with a Python Kemi based
> config. I am seeing some intermittent failures
Hi Daniel
===
For the upgrading notes, some ideas —
"tls.so: fixing GH#3635 new global config tls_threads_mode = 0 | 1
0: is the default and is the existing Kamailio behaviour
1: run some initialization functions(libcurl, database) in a thread to
avoid creating
Hello Kamailio community,
After the January refactoring of OpenSSL integration, configurations that
initialise libssl in rank 0 (thread #1) are likely to trigger errors more
aggressively. This type of configuration has all along been broken due to
OpenSSL use of thread-local variables.
The first
In the config file:
#!define KEYVALUE "key=s:value"
modparam("pv", "varset", KEYVALUE)
works. But if I try to use defexp or defexps the ID KEYVALUE
is not set as expected and the parser complains.
## this doesn't parse
#!defexp KEYVALUE2 "key=s:value"
#!defexps KEYVALUE3 "key=s:value"
# both
Hi sr-users,
In the case of dispatcher-based HA such as the Wazo example (
https://wazo-platform.org/blog/kamailio-ha-dispatcher-and-dmq)
won't the Route: headers be wrong for in-dialog requests if the request is
sent to the backup proxy?
front proxy -> proxy A, B, C, D,... -> network
Suppose
