Hello,
it does not matter, they are scripting language tokens mapped to 1 or 0:
1 == yes == on
0 == no == off
Not sure the interpreter has true/false, if yes, I expect to be the same.
Cheers,
Daniel
On 28.08.21 09:38, Juha Heinanen wrote:
> Wiki tells:
>
> dns_srv_lb = yes | no (default
Hello,
does it happen only for connections done by the monitoring system? Or
also for the connections tried from the usual sip phones?
What is the operating system and libssl version?
Cheers,
Daniel
On 30.08.21 11:57, Sebastian Damm wrote:
> Hi Henning,
>
> unfortunately, I don't have a host
For the archives:
If you have a configuration file for your tls connections (not kamailio.cfg
modparams) I believe the TLS module will reopen connections at tls.reload. If
you update the certificates the new ones will be active after reload. This does
not happen if you use modparams. Meaning
Hi,
I suppose, it happens for real connections, too. But since it's so
sporadically, I guess, clients just retry and then it works.
The operating system is an Ubuntu 18.04 (getting replaced by Ubuntu 20.04
soon), thus it's running with libssl 1.1.1.
Regards,
Sebastian
- Ursprüngliche
> On 30 Aug 2021, at 14:23, Daniel-Constantin Mierla wrote:
>
> Actually the active tls connections are not closed (and thus not
> re-opened) on tls.reload. It should use the new tls.cfg and
> corresponding certs only for the new connections. Old connections should
> not affected by reload.
Hello,
ubuntu 18.04 is the worse distro to work with when having to use libssl.
One of their upgrades introduced mixed use of libssl 1.0 and 1.1, with
1.1 being one of the early releases in 1.1.x series. First thing that
broke (or was reported) was related to mysql tls connections and getting
Actually the active tls connections are not closed (and thus not
re-opened) on tls.reload. It should use the new tls.cfg and
corresponding certs only for the new connections. Old connections should
not affected by reload.
Cheers,
Daniel
On 30.08.21 13:57, Olle E. Johansson wrote:
> For the
