hello Daniel
Thanks a lot for the update. We will also test it.
It has not 100% relation with this issue, but i only wanted to share the setup
we have for cases where a rtpengine fails having high traffic load, to minimize
the impact on the kamailio processes.
modparam("rtpengine",
On Fri, 28 Dec 2018 at 10:32, Daniel-Constantin Mierla
wrote:
> I just pushed a series of commits trying to rework how loading (and
> reloading) of rtpegines list is done, to avoid that sync'ed probing,
> which can take long if any of the rtpengines is down.
>
I just want to thank you for this
Daniel-Constantin Mierla writes:
> I just pushed a series of commits trying to rework how loading (and
> reloading) of rtpegines list is done, to avoid that sync'ed probing,
> which can take long if any of the rtpengines is down.
Daniel,
Thanks for the commit. Now K starts responding
I just pushed a series of commits trying to rework how loading (and
reloading) of rtpegines list is done, to avoid that sync'ed probing,
which can take long if any of the rtpengines is down.
Now, building the local (per process) structures/sockets for rtpengines
during kamailio start up is done
Indeed I stopped at the wrong param for the timeout, should have been
another one:
modparam("rtpengine", "rtpengine_tout_ms", 500)
Cheers,
Daniel
On 26.12.18 12:16, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> Maybe you would also want to tune the timeout with the modparam:
>>
There are many situations that can block a proxy, including writing to
syslog, dns and DB queries,... At the end you cannot rely on a single app
to have a smooth runtime, the ecosystem has to be also in good parameters.
The current implementation is like this now, the choice of developer. You
can
Daniel-Constantin Mierla writes:
> You can make a fix yourself if you want and have the time. It is not a
> module I coded, nor the one that added db support for it, so I am also
> coding by learning what was done there.
Understand. Perhaps the solution for now is to disable db mode in the
No, it is for no-db. For db, it requires another solution, but I don't
have time for it right now. I explanined in my previous email what would
be a solution.
You can make a fix yourself if you want and have the time. It is not a
module I coded, nor the one that added db support for it, so I am
Daniel-Constantin Mierla writes:
> 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:
Still took in rtpengine db mode about 2 minutes
Daniel-Constantin Mierla writes:
> 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
Daniel-Constantin Mierla writes:
> 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")
In my test, I use rtpengine in db mode, i.e., db_url param is set.
Would your patch also fix the delay in that
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
>
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
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
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?
Is the CPU usage very high? Because it is strange that
David Villasmil writes:
> You could also ask politely, as this IS open source, after all.
I didn't notice any impoliteness in my message. I just mentioned that a
proper fix is needed.
-- Juha
___
Kamailio (SER) - Users Mailing List
You could also ask politely, as this IS open source, after all.
On Tue, 25 Dec 2018 at 02:42, Juha Heinanen wrote:
> * Paolo Visintin - evosip.cloud writes:
>
> > we solved starting with no rtpengine this produces at startup:
> > WARNING: rtpengine [rtpengine_db.c:100]: rtpp_load_db(): No
* Paolo Visintin - evosip.cloud writes:
> we solved starting with no rtpengine this produces at startup:
> WARNING: rtpengine [rtpengine_db.c:100]: rtpp_load_db(): No rtpproxy
> instances in database
> and then, after rtpengine instances are up and correctly running we send an
>
Hello Juha,
I think we have experienced the same behaviour (also `service kamailio
restart` does strange things like freezed processes and failure of
reloading procedure)
we solved starting with no rtpengine
this produces at startup:
WARNING: rtpengine [rtpengine_db.c:100]: rtpp_load_db(): No
Daniel-Constantin Mierla writes:
> Can you see the packet being sent over the network (with ngrep, tcpdump,
> ...)?
Yes, UDP register is sent, but kamailio does not respond to it.
Then I did this.
1) Started K where rtpengine udp:192.26.134.10:6050 is enabled but is
not running.
2) Gave
Can you see the packet being sent over the network (with ngrep, tcpdump,
...)?
Maybe you can also send a registration over udp, to see if that works or
not.
Daniel
On 24.12.18 13:55, Juha Heinanen wrote:
> Daniel-Constantin Mierla writes:
>
>> It waits for packets from the network. Did you send
Daniel-Constantin Mierla writes:
> It waits for packets from the network. Did you send registration via
> UDP?
No, via tcp and there was also tcp listener processes.
-- Juha
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
This one seems to be a udp receiver and looks ok:
#0 0x7f9958d359c3 in __recvfrom_nocancel () at
../sysdeps/unix/syscall-template.S:84
#1 0x55ce6a029443 in udp_rcv_loop () at core/udp_server.c:460
#2 0x55ce69f969cf in main_loop () at main.c:1621
#3 0x55ce69f9eb39 in main
Daniel-Constantin Mierla writes:
> Can you see how many kamailio processes are running (w.g., with ps)? Are
> there expected number of there?
Same number of processes when I start K with proper rtpengine set and
with one that has an rtpengine that does not respond.
> If yes, take the PID of few
Can you see how many kamailio processes are running (w.g., with ps)? Are
there expected number of there?
If yes, take the PID of few of them and attach with gdb, then grab the
back trace in order to see what they do.
Cheers,
Daniel
On 24.12.18 11:33, Juha Heinanen wrote:
> Daniel-Constantin
Daniel-Constantin Mierla writes:
> what happens when you send a sip message and have debug=3? Do you see
> any logs printed?
Nothing comes to syslog when register request arrives. Also kamailio does not
respond to ctl command.
Below is sample on what comes to syslog after start.
-- Juha
Hello,
what happens when you send a sip message and have debug=3? Do you see
any logs printed?
Cheers,
Daniel
On 23.12.18 10:07, Juha Heinanen wrote:
> I noticed that if one rtpengine in a set is unreachable, kamailio 5.2
> does start, but does not process any SIP requests. Is this
I noticed that if one rtpengine in a set is unreachable, kamailio 5.2
does start, but does not process any SIP requests. Is this intentional?
-- Juha
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
28 matches
Mail list logo
