Re: [SR-Users] Out of memory in UB 210: OOM killed process 12261 (kamailio) score 0 vm:1614768kB, rss:280200kB, swap:131408kB

[Daniel-Constantin Mierla]

Hello,

that's the way it was done for older versions of kamailio.

In master and 4.4 the memory debugging is turned on and it is reflected
by the presence of DBG_SR_MEMORY in the output of 'kamailio -v'.

Anyhow, what you reported is not a leak inside kamailio memory manager,
but a leak of using system memory, so it is not affected by
DBG_SR_MEMORY and cannot be troubleshooted using the mechanisms for pkg
and shm managers.

Cheers,
Daniel


On 07/10/16 15:45, Jurijs Ivolga wrote:
> Hi Daniel,
>
> I tried to compile with memory manager in debugging mode like this:
>
> MEMDBG=1 make cfg 'include_modules= textopsx db_mysql jansson json
> snmpstats tls utils uuid'
> make all
> /etc/init.d/kamailioa stop
> make install
> /etc/init.d/kamailioa start
>
> But still I'm getting nothing on:
>
> kamailio -I | grep DBG_QM_MALLOC
>
> Any hints?
>
> With kind regards,
>
> Jurijs
>
> On Fri, Oct 7, 2016 at 10:39 AM, Daniel-Constantin Mierla
> > wrote:
>
> Hello,
>
> There are some results when searching for memory leak on openssl
> 1.0.1, but might not be valid for this case.
>
> Would you be able to run kamailio through valgrind? It may slow
> down a bit the processing, but may be the fastest way to catch the
> system memory leak. Maybe you have an instance will less traffic
> and you can run through valgrind for a while, you don't have to
> wait until you get the OOM.
>
> Cheers,
> Daniel
>
>
> On 07/10/16 09:27, Jurijs Ivolga wrote:
>> Hi Daniel,
>>
>> openssl.x86_64   
>>
>> 1.0.1e-48.el6_8.1
>> CentOS release 6.8
>>
>> With kind regards,
>>
>> Jurijs
>>
>> On Fri, Oct 7, 2016 at 10:20 AM, Daniel-Constantin Mierla
>> > wrote:
>>
>> Hello,
>>
>> the tls module in kamailio is using shm memory, but can be
>> something internal for libssl. What operating system do you
>> use and what is the libssl version?
>>
>> Cheers,
>> Daniel
>>
>>
>> On 06/10/16 17:43, Jurijs Ivolga wrote:
>>> Hi Daniel,
>>>
>>> I do not use puke.top rpc command. Maybe this issue related
>>> to TLS? Servers what has this problem are utilizing TLS
>>> heavily, servers which do not has this problem use UDP.
>>>
>>> With kind regards,
>>>
>>> Jurijs
>>>
>>> On Thu, Oct 6, 2016 at 6:05 PM, Daniel-Constantin Mierla
>>> > wrote:
>>>
>>> Hello,
>>>
>>> are you using pike.top rpc command? I noticed in the
>>> code that it uses system malloc, but I haven't
>>> investigated further yet, first to see if this would be
>>> a possibility ...
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 06/10/16 16:33, Jurijs Ivolga wrote:
 Hi Daniel,

 We do not do any external operations.

 We are using janson 2.7 everywhere. I will try to
 update to latest janson version tomorrow.
 All json operation is pretty much same, we are using
 only jansson_get.

 In attachment you can see memory consumption. On the
 right 2 servers which are faced internet on the left
 which don't face internet. As you can see memory
 consumption is pretty dramatic.

 Thank you for your help!

 With kind regards,

 Jurijs

 On Thu, Oct 6, 2016 at 5:17 PM, Daniel-Constantin
 Mierla >
 wrote:

 Hello,

 are you doing different external operations than on
 the other instances, like mi/rpc commands.

 From the list of the modules you exposed, I think
 jansson has the higher probability to work with
 system memory. Are you doing different json
 operations in config that in the other instances of
 kamailio? Are you using same version of libjansson
 everywhere?

 Cheers,
 Daniel

 On 06/10/16 13:46, Jurijs Ivolga wrote:
> Hi Daniel,
>
> This modules what we are using:
>
> loadmodule "mi_fifo.so"
> loadmodule "kex.so"
> loadmodule "corex.so"
> loadmodule "tm.so"
> loadmodule "tmx.so"
> loadmodule "sl.so"
> loadmodule "rr.so"
> loadmodule 

Re: [SR-Users] Out of memory in UB 210: OOM killed process 12261 (kamailio) score 0 vm:1614768kB, rss:280200kB, swap:131408kB

[Jurijs Ivolga]

Hi Daniel,

I tried to compile with memory manager in debugging mode like this:

MEMDBG=1 make cfg 'include_modules= textopsx db_mysql jansson json
snmpstats tls utils uuid'
make all
/etc/init.d/kamailioa stop
make install
/etc/init.d/kamailioa start

But still I'm getting nothing on:

kamailio -I | grep DBG_QM_MALLOC

Any hints?

With kind regards,

Jurijs

On Fri, Oct 7, 2016 at 10:39 AM, Daniel-Constantin Mierla  wrote:

