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

[Daniel-Constantin Mierla]

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

Cheers,
Daniel

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:127.0.0.1:2223
> udp:192.168.64.4:2224")
>
> Host 192.168.64.4 is not running (not existing in my case, just made up
> that ip to be on the same network with the kamailio running on
> 192.168.64.2).
>
> 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:127.0.0.1:2223
> udp:127.0.0.1:2224")
>
> 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:127.0.0.1:6050  (running)
>> udp:192.26.134.10:6050 (host 192.26.134.10 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:192.26.134.10:6050 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