[SR-Users] kamailio does not responde if an rtpengine is unreachable

Daniel-Constantin Mierla miconda at gmail.com
Wed Dec 26 12:02:35 CET 2018

I forgot to say that if the patch makes it work for you, then you can go
ahead and backport to branch 5.2.


On 26.12.18 12:01, Daniel-Constantin Mierla wrote:
> I was able to figure out what could be the cause with:
> modparam("rtpengine", "rtpengine_sock", "udp:
> udp:")
> Host is not running (not existing in my case, just made up
> that ip to be on the same network with the kamailio running on
> It was starting a slower, iterating over each child, but then all ok,
> requests were handled very fast.
> When I ran with:
> modparam("rtpengine", "rtpengine_sock", "udp:
> udp:")
> with no rtpengine on port 2224, start was very fast, expecting to be due
> to detecting very quickly that port was not open.
> The cause for slower start was the code for ability to reload from
> database. There are some locks that are enabled while initializing
> rtpengine sockets, so each child had to wait for the one that acquired
> the lock.
> I pushed a quick fix for the case when db support is not enabled,
> because these locks are useless in that case, so all children will do
> the rtpengine init at the same time, without waiting for the others:
>   *
> https://github.com/kamailio/kamailio/commit/99250f758e6deb90a5852599f831a53ab394b751
> Maybe you would also want to tune the timeout with the modparam:
> modparam("rtpengine", "rtpengine_disable_tout", 5)
> So detection of unavailable rtpproxy is fast, otherwise it is 60 sec by
> default, so you may still experience some slow start per child process.
> Once I get more time, I will optimize the reload from db as well, so the
> build of rtpengine sockets is going to be done in parallel, by copying
> first inside locking the addresses from shared memory to private (should
> be fast) and then do the connect test  (which can be slower) outside of
> locking.
> I may also discovered an issue with reload from db, not sure if works
> right now if there is the same number of rtpengine instances at reload.
> But I need to verify if I understood the mechanism so far, not being the
> one that coded db support and reload.
> Cheers,
> Daniel
> On 26.12.18 10:59, Juha Heinanen wrote:
>> Daniel-Constantin Mierla writes:
>>> I tried quickly with a rtpengine that was not running, and kamailio
>>> started fine and then was responding fast for sip requests.
>>> To clarify: you actually have more rtpengine configured (at least two)
>>> in a set and one is not available, right?
>> Yes, I have two in one set:
>> udp:  (running)
>> udp: (host is down)
>>> Is the CPU usage very high? Because it is strange that is responding,
>>> but with long delay ...
>> top does not show any kamailio processes in the top.
>> In addition to not responding to sip requests, kamailio does not respond
>> to kamcmd command either.
>> It stars to respond when rtpengine module gives up on trying and
>> declares udp: disabled.
>> -- Juha

Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in Washington, DC, USA -- www.asipto.com

More information about the sr-users mailing list