Daniel-Constantin Mierla writes:
> If you can reproduce it, watch what the timer processes do during that
> time frame. Get the list of processes with 'kamctl ps', then when the
> issue is exposed, grab the backtraces of all processes with:
>
> kamctl trap
>
> A file is created with the
Hello,
(moving discussion to users list)
have a look to the Kamailio log files to see the actual errors, maybe there is
a path not correct. You can also execute Kamailio with logging to stdout (have
a look to the parameter visible with kamailio -h).
Cheers,
Henning
--
Henning Westerholt –
Hello,
the backtrace is unfortunately not useful, as you are missing the necessary
debug information. There should a be Kamailio package available to install the
debug information.
But as mentioned before, you really should upgrade at least to the lastest
5.0.x version, as many bugs are fixed
Hi All, thanks for your replies. As suggested I did the following steps:
1) Checked our backend and now, after creating some indexes, is running
properly with the right query time
2) Increased the connection limit to 64K in kamailio.cfg file
3) Set tcp_connection_lifetime to 5s for new connection
Hello Thomas,
You can configure the dispatcher module to skip DNS resolution at startup. Have
a look to this docs section:
"16 (bit at index 4 - 1 <<4) - skip DNS A/ resolve at startup, useful when
the hostname of the destination address is a NAPTR or SRV record only. Such
addresses
Hi Alex,
about the second question - a bit hard to tell. I remember that some big
deployments used patches with a similar effect already many years ago. On the
other hand, there have been not much reports on list or tracker on these
problems in the past.
The documentation can be always
Hello,
On 07.03.20 21:29, Alex Balashov wrote:
> Hi Henning,
>
> Yes, the db_check_update approach provides an adequate solution. I already
> explored that before making this post.
>
> My interest in that issue is insofar as:
>
> 1) How do registrants come to go missing from the DB sync, if
