[Kamailio-Users] Kamailio (1.5 rev5834) and/or rtpproxy gets frozen

[Iñaki Baz Castillo]

Hi, I'm experimenting an annoying issue in a Debian Lenny 32 bits under a DELL 
850 (2 cores). Same occured before with Debian Etch 32 and 64 bits in other 
host (also DELL 850).

Kamailio (1.5 rev 5834) behaves as a load balancer in front of 2 PSTN 
gateways. There are ~200 calls and for all of them rtpproxy is applied.

Sometimes, with no reason (not just in the moments of highest traffic) 
kamailio gets totally frozen, this is, it doesn't reply to SIP messages, 
neither relays them. Then Kamailio cannot be killed (just with -9).
Sometimes it occurs when performing a fifo command (i.e. "kamctl fifo 
address_reload").

After killing it, kamailio cannot be started again. It starts and logs the 
usual logs (to syslog) but after "rtp proxy <unix:/var/run/rtpproxy.sock> 
found, support for it enabled" there is no more logs. Then if I do a "ps aux | 
grep kamailio" I just see a single process, it's like the children fail when 
connecting to rtpproxy and die but the master process doesn't realize of it 
and remains alive showing no error at all.
So I suspect from rtpproxy as even when kamailio was killed rtpproxy process 
consumes lot of CPU.

I'll try with rtpproxy-1.2.1 (the latest stable version) as before I was using 
a old "truk" version (unfortunatelly I've no idea about how to know the CVS 
revision of a CVS working directory...).

Anyhow I also suspect that the problem could be in the server itself, as 
sometimes the above problem occurs when reloading iptables and so on, very 
very strange, no a definitive cause or reason, very annoying.

So nothing is clear for me. But I know that the problem occurs:
- In two DELL 850, one with 32 and the other with 64 bits.
- In both Debian Leeny and Etch.
- With kamailio 1.5 rev 5834.
- With rtpproxy rev XXX (how to get the last modification date in a CVS 
working dirrectory?)

So, the fact is that I'm completely lost, no idea of what is happening.
Any suggestion? Thanks a lot.


-- 
Iñaki Baz Castillo <ibc at aliax.net>