> Hello,
>
> There are some results when searching for memory leak on openssl 1.0.1,
> but might not be valid for this case.
>
> Would you be able to run kamailio through valgrind? It may slow down a bit
> the processing, but may be the fastest way to catch the system memory leak.
> Maybe you have an instance will less traffic and you can run through
> valgrind for a while, you don't have to wait until you get the OOM.
>
> Cheers,
> Daniel
>
> On 07/10/16 09:27, Jurijs Ivolga wrote:
>
> Hi Daniel,
>
> openssl.x86_64
> 1.0.1e-48.el6_8.1
> CentOS release 6.8
>
> With kind regards,
>
> Jurijs
>
> On Fri, Oct 7, 2016 at 10:20 AM, Daniel-Constantin Mierla <
> mico...@gmail.com> wrote:
>
>> Hello,
>>
>> the tls module in kamailio is using shm memory, but can be something
>> internal for libssl. What operating system do you use and what is the
>> libssl version?
>>
>> Cheers,
>> Daniel
>>
>> On 06/10/16 17:43, Jurijs Ivolga wrote:
>>
>> Hi Daniel,
>>
>> I do not use puke.top rpc command. Maybe this issue related to TLS?
>> Servers what has this problem are utilizing TLS heavily, servers which do
>> not has this problem use UDP.
>>
>> With kind regards,
>>
>> Jurijs
>>
>> On Thu, Oct 6, 2016 at 6:05 PM, Daniel-Constantin Mierla <
>> mico...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> are you using pike.top rpc command? I noticed in the code that it uses
>>> system malloc, but I haven't investigated further yet, first to see if this
>>> would be a possibility ...
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 06/10/16 16:33, Jurijs Ivolga wrote:
>>>
>>> Hi Daniel,
>>>
>>> We do not do any external operations.
>>>
>>> We are using janson 2.7 everywhere. I will try to update to latest
>>> janson version tomorrow.
>>> All json operation is pretty much same, we are using only jansson_get.
>>>
>>> In attachment you can see memory consumption. On the right 2 servers
>>> which are faced internet on the left which don't face internet. As you can
>>> see memory consumption is pretty dramatic.
>>>
>>> Thank you for your help!
>>>
>>> With kind regards,
>>>
>>> Jurijs
>>>
>>> On Thu, Oct 6, 2016 at 5:17 PM, Daniel-Constantin Mierla <
>>> mico...@gmail.com> wrote:
>>>
 Hello,

 are you doing different external operations than on the other
 instances, like mi/rpc commands.

 From the list of the modules you exposed, I think jansson has the
 higher probability to work with system memory. Are you doing different json
 operations in config that in the other instances of kamailio? Are you using
 same version of libjansson everywhere?

 Cheers,
 Daniel
 On 06/10/16 13:46, Jurijs Ivolga wrote:

 Hi Daniel,

 This modules what we are using:

 loadmodule "mi_fifo.so"
 loadmodule "kex.so"
 loadmodule "corex.so"
 loadmodule "tm.so"
 loadmodule "tmx.so"
 loadmodule "sl.so"
 loadmodule "rr.so"
 loadmodule "pv.so"
 loadmodule "maxfwd.so"
 loadmodule "textops.so"
 loadmodule "siputils.so"
 loadmodule "xlog.so"
 loadmodule "sanity.so"
 loadmodule "ctl.so"
 loadmodule "cfg_rpc.so"
 loadmodule "mi_rpc.so"
 loadmodule "dispatcher.so"
 loadmodule "utils.so"
 loadmodule "path.so"
 loadmodule "ipops.so"
 loadmodule "jansson.so"
 loadmodule "auth.so"
 loadmodule "nathelper.so"
 loadmodule "tls.so"
 loadmodule "htable.so"
 loadmodule "pike.so"

 We have several other Kamailio instances but they are not faced to
 internet and they do not have such memory issue. That other Kamailio
 instances have same modules,  except modules listed below. So if you think
 that issue is inside external library, probably we need to check first
 modules from list below.

 loadmodule "ipops.so"
 loadmodule "auth.so"
 loadmodule "nathelper.so"
 loadmodule "pike.so"

 But maybe this other Kamailio instances do not have this memory issue,
 just because they did not face to internet and did not have same load as
 instances with memory issue.

  kamailio -v
 version: kamailio 4.4.3 (x86_64/linux) 5a2195
 flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS,
 USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP,
 PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX,
 FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR,
 USE_DST_BLACKLIST, HAVE_RESOLV_RES
 ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,

Re: [SR-Users] Order of record-route

[Dirk Teurlings - Signet B.V.]

Got an update on this from the firewall's perspective. Apparently the
Barracuda was in (SIP) Proxy mode. After turning that off and just using
plain NAT everything worked like expected.


Cheers,
Dirk

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Contacts replacing each other when registering

[Daniel-Constantin Mierla]

Hello,

there is a mode when the matching is done only on call-id. Have you
checked if they use different call-id?

Anyhow, knowing the matching mode helps looking into the code in the
right direction.

Cheers,
Daniel

On 07/10/16 12:03, Sebastian Damm wrote:
> Hi Daniel,
>
> thanks for the reply. Since we didn't configure the matching mode, it
> is 0 I guess. I actually didn't look into the usrlc module settings.
> But from the registrations, the Contacts all have a different IP
> address in it, so they shouldn't replace each other, right?
>
> Best Regards,
> Sebastian

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Contacts replacing each other when registering

[Sebastian Damm]

Hi Daniel,

thanks for the reply. Since we didn't configure the matching mode, it is 0
I guess. I actually didn't look into the usrlc module settings. But from
the registrations, the Contacts all have a different IP address in it, so
they shouldn't replace each other, right?

Best Regards,
Sebastian
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio stop processing SIP

[Igor Potjevlesch]

Yes, over UDP only.

 

Regards,

 

Igor.

 

De : Daniel-Constantin Mierla [mailto:mico...@gmail.com] 
Envoyé : vendredi 7 octobre 2016 09:25
À : Igor Potjevlesch ; 'Kamailio (SER) - Users 
Mailing List' 
Objet : Re: [SR-Users] Kamailio stop processing SIP

 

The load is not big.

Is the SIP traffic over UDP?

Cheers,
Daniel

On 06/10/16 18:16, Igor Potjevlesch wrote:

I'm using snmpstats and dialog. 

IPTables is used but not with SIP tracking module.

 

But if I work on a Wireshark trace during a representative peak period (during 
~12min), I have 30-40 INVITE/second ; 3 REGISTER/second and 7 OPTIONS/second.

 

Kamailio is running with 15 children actually.

 

Regards,

 

Igor.

 

 

De : sr-users [mailto:sr-users-boun...@lists.sip-router.org] De la part de 
Daniel-Constantin Mierla
Envoyé : jeudi 6 octobre 2016 12:54
À : Kamailio (SER) - Users Mailing List   

Objet : Re: [SR-Users] Kamailio stop processing SIP

 

Are you using pike module or any kernel/iptable module for tracking sip traffic?

If you use statsc module you can get details about how many requests were 
received per specific interval of time.

Cheers,
Daniel

 

On 06/10/16 12:38, Igor Potjevlesch wrote:

Hard to say. Is there this kind of stats on Kamailio?

 

Regards,

 

Igor.

 

De : sr-users [  
mailto:sr-users-boun...@lists.sip-router.org] De la part de Aqs Younas
Envoyé : vendredi 30 septembre 2016 11:45
À : Kamailio (SER) - Users Mailing List   

