Yes, I have the same problem with db_mode 2
I always get these lines : ERROR: receive_msg: no mem for sip_msg DEBUG: probing packet received
I will upgrade to 0.8.14...
Thank you Gwen
Hi Gwen,
it will be safer to uninstall first the 0.8.12 version. out of curiosity, since the problem you reported is quite strange, have you tried db_mod 2?
bogdan
g.billoudet@arwen-tech.fr wrote:
Hi,
If I don't use "serctl alias add", I still get the same error message... I will try to upgrade ser:
- Should I uninstall ser 0.8.12 and then install 0.8.14
- Or should I install 0.8.14 directly ?
Thanks
Gwen
Try to install 0.8.14.
Jan.
On 10-11 14:27, Bogdan-Andrei IANCU wrote:
Hi Gwen,
try to set back db_mode to 1 or 2 but without adding the aliases via serctl. I'm trying to figure out if it's a problem in DB part or in fifo part of usrloc.
bogdan
g.billoudet@arwen-tech.fr wrote:
Hi, thanks for help
I used serctl alias add 1234 sip:gwenael@arwen-tech.fr just after
starting
ser :
- When I set modparam("usrloc", "db_mode", 0), ser works fine and I
can have phone calls but I can't use this alias of course...
- When I ser modparam("usrloc", "db_mode", 1), ser just doesn't work
at all.
My aliases table is empty when I start ser. I am using ser 0.8.12.
Gwen
On 10-11 11:41, Bogdan-Andrei IANCU wrote:
>Jan Janak wrote: > > > >>On 10-11 10:01, Bogdan-Andrei IANCU wrote: >> >> >> >> >>>my first guess is that use at start-up time you have an intensive >>>private memory consumer which gets into conflict with the SIP >>> >>>
messages
>>>receiver. >>> >>>Judging after the error (in receive loop) I'm sure you have some >>> >>>
SIP
>>>traffic at start-up - please check with tcpdump or ngrep - it can >>> >>>
be
>a > > > >>>REGISTER, SUBSCRIBE, etc >>> >>>Looking into your script, I would say only usrloc can be the >>> >>>
intensive
>>>private memory consumer - if you have a lot of entries in DB >>> >>>
(usrloc
>and > > > >>>aliases). To check this theory, try to start ser with DB disabled >>> >>>
in
>>>usrloc; set: >>> modparam("usrloc", "db_mode", 0) >>> >>>please see if you still get the error and also please confirm if >>> >>>
you
>>>have or not sip traffic. >>> >>> >>I don't think this is the problem. usrloc consumes private memory >>before SER forks (and at that stage it does not process SIP >> >> >messages), > > > >>when re-loading data from the database. It would fail to start if >> >> >this > > > >>was the problem, so I think there must be some other memory >> problem. >> >> >I was considering the possibility of memory fragmentation. If there > >
are
>a lot of usrloc/aliases records to be loaded, memory can get to >fragmented to be able later to alloced a bigger size chunk. > > Bot tables (aliases, location) are empty:
0(0) preload_udomain(): Table is empty 0(0) fixing /usr/local/lib/ser/modules/sl.so sl_send_reply 0(0) fixing /usr/local/lib/ser/modules/registrar.so lookup 0(0) preload_udomain(): Table is empty
Jan.