Objet : Re: [SR-Users] Kamailio stop processing SIP

 

You need to increase the number of child. What is current CPS?

 

On 30 September 2016 at 14:34, Igor Potjevlesch < 
 igor.potjevle...@gmail.com> wrote:

Hello,

 

Someone has an idea?

Again, Kamailio stop processing SIP during more than 30s. Nothing print in the 
logs.

 

The processing back on when a script detect no answer and restart the service.

Regards,

 

Igor.

 

De : Igor Potjevlesch [mailto:igor.potjevle...@gmail.com 
 ] 
Envoyé : vendredi 23 septembre 2016 11:05
À : sr-users@lists.sip-router.org  
Objet : Dimension number of child

 

Hello,

 

I'm wondering if there's a best practise to dimension the number of child to 
setup?

 

I see, very often, Kamailio that stops to reply to SIP traffic for couple a 
seconds. This cause some calls drop if RE-INVITE are not processed for example.

 

So, I'm wondering if the issue is not due to a lack of child for processing the 
SIP traffic.

 

Thank you for your inputs.

Regards,

 

Igor.


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
  sr-users@lists.sip-router.org
  
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

 







___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
  sr-users@lists.sip-router.org
  
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users






-- 
Daniel-Constantin Mierla
  http://twitter.com/#!/miconda -  
 http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Oct 24-26, 2016 -   
http://www.asipto.com





-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] kamctl - Error opening FIFO

[Hermann Norpois]

Hello,
I have problems with the behaviour of kamctl

ubuntu@ip-172-31-32-10:/etc/kamailio$ kamctl ul show
ERROR: Error opening Kamailio's FIFO /var/run/kamailio/kamailio_fifo
ERROR: Make sure you have the line 'modparam("mi_fifo", "fifo_name",
"/var/run/kamailio/kamailio_fifo")' in your config
ERROR: and also have loaded the mi_fifo module.

#my FIFO file
ubuntu@ip-172-31-32-10:/etc/kamailio$ ls -l /var/run/kamailio/kamailio_fifo
prw-rw 1 kamailio kamailio 0 Oct  7 09:01
/var/run/kamailio/kamailio_fifo

#FIFO in config
ubuntu@ip-172-31-32-10:/etc/kamailio$ grep fifo kamailio.cfg
loadmodule "mi_fifo.so"
# - mi_fifo params -
modparam("mi_fifo", "fifo_name", "/var/run/kamailio/kamailio_fifo")

#With sudo it works
ubuntu@ip-172-31-32-10:/etc/kamailio$ sudo kamctl ul show
Domain:: location table=1024 records=0 max_slot=0


Further ...

ubuntu@ip-172-31-32-10:/etc/kamailio$ kamctl restart

INFO: Stopping Kamailio :

ERROR: No PID file found (/var/run/kamailio.pid)! Kamailio probably not
running
INFO: check with 'ps axw | /bin/egrep kamailio'
#But kamailio is running
ubuntu@ip-172-31-32-10:/etc/kamailio$ ps axw|egrep kamailio
 4122 ?S  0:00 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg
-P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio
 4123 ?S  0:00 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg
-P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio
 4124 ?S  0:00 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg
-P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio
 4125 ?S  0:00 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg
-P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio
 4126 ?S  0:00 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg
-P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio
 4127 ?S  0:46 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg
-P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio
 4128 ?S  0:44 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg
-P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio
 4129 ?S  0:44 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg
-P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio
 4130 ?S  0:44 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg
-P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio
 4131 ?S  0:03 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg
-P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio
 4132 ?S909:27 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg
-P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio
 4133 ?S  0:00 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg
-P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio
 4134 ?S  5:08 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg
-P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio
 4135 ?S 25:51 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg
-P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio
 4136 ?S 26:02 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg
-P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio
 4137 ?S 26:08 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg
-P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio
 4138 ?S 26:18 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg
-P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio
 4139 ?S 10:17 /usr/sbin/kamailio -f /etc/kamailio/kamailio.cfg
-P /var/run/kamailio/kamailio.pid -m 64 -M 8 -u kamailio -g kamailio
27344 pts/1S+ 0:00 egrep --color=auto kamailio




Whats wrong with my usage of kamctl?

Thanks Hermann
___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] transaction is not suspended ERROR

[david]

hello Daniel

thanks for the response
we are using 4.4.1. 
i will try to use async_route instead

i found making some tests that the error seems to happen when there is
some delay in the connection with the FSW and we have a timeout, so it
seems there is some relation with that timeout (with lua conn:bgapi it
waits to receive an event) and having issue to do the t_suspend and
t_continue.

best regards
david



El jue, 06-10-2016 a las 12:01 +0200, Daniel-Constantin Mierla escribió:

> Hello,
> 
> 
> On 04/10/16 13:57, david wrote:
> > Hello all
> >
> > i'm having some errors sometimes and  i'm not able to know why they happen
> > i made a lua configuration script where i create some ESL sockets with
> > several freeswitches (10) (around 500-600 sockets in total, depending
> > on the number os children (8) and listen ips we have (5)), and i use
> > the lua script to send some API to the FSW by a function.
> > No matter what the FSW replies.
> > i dont know why, but i think that having that conn:bgapi($command) in
> > the lua script, makes the issue to happen. theorically, the lua script
> > waits to receive the response from the fsw through the tcp socket, and
> > after that the script continues (with an async_sleep command), but
> > after the API sent, i see (only sometimes, few times) an async_sleep
> > seem to fail when doing the t_continue with the following error
> >
> > WARNING: tm [t_suspend.c:186]: t_continue(): transaction is not
> > suspended [20748:225229907]
> I think async_sleep() is doing t_continue() internally, are you doing it
> also in the config file or the error comes from inside the c code of
> async_sleep()?
> 
> What version of kamailio are you using?
> 
> Also, it's better to use async_route() instead of async_sleep().
> >
> > could it be posible that having manye ESL sockets opened in the
> > kamailio server makes this to happen?
> > how many async workers are needed? i have 8 right now
> > is there a way where i can know or correlate the log to a $ci or
> > something known?
> >
> To get $ci in almost all logs (those that are printed when a sip message
> is processed), you can set the log_prefix core parameter:
> 
>- https://www.kamailio.org/wiki/cookbooks/4.4.x/core#log_prefix
> 
> Cheers,
> Daniel
> 


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] 420 Bad Extension error

[Infinicalls Infinicalls]

Hi Daniel,
 By pasting the following to the registrar config file, I stopped
getting Bad Extension error. And I am able to stay online. But while
dialing, it gives the "I am terribly sorry..." error.

modparam("path", "use_received", 1)
modparam("registrar", "use_path", 1)
modparam("registrar", "path_mode", 1)
modparam("registrar", "path_use_received", 1)

regards
Ganesh Kumar


On 10/7/16, Infinicalls Infinicalls  wrote:
> Hi Daniel,
> I am pasting a fresh REGISTER request and the error message here. The
> Proxy and Registrar config files are taken from
> http://kamailio.org/docs/modules/4.2.x/modules/outbound.html
>
>
> -
> root@infinicalls:~# ngrep -d any -qt -W byline . port 5060
> interface: any
> filter: (ip or ip6) and ( port 5060 )
> match: .
>
> U 2016/10/07 08:36:50.151818 52.233.25.164:5060 -> 10.0.0.4:5060
> REGISTER sip:infinicalls-proxy1.canadacentral.cloudapp.azure.com SIP/2.0.
> Via: SIP/2.0/UDP
> 10.1.0.4;branch=z9hG4bK8a33.416e8573670e015bec4d14051ceb68a8.0.
> Via: SIP/2.0/UDP
> 10.114.70.81:1330;received=113.193.151.1;rport=1330;branch=z9hG4bKPj832cd09f4be040e89dc5d9e8d17bc531.
> Max-Forwards: 69.
> From: "Balaji"
> ;tag=eda6c2494a0742b08f8fbe6254bfa385.
> To: "Balaji" .
> Call-ID: b2b13a3cfeab41228fd8127e18e5acef.
> CSeq: 26376 REGISTER.
> User-Agent: MicroSIP/3.12.3.
> Contact: "Balaji" .
> Expires: 300.
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE,
> NOTIFY, REFER, MESSAGE, OPTIONS.
> Content-Length:  0.
> Path: .
> .
>
>
> U 2016/10/07 08:36:50.154628 10.0.0.4:5060 -> 52.233.25.164:5060
> SIP/2.0 420 Bad Extension.
> Via: SIP/2.0/UDP
> 10.1.0.4;branch=z9hG4bK8a33.416e8573670e015bec4d14051ceb68a8.0;received=52.233.25.164.
> Via: SIP/2.0/UDP
> 10.114.70.81:1330;received=113.193.151.1;rport=1330;branch=z9hG4bKPj832cd09f4be040e89dc5d9e8d17bc531.
> From: "Balaji"
> ;tag=eda6c2494a0742b08f8fbe6254bfa385.
> To: "Balaji"
> ;tag=b27e1a1d33761e85846fc98f5f3a7e58.0549.
> Call-ID: b2b13a3cfeab41228fd8127e18e5acef.
> CSeq: 26376 REGISTER.
> Contact: ;expires=300.
> Unsupported: path.
> Path: .
> Supported: outbound.
> P-Registrar-Error: No support for found Path indicated.
> Server: kamailio (4.4.3 (x86_64/linux)).
> Content-Length: 0.
> .
> -
>
> Kindly let me know what went wrong. Thanks.
>
> regards
> Ganesh Kumar
>


-- 
---
http://www.infinicalls.com

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] 420 Bad Extension error

[Infinicalls Infinicalls]

Hi Daniel,
I am pasting a fresh REGISTER request and the error message here. The
Proxy and Registrar config files are taken from
http://kamailio.org/docs/modules/4.2.x/modules/outbound.html


-
root@infinicalls:~# ngrep -d any -qt -W byline . port 5060
interface: any
filter: (ip or ip6) and ( port 5060 )
match: .

U 2016/10/07 08:36:50.151818 52.233.25.164:5060 -> 10.0.0.4:5060
REGISTER sip:infinicalls-proxy1.canadacentral.cloudapp.azure.com SIP/2.0.
Via: SIP/2.0/UDP 10.1.0.4;branch=z9hG4bK8a33.416e8573670e015bec4d14051ceb68a8.0.
Via: SIP/2.0/UDP
10.114.70.81:1330;received=113.193.151.1;rport=1330;branch=z9hG4bKPj832cd09f4be040e89dc5d9e8d17bc531.
Max-Forwards: 69.
From: "Balaji" 
;tag=eda6c2494a0742b08f8fbe6254bfa385.
To: "Balaji" .
Call-ID: b2b13a3cfeab41228fd8127e18e5acef.
CSeq: 26376 REGISTER.
User-Agent: MicroSIP/3.12.3.
Contact: "Balaji" .
Expires: 300.
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE,
NOTIFY, REFER, MESSAGE, OPTIONS.
Content-Length:  0.
Path: .
.


U 2016/10/07 08:36:50.154628 10.0.0.4:5060 -> 52.233.25.164:5060
SIP/2.0 420 Bad Extension.
Via: SIP/2.0/UDP
10.1.0.4;branch=z9hG4bK8a33.416e8573670e015bec4d14051ceb68a8.0;received=52.233.25.164.
Via: SIP/2.0/UDP
10.114.70.81:1330;received=113.193.151.1;rport=1330;branch=z9hG4bKPj832cd09f4be040e89dc5d9e8d17bc531.
From: "Balaji" 
;tag=eda6c2494a0742b08f8fbe6254bfa385.
To: "Balaji" 
;tag=b27e1a1d33761e85846fc98f5f3a7e58.0549.
Call-ID: b2b13a3cfeab41228fd8127e18e5acef.
CSeq: 26376 REGISTER.
Contact: ;expires=300.
Unsupported: path.
Path: .
Supported: outbound.
P-Registrar-Error: No support for found Path indicated.
Server: kamailio (4.4.3 (x86_64/linux)).
Content-Length: 0.
.
-

Kindly let me know what went wrong. Thanks.

regards
Ganesh Kumar

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Order of record-route

[Dirk Teurlings - Signet B.V.]

This was also my understanding. But as you can understand I want to be
certain. Currently this issue only rises with the Cisco hardware in
combination with the Barracuda firewall. Other appliances seem to
respect the order properly.

On 07-10-16 09:30, Daniel-Constantin Mierla wrote:
> I think the Route set as presented in the first email is correct. The
> Client is also having a proxy, so the caller device has to use the Route
> set from bottom up, sending first to its proxy, which should send to
> Kamailio's public IP. If the caller device is sending directly to
> kamailio, then there is something wrong with that device.
> 

To be complete, this is the entire message:

Via: SIP/2.0/UDP 4.3.2.1:5060;rport=5060;branch=z9hG4bK397b.fc14665.0
Via: SIP/2.0/UDP
10.0.1.50:5060;rport=57093;received=10.0.1.50;branch=z9hG4bK60450F49
Record-Route:

Record-Route: 
Record-Route: 
Record-Route: 
From: +2233445566 ;tag=12D1120C-1C4
To: ;tag=as70bcd8b2
Call-ID: 6A54E603-894E11E6-8784FA54-A855A3EA@10.0.1.50
CSeq: 102 INVITE
Server: sip.domain.net
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY,
INFO, PUBLISH
Supported: replaces, timer
Session-Expires: 1800;refresher=uas
Contact: 
Content-Type: application/sdp
Content-Length: 237

v=0
o=charles 2051523742 2051523742 IN IP4 1.2.3.4
s=sip.domain.net
c=IN IP4 1.2.3.4
t=0 0
m=audio 13772 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv


Cheers,
Dirk

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Out of memory in UB 210: OOM killed process 12261 (kamailio) score 0 vm:1614768kB, rss:280200kB, swap:131408kB

[Daniel-Constantin Mierla]

Hello,

There are some results when searching for memory leak on openssl 1.0.1,
but might not be valid for this case.

Would you be able to run kamailio through valgrind? It may slow down a
bit the processing, but may be the fastest way to catch the system
memory leak. Maybe you have an instance will less traffic and you can
run through valgrind for a while, you don't have to wait until you get
the OOM.

Cheers,
Daniel


On 07/10/16 09:27, Jurijs Ivolga wrote:
> Hi Daniel,
>
> openssl.x86_64
>   
> 1.0.1e-48.el6_8.1
> CentOS release 6.8
>
> With kind regards,
>
> Jurijs
>
> On Fri, Oct 7, 2016 at 10:20 AM, Daniel-Constantin Mierla
> > wrote:
>
> Hello,
>
> the tls module in kamailio is using shm memory, but can be
> something internal for libssl. What operating system do you use
> and what is the libssl version?
>
> Cheers,
> Daniel
>
>
> On 06/10/16 17:43, Jurijs Ivolga wrote:
>> Hi Daniel,
>>
>> I do not use puke.top rpc command. Maybe this issue related to
>> TLS? Servers what has this problem are utilizing TLS heavily,
>> servers which do not has this problem use UDP.
>>
>> With kind regards,
>>
>> Jurijs
>>
>> On Thu, Oct 6, 2016 at 6:05 PM, Daniel-Constantin Mierla
>> > wrote:
>>
>> Hello,
>>
>> are you using pike.top rpc command? I noticed in the code
>> that it uses system malloc, but I haven't investigated
>> further yet, first to see if this would be a possibility ...
>>
>> Cheers,
>> Daniel
>>
>>
>> On 06/10/16 16:33, Jurijs Ivolga wrote:
>>> Hi Daniel,
>>>
>>> We do not do any external operations.
>>>
>>> We are using janson 2.7 everywhere. I will try to update to
>>> latest janson version tomorrow.
>>> All json operation is pretty much same, we are using only
>>> jansson_get.
>>>
>>> In attachment you can see memory consumption. On the right 2
>>> servers which are faced internet on the left which don't
>>> face internet. As you can see memory consumption is pretty
>>> dramatic.
>>>
>>> Thank you for your help!
>>>
>>> With kind regards,
>>>
>>> Jurijs
>>>
>>> On Thu, Oct 6, 2016 at 5:17 PM, Daniel-Constantin Mierla
>>> > wrote:
>>>
>>> Hello,
>>>
>>> are you doing different external operations than on the
>>> other instances, like mi/rpc commands.
>>>
>>> From the list of the modules you exposed, I think
>>> jansson has the higher probability to work with system
>>> memory. Are you doing different json operations in
>>> config that in the other instances of kamailio? Are you
>>> using same version of libjansson everywhere?
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 06/10/16 13:46, Jurijs Ivolga wrote:
 Hi Daniel,

 This modules what we are using:

 loadmodule "mi_fifo.so"
 loadmodule "kex.so"
 loadmodule "corex.so"
 loadmodule "tm.so"
 loadmodule "tmx.so"
 loadmodule "sl.so"
 loadmodule "rr.so"
 loadmodule "pv.so"
 loadmodule "maxfwd.so"
 loadmodule "textops.so"
 loadmodule "siputils.so"
 loadmodule "xlog.so"
 loadmodule "sanity.so"
 loadmodule "ctl.so"
 loadmodule "cfg_rpc.so"
 loadmodule "mi_rpc.so"
 loadmodule "dispatcher.so"
 loadmodule "utils.so"
 loadmodule "path.so"
 loadmodule "ipops.so"
 loadmodule "jansson.so"
 loadmodule "auth.so"
 loadmodule "nathelper.so"
 loadmodule "tls.so"
 loadmodule "htable.so"
 loadmodule "pike.so"

 We have several other Kamailio instances but they are
 not faced to internet and they do not have such memory
 issue. That other Kamailio instances have same
 modules,  except modules listed below. So if you think
 that issue is inside external library, probably we need
 to check first modules from list below.

 loadmodule "ipops.so"
 loadmodule "auth.so"
 loadmodule "nathelper.so"
 loadmodule "pike.so"

 But maybe this other Kamailio instances do not have
 this memory issue, just because they did not face to
 internet and did not have 

Re: [SR-Users] Order of record-route

[Daniel-Constantin Mierla]

I think the Route set as presented in the first email is correct. The
Client is also having a proxy, so the caller device has to use the Route
set from bottom up, sending first to its proxy, which should send to
Kamailio's public IP. If the caller device is sending directly to
kamailio, then there is something wrong with that device.

Cheers,
Daniel


On 06/10/16 16:38, Alex Balashov wrote:
> The order of the Record-Route headers is very relevant, and must
> strictly correspond to the order in which the intermediate proxy chain
> is traversed. The RR header of the Kamailio closest to your Client
> will be at the top of the RR stack, and this will be the first hop in
> the Route set used in in-dialog requests (e.g. end-to-end ACKs, BYEs,
> reinvites).
>
> Thus, it is entirely appropriate that your client is trying to send
> the ACK to 192.168.0.200 on the network/transport layer.
>
> -- Alex
>

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com


___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Out of memory in UB 210: OOM killed process 12261 (kamailio) score 0 vm:1614768kB, rss:280200kB, swap:131408kB

[Jurijs Ivolga]

Hi Daniel,

openssl.x86_64
1.0.1e-48.el6_8.1
CentOS release 6.8

With kind regards,

Jurijs

On Fri, Oct 7, 2016 at 10:20 AM, Daniel-Constantin Mierla  wrote:

> Hello,
>
> the tls module in kamailio is using shm memory, but can be something
> internal for libssl. What operating system do you use and what is the
> libssl version?
>
> Cheers,
> Daniel
>
> On 06/10/16 17:43, Jurijs Ivolga wrote:
>
> Hi Daniel,
>
> I do not use puke.top rpc command. Maybe this issue related to TLS?
> Servers what has this problem are utilizing TLS heavily, servers which do
> not has this problem use UDP.
>
> With kind regards,
>
> Jurijs
>
> On Thu, Oct 6, 2016 at 6:05 PM, Daniel-Constantin Mierla <
> mico...@gmail.com> wrote:
>
>> Hello,
>>
>> are you using pike.top rpc command? I noticed in the code that it uses
>> system malloc, but I haven't investigated further yet, first to see if this
>> would be a possibility ...
>>
>> Cheers,
>> Daniel
>>
>> On 06/10/16 16:33, Jurijs Ivolga wrote:
>>
>> Hi Daniel,
>>
>> We do not do any external operations.
>>
>> We are using janson 2.7 everywhere. I will try to update to latest janson
>> version tomorrow.
>> All json operation is pretty much same, we are using only jansson_get.
>>
>> In attachment you can see memory consumption. On the right 2 servers
>> which are faced internet on the left which don't face internet. As you can
>> see memory consumption is pretty dramatic.
>>
>> Thank you for your help!
>>
>> With kind regards,
>>
>> Jurijs
>>
>> On Thu, Oct 6, 2016 at 5:17 PM, Daniel-Constantin Mierla <
>> mico...@gmail.com> wrote:
>>
>>> Hello,
>>>
>>> are you doing different external operations than on the other instances,
>>> like mi/rpc commands.
>>>
>>> From the list of the modules you exposed, I think jansson has the higher
>>> probability to work with system memory. Are you doing different json
>>> operations in config that in the other instances of kamailio? Are you using
>>> same version of libjansson everywhere?
>>>
>>> Cheers,
>>> Daniel
>>> On 06/10/16 13:46, Jurijs Ivolga wrote:
>>>
>>> Hi Daniel,
>>>
>>> This modules what we are using:
>>>
>>> loadmodule "mi_fifo.so"
>>> loadmodule "kex.so"
>>> loadmodule "corex.so"
>>> loadmodule "tm.so"
>>> loadmodule "tmx.so"
>>> loadmodule "sl.so"
>>> loadmodule "rr.so"
>>> loadmodule "pv.so"
>>> loadmodule "maxfwd.so"
>>> loadmodule "textops.so"
>>> loadmodule "siputils.so"
>>> loadmodule "xlog.so"
>>> loadmodule "sanity.so"
>>> loadmodule "ctl.so"
>>> loadmodule "cfg_rpc.so"
>>> loadmodule "mi_rpc.so"
>>> loadmodule "dispatcher.so"
>>> loadmodule "utils.so"
>>> loadmodule "path.so"
>>> loadmodule "ipops.so"
>>> loadmodule "jansson.so"
>>> loadmodule "auth.so"
>>> loadmodule "nathelper.so"
>>> loadmodule "tls.so"
>>> loadmodule "htable.so"
>>> loadmodule "pike.so"
>>>
>>> We have several other Kamailio instances but they are not faced to
>>> internet and they do not have such memory issue. That other Kamailio
>>> instances have same modules,  except modules listed below. So if you think
>>> that issue is inside external library, probably we need to check first
>>> modules from list below.
>>>
>>> loadmodule "ipops.so"
>>> loadmodule "auth.so"
>>> loadmodule "nathelper.so"
>>> loadmodule "pike.so"
>>>
>>> But maybe this other Kamailio instances do not have this memory issue,
>>> just because they did not face to internet and did not have same load as
>>> instances with memory issue.
>>>
>>>  kamailio -v
>>> version: kamailio 4.4.3 (x86_64/linux) 5a2195
>>> flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS,
>>> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
>>> Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX,
>>> FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR,
>>> USE_DST_BLACKLIST, HAVE_RESOLV_RES
>>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
>>> MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
>>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>>> id: 5a2195
>>> compiled on 08:30:51 Sep 15 2016 with gcc 4.4.7
>>>
>>>
>>> With kind regards,
>>>
>>>
>>> Jurijs
>>>
>>> On Thu, Oct 6, 2016 at 12:52 PM, Daniel-Constantin Mierla <
>>> mico...@gmail.com> wrote:
>>>
 Hello,

 it looks like a leak from the system memory, not from kamailio's pkg or
 shm memory. This can be due to an improper use of an external library
 (e.g., libxml2) by a kamailio module or because of a problem in the 
 library.

 Can you list the modules used in your config (the loadmodule lines)? I
 will try to guess from the list which one relying on external libs with
 higher risk of leak issues.

 Also, provide the version of kamailio you are using (kamailio -v).

 Cheers,
 Daniel

 On 04/10/16 15:42, Jurijs Ivolga wrote:

 Hi,

 Our Kamailio server is crashing once per week, with following error:

 Oct  1 06:25:06 kamailio 

Re: [SR-Users] Kamailio stop processing SIP

[Daniel-Constantin Mierla]

The load is not big.

Is the SIP traffic over UDP?

Cheers,
Daniel

On 06/10/16 18:16, Igor Potjevlesch wrote:
>
> I'm using snmpstats and dialog.
>
> IPTables is used but not with SIP tracking module.
>
>  
>
> But if I work on a Wireshark trace during a representative peak period
> (during ~12min), I have 30-40 INVITE/second ; 3 REGISTER/second and 7
> OPTIONS/second.
>
>  
>
> Kamailio is running with 15 children actually.
>
>  
>
> Regards,
>
>  
>
> Igor.
>
>  
>
>  
>
> *De :*sr-users [mailto:sr-users-boun...@lists.sip-router.org] *De la
> part de* Daniel-Constantin Mierla
> *Envoyé :* jeudi 6 octobre 2016 12:54
> *À :* Kamailio (SER) - Users Mailing List 
> *Objet :* Re: [SR-Users] Kamailio stop processing SIP
>
>  
>
> Are you using pike module or any kernel/iptable module for tracking
> sip traffic?
>
> If you use statsc module you can get details about how many requests
> were received per specific interval of time.
>
> Cheers,
> Daniel
>
>  
>
> On 06/10/16 12:38, Igor Potjevlesch wrote:
>
> Hard to say. Is there this kind of stats on Kamailio?
>
>  
>
> Regards,
>
>  
>
> Igor.
>
>  
>
> *De :*sr-users [mailto:sr-users-boun...@lists.sip-router.org] *De
> la part de* Aqs Younas
> *Envoyé :* vendredi 30 septembre 2016 11:45
> *À :* Kamailio (SER) - Users Mailing List
>  
> *Objet :* Re: [SR-Users] Kamailio stop processing SIP
>
>  
>
> You need to increase the number of child. What is current CPS?
>
>  
>
> On 30 September 2016 at 14:34, Igor Potjevlesch
> >
> wrote:
>
> Hello,
>
>  
>
> Someone has an idea?
>
> Again, Kamailio stop processing SIP during more than 30s.
> Nothing print in the logs.
>
>  
>
> The processing back on when a script detect no answer and
> restart the service.
>
> Regards,
>
>  
>
> Igor.
>
>  
>
> *De :* Igor Potjevlesch [mailto:igor.potjevle...@gmail.com
> ]
> *Envoyé :* vendredi 23 septembre 2016 11:05
> *À :* sr-users@lists.sip-router.org
> 
> *Objet :* Dimension number of child
>
>  
>
> Hello,
>
>  
>
> I'm wondering if there's a best practise to dimension the
> number of child to setup?
>
>  
>
> I see, very often, Kamailio that stops to reply to SIP traffic
> for couple a seconds. This cause some calls drop if RE-INVITE
> are not processed for example.
>
>  
>
> So, I'm wondering if the issue is not due to a lack of child
> for processing the SIP traffic.
>
>  
>
> Thank you for your inputs.
>
> Regards,
>
>  
>
> Igor.
>
>
> ___
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users
> mailing list
> sr-users@lists.sip-router.org
> 
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>  
>
>
>
>
> ___
>
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing
> list
>
> sr-users@lists.sip-router.org 
>
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
>
> -- 
> Daniel-Constantin Mierla
> http://twitter.com/#!/miconda -
> http://www.linkedin.com/in/miconda
> Kamailio Advanced Training, Berlin, Oct 24-26, 2016 -
> http://www.asipto.com

-- 
Daniel-Constantin Mierla
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com

___
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Migrating from OpenSER config file question.

[Daniel-Constantin Mierla]

Hello,


On 06/10/16 19:30, Brian McCrary wrote:
> Hello,
>
> No, I did not have the pv module loaded!  I loaded that module and all 
> is well.  I didn't know I needed it.  I ran into a few other small 
> errors that I was able to easily fix so I now have a good config file 
> and am ready to start importing the old database in.  Thanks for your 
> help!!

good it was sorted out.

For reference, there are some migration/upgrade notes in the wiki for
each major version:

  - http://www.kamailio.org/dokuwiki/doku.php#setup
  - https://www.kamailio.org/wiki/#upgrade

Cheers,
Daniel

>
> Brian
>
>
> On Thu, Oct 06, 2016 at 11:11:02AM +0200, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> I just tested with:
>>
>> $avp(s:callfwd) = $ruri;
>>
>> using kamailio.cfg from master branch and all is ok.
>>
>> Have you loaded the pv module?
>>
>> Cheers,
>> Daniel
>>
>> On 06/10/16 00:56, Brian McCrary wrote:
>>> Hello,
>>>
>>> Thanks so much for the help in pointing me in the right direction.  I 
>>> finally had some time today to work with Kamailio a little.  I should 
>>> have pointed out I had commented the avp_write line out in the config 
>>> file and had attempted to convert it to the new format as you had 
>>> suggested.  I had $avp(s:callfwd) = $ruri; instead of $avp(callfwd) = 
>>> $ruri; but it seems both give the same error.
>>>
>>> With that being said, thanks for pointing out the sqlops module.  It 
>>> looks like I should be able to make it do everything I need, and then 
>>> some.  There are some things I have been wanting to improve upon and it 
>>> looks like this will certainly help.  There has been a lot of really 
>>> nice things added to these new releases!  I'm going to give that a go 
>>> and see if I can fix the error by eliminating the problem altogether. :)
>>>
>>> Thanks,
>>>
>>> Brian
>>>
>>> On Mon, Oct 03, 2016 at 09:00:24PM +0200, Daniel-Constantin Mierla wrote:
 Hello,

 hmm, the format $avp(s:callfwd) should still work fine. I will look
 deeper at it when I get a chance after returning to the office in few
 days. Anyhow, try to use $avp(callfwd), it is the same as $avp(callfwd)
 if you haven't defined an overlapping avp-alias.

 On the other hand, I think avp_write(...) is no longer available. Now
 you can use direct assignment, like:

 $avp(callfwd) = $ruri;

 One very useful additions (in newer versions than 1.0, otherwise being
 quite old by now) is the sqlops module that allows to do all kind of sql
 operations from configuration file, in many cases saving from the
 complexity of using avpops db functions. See:

 https://www.kamailio.org/docs/modules/stable/modules/sqlops.html#idp44901364

 So you can do INSERT/UPDATE/REPLACE/... as you need from config file,
 building the sql query with the variables you want.

 Cheers,
 Daniel

 On 30/09/16 18:29, Brian McCrary wrote:
> Hello group,
>
> I know this may be hard to believe but I'm in the process of upgrading 
> an old, but stable, OpenSER 1.0 group of servers to Kamilio.  I'm 
> basically going to sort of start from scratch with the database and 
> export my old MySQL database and write some scripts to reimport the data 
> using kamctl scripts since the database structure has changed 
> substantially since then it looks like.
>
> I've mostly migrated the config file over fairly easily, except for 
> AVPops.  I've got a section of config file that writes into the 
> usr_preferences database for call forwarding, but I seem to get the same 
> error anywhere I try to write to the database using AVPops.  Here's the 
> output I get when checking the config:
>
>  0(1378) DEBUG:  [pvapi.c:268]: pv_cache_add(): PV cache not 
> initialized, doing it now
>  0(1378) ERROR:  [pvapi.c:828]: pv_parse_spec2(): error searching 
> pvar "avp"
>  0(1378) ERROR:  [pvapi.c:1032]: pv_parse_spec2(): wrong char 
> [s/115] in [$avp(s:callfwd)] at [5 (5)]
>  0(1378) :  [cfg.y:3368]: yyerror_at(): parse error in config file 
> /usr/local/etc/kamailio/kamailio.cfg, line 145, column 4-18: Can't get 
> from cache: $avp(s:callfwd)
> ERROR: bad config file (1 errors)
>
> Here's what I think are the revelant portions of the config file:
>
> modparam("avpops", "db_url", "mysql://user:pass@localhost/kamailio")
> modparam("avpops", "avp_table", "usr_preferences")
> modparam("avpops", "uuid_column", "uuid")
> modparam("avpops", "username_column", "username")
> modparam("avpops", "domain_column", "domain")
> modparam("avpops", "attribute_column", "attribute")
> modparam("avpops", "value_column", "value")
> modparam("avpops", "type_column", "type")
> 
> if (avp_db_load("$from/username", 
> "$avp(s:callfwd)"))
> {
> 

Re: [SR-Users] Out of memory in UB 210: OOM killed process 12261 (kamailio) score 0 vm:1614768kB, rss:280200kB, swap:131408kB

[Daniel-Constantin Mierla]

Hello,

the tls module in kamailio is using shm memory, but can be something
internal for libssl. What operating system do you use and what is the
libssl version?

Cheers,
Daniel


On 06/10/16 17:43, Jurijs Ivolga wrote:
> Hi Daniel,
>
> I do not use puke.top rpc command. Maybe this issue related to TLS?
> Servers what has this problem are utilizing TLS heavily, servers which
> do not has this problem use UDP.
>
> With kind regards,
>
> Jurijs
>
> On Thu, Oct 6, 2016 at 6:05 PM, Daniel-Constantin Mierla
> > wrote:
>
> Hello,
>
> are you using pike.top rpc command? I noticed in the code that it
> uses system malloc, but I haven't investigated further yet, first
> to see if this would be a possibility ...
>
> Cheers,
> Daniel
>
>
> On 06/10/16 16:33, Jurijs Ivolga wrote:
>> Hi Daniel,
>>
>> We do not do any external operations.
>>
>> We are using janson 2.7 everywhere. I will try to update to
>> latest janson version tomorrow.
>> All json operation is pretty much same, we are using only
>> jansson_get.
>>
>> In attachment you can see memory consumption. On the right 2
>> servers which are faced internet on the left which don't face
>> internet. As you can see memory consumption is pretty dramatic.
>>
>> Thank you for your help!
>>
>> With kind regards,
>>
>> Jurijs
>>
>> On Thu, Oct 6, 2016 at 5:17 PM, Daniel-Constantin Mierla
>> > wrote:
>>
>> Hello,
>>
>> are you doing different external operations than on the other
>> instances, like mi/rpc commands.
>>
>> From the list of the modules you exposed, I think jansson has
>> the higher probability to work with system memory. Are you
>> doing different json operations in config that in the other
>> instances of kamailio? Are you using same version of
>> libjansson everywhere?
>>
>> Cheers,
>> Daniel
>>
>> On 06/10/16 13:46, Jurijs Ivolga wrote:
>>> Hi Daniel,
>>>
>>> This modules what we are using:
>>>
>>> loadmodule "mi_fifo.so"
>>> loadmodule "kex.so"
>>> loadmodule "corex.so"
>>> loadmodule "tm.so"
>>> loadmodule "tmx.so"
>>> loadmodule "sl.so"
>>> loadmodule "rr.so"
>>> loadmodule "pv.so"
>>> loadmodule "maxfwd.so"
>>> loadmodule "textops.so"
>>> loadmodule "siputils.so"
>>> loadmodule "xlog.so"
>>> loadmodule "sanity.so"
>>> loadmodule "ctl.so"
>>> loadmodule "cfg_rpc.so"
>>> loadmodule "mi_rpc.so"
>>> loadmodule "dispatcher.so"
>>> loadmodule "utils.so"
>>> loadmodule "path.so"
>>> loadmodule "ipops.so"
>>> loadmodule "jansson.so"
>>> loadmodule "auth.so"
>>> loadmodule "nathelper.so"
>>> loadmodule "tls.so"
>>> loadmodule "htable.so"
>>> loadmodule "pike.so"
>>>
>>> We have several other Kamailio instances but they are not
>>> faced to internet and they do not have such memory issue.
>>> That other Kamailio instances have same modules,  except
>>> modules listed below. So if you think that issue is inside
>>> external library, probably we need to check first modules
>>> from list below.
>>>
>>> loadmodule "ipops.so"
>>> loadmodule "auth.so"
>>> loadmodule "nathelper.so"
>>> loadmodule "pike.so"
>>>
>>> But maybe this other Kamailio instances do not have this
>>> memory issue, just because they did not face to internet and
>>> did not have same load as instances with memory issue.
>>>
>>>  kamailio -v
>>> version: kamailio 4.4.3 (x86_64/linux) 5a2195
>>> flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS,
>>> USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK,
>>> SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC,
>>> TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX,
>>> FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER,
>>> USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
>>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144,
>>> MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT
>>> PKG_SIZE 8MB
>>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>>> id: 5a2195
>>> compiled on 08:30:51 Sep 15 2016 with gcc 4.4.7
>>>
>>>
>>> With kind regards,
>>>
>>>
>>> Jurijs
>>>
>>> On Thu, Oct 6, 2016 at 12:52 PM, Daniel-Constantin Mierla
>>> > wrote:
>>>
>>> Hello,
>>>
>>> it looks like a leak from the system memory, not from
>>> kamailio's pkg or shm memory. This can be due to an
>>> improper use of an external library