Re: [SR-Users] Problem with forward on busy

2013-07-24 Thread Daniel Tryba 
On Wednesday 24 July 2013 20:41:04 LAA wrote:
> May be I'm loosing something. I have changed my config as you
> suggested (I thing so...):
> 
> if (t_check_status("486|408")) {
...
> $du = $null;
> #$du = "sip:192.168.0.197";
> append_branch();
> t_relay();


Did you try without the append_branch()? 

-- 

POCOS B.V. - Croy 9c - 5653 LC Eindhoven
Telefoon: 040 293 8661 - Fax: 040 293 8658
http://www.pocos.nl/   - http://www.sipo.nl/
K.v.K. Eindhoven 17097024

___
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] Memory leak in 3.3.4

2013-07-24 Thread Daniel-Constantin Mierla 

Hello,

can you try the attached patch? It's the same patch, just for two 
versions, one is for 3.3.x and the other for devel version


It initializes the SIP message variable that is passed to perl after 
creating the temporary environment, so it is actually destroyed by the 
perl embedded interpreter.


Cheers,
Daniel

On 7/25/13 1:29 AM, David Cunningham wrote:

Hi Daniel,

The system is running Perl 5.8.8 on Red Hat Enterprise Linux Server 
release 5.4. If I remember right programs running under Valgrind can 
have issues, so I'm not sure if the customer will want to do that. 
Ideally we'd do it on a test system, but I'm not sure if we have any 
RHEL available.

I'll see what we can do. Thanks again.


On 25 July 2013 04:55, Daniel-Constantin Mierla > wrote:


Hello,

I would say that perl_exec() is the one with the highest chances
to be the reason for the leak. Next is line would be db_mysql
module, if liked with some custom mysql client library, although
even in this case will be unlikely.

Back to perl, the module itself does not call any malloc, so it
might be the embedding Perl API that is not used properly in the
module.

Can you use some testbed, set children=1 and run kamailio under
valgrind, then do some calls and see if it detects the source of
the leak?

I'm not using the perl module, I will try to check it whenever I
get a chance in the next days. What version of perl do you have
installed?

Cheers,
Daniel


On 7/24/13 10:31 AM, David Cunningham wrote:

Hello,

We don't do any kamctl commands at all. We do have various
modules loaded, as follows. The primary functions we use Kamailio
for are phone registrations through usrloc, and routing calls to
Asterisk through logic contained in Perl via perl_exec().
Thanks for all your advice so far!

loadmodule "tm.so"
loadmodule "tmx.so"
loadmodule "usrloc.so"
loadmodule "auth.so"
loadmodule "auth_db.so"
loadmodule "ctl.so"
loadmodule "db_mysql.so"
loadmodule "kex.so"
loadmodule "maxfwd.so"
loadmodule "mi_fifo.so"
loadmodule "mi_rpc.so"
loadmodule "nathelper.so"
loadmodule "perl.so"
loadmodule "pv.so"
loadmodule "registrar.so"
loadmodule "rr.so"
loadmodule "sanity.so"
loadmodule "siputils.so"
loadmodule "sl.so"
loadmodule "textops.so"
loadmodule "xlog.so"


On 24 July 2013 16:33, Daniel-Constantin Mierla
mailto:mico...@gmail.com>> wrote:

Hello,


On 7/24/13 4:24 AM, David Cunningham wrote:

Hello,

Thank you very much for the email. In reply:

1. The system ran out of memory. Linux's oom-killer killed
Kamailio.

then all the instructions I gave are useless, they are for
debugging kamailio's internal memory manager, which handles
pkg and shm mallocs.

The chances to be from kamailio itself are very low now. Do
you do lot of mi commands (e.g., kamctl ...)? The mi api uses
system malloc, but the rest of code should use internal
memory manager which does not go beyond the limits set with
-m and -M, thus not causing an OS memory exhaustion.

Can you list what modules are you loading? At some point it
was a leak in libssl, in case you use tls a lot. But could be
another external library...

Cheers,
Daniel




2. You're right, DEBUG_MEMORY is a local configuration
setting. If defined it sets memdbg to -2, and memlog to -2.
The debug setting is -1.

3. We'll try setting mem_summary=12, thanks.

4. We'll try setting asynchronous syslog, thanks.

5.  Our configuration totals 338 lines, or approx 8.5kb. Is
that a lot?

6. We'll try setting mem_join=1, thanks.



On 23 July 2013 16:53, Daniel-Constantin Mierla
mailto:mico...@gmail.com>> wrote:

Hello,

first, to clarify, is the system memory or kamailio's
pkg/shm memory running out? If the operating system runs
out of memory, then should be a leak in a library,
because kamailio modules uses only from a pre-allocated
chunk, not going over it.


On 7/23/13 7:33 AM, David Cunningham wrote:

Hello,

We're running a Kamailio 3.3.4 system, and Kamailio
is slowly using more and more memory. Over a couple
of weeks it will run out of system memory.

We tried to enable memory debugging doing the
following, but it resulted in Kamailio not
responding to any SIP packets. Would anyone have
advice please on how to debug the situation?

1. In Makefile.defs set MEMDBG to 1 and recompile
Kamailio.
2. In kamailio.cfg add the line:

[SR-Users] XCAP table is not getting updated

2013-07-24 Thread Premchandiran 
Hi All,

I have cfg file which behaves like both presence and xcap (Integarted cfg)
took reference from
http://nil.uniza.sk/instant-messaging/simple/configuring-xcap-support-im-and
-presence-over-kamailio-31-debian-lenny. Kamailio is running but xcap table
is not getting updated. Using JTSI as client(please refer screen shot for
xcap configuration in jtsi client). I would like to know the following

 

1.)Any issue/missing in the cfg file (Please find the attached cfg
file).

2.)When xcap table will be updated. 

 



 

I kindly request to help us.

 

Regards,

Prem Chandiran M



<>

kamailio.cfg
Description: Binary data
___
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] Memory leak in 3.3.4

2013-07-24 Thread David Cunningham 
Hi Daniel,

The system is running Perl 5.8.8 on Red Hat Enterprise Linux Server release
5.4. If I remember right programs running under Valgrind can have issues,
so I'm not sure if the customer will want to do that. Ideally we'd do it on
a test system, but I'm not sure if we have any RHEL available.
I'll see what we can do. Thanks again.


On 25 July 2013 04:55, Daniel-Constantin Mierla  wrote:

>  Hello,
>
> I would say that perl_exec() is the one with the highest chances to be the
> reason for the leak. Next is line would be db_mysql module, if liked with
> some custom mysql client library, although even in this case will be
> unlikely.
>
> Back to perl, the module itself does not call any malloc, so it might be
> the embedding Perl API that is not used properly in the module.
>
> Can you use some testbed, set children=1 and run kamailio under valgrind,
> then do some calls and see if it detects the source of the leak?
>
> I'm not using the perl module, I will try to check it whenever I get a
> chance in the next days. What version of perl do you have installed?
>
> Cheers,
> Daniel
>
>
> On 7/24/13 10:31 AM, David Cunningham wrote:
>
> Hello,
>
> We don't do any kamctl commands at all. We do have various modules loaded,
> as follows. The primary functions we use Kamailio for are phone
> registrations through usrloc, and routing calls to Asterisk through logic
> contained in Perl via perl_exec().
> Thanks for all your advice so far!
>
> loadmodule "tm.so"
> loadmodule "tmx.so"
> loadmodule "usrloc.so"
> loadmodule "auth.so"
> loadmodule "auth_db.so"
> loadmodule "ctl.so"
> loadmodule "db_mysql.so"
> loadmodule "kex.so"
> loadmodule "maxfwd.so"
> loadmodule "mi_fifo.so"
> loadmodule "mi_rpc.so"
> loadmodule "nathelper.so"
> loadmodule "perl.so"
> loadmodule "pv.so"
> loadmodule "registrar.so"
> loadmodule "rr.so"
> loadmodule "sanity.so"
> loadmodule "siputils.so"
> loadmodule "sl.so"
> loadmodule "textops.so"
> loadmodule "xlog.so"
>
>
> On 24 July 2013 16:33, Daniel-Constantin Mierla  wrote:
>
>>  Hello,
>>
>>
>> On 7/24/13 4:24 AM, David Cunningham wrote:
>>
>> Hello,
>>
>>  Thank you very much for the email. In reply:
>>
>> 1. The system ran out of memory. Linux's oom-killer killed Kamailio.
>>
>> then all the instructions I gave are useless, they are for debugging
>> kamailio's internal memory manager, which handles pkg and shm mallocs.
>>
>> The chances to be from kamailio itself are very low now. Do you do lot of
>> mi commands (e.g., kamctl ...)? The mi api uses system malloc, but the rest
>> of code should use internal memory manager which does not go beyond the
>> limits set with -m and -M, thus not causing an OS memory exhaustion.
>>
>> Can you list what modules are you loading? At some point it was a leak in
>> libssl, in case you use tls a lot. But could be another external library...
>>
>> Cheers,
>> Daniel
>>
>>
>>
>> 2. You're right, DEBUG_MEMORY is a local configuration setting. If
>> defined it sets memdbg to -2, and memlog to -2. The debug setting is -1.
>>
>> 3. We'll try setting mem_summary=12, thanks.
>>
>> 4. We'll try setting asynchronous syslog, thanks.
>>
>> 5.  Our configuration totals 338 lines, or approx 8.5kb. Is that a lot?
>>
>> 6. We'll try setting mem_join=1, thanks.
>>
>>
>>
>> On 23 July 2013 16:53, Daniel-Constantin Mierla wrote:
>>
>>> Hello,
>>>
>>> first, to clarify, is the system memory or kamailio's pkg/shm memory
>>> running out? If the operating system runs out of memory, then should be a
>>> leak in a library, because kamailio modules uses only from a pre-allocated
>>> chunk, not going over it.
>>>
>>>
>>> On 7/23/13 7:33 AM, David Cunningham wrote:
>>>
 Hello,

 We're running a Kamailio 3.3.4 system, and Kamailio is slowly using
 more and more memory. Over a couple of weeks it will run out of system
 memory.

 We tried to enable memory debugging doing the following, but it
 resulted in Kamailio not responding to any SIP packets. Would anyone have
 advice please on how to debug the situation?

 1. In Makefile.defs set MEMDBG to 1 and recompile Kamailio.
 2. In kamailio.cfg add the line:
 #!define DEBUG_MEMORY 1

>>>  do you set something special in config when DEBUG_MEMORY is 1? It is
>>> not by default there, so I assume you added some rules based on this
>>> pre-processor directive.
>>>
>>> For memory troubleshooting, set memlog to a value lower than debug
>>> parameter in config file and try with mem_summary=12 for a more compact
>>> output. See more about these parameters in the wiki:
>>>
>>> - http://www.kamailio.org/wiki/cookbooks/3.3.x/core#memlog
>>>
>>> Run kamailio for a while in normal conditions, then restart it to get
>>> the memory usage summaries. There should be indication if there is some
>>> leak, by seeing memory chunks allocated many times from a function used at
>>> runtime. You can send the memory summary for a process here, we can look at
>>> it.
>>>
>>>
>>>
 While this was runni

Re: [SR-Users] Replication problems Registration Using t_replicate ().

2013-07-24 Thread Raphael Borges 
Hello, anyone have any idea for this my problem? Need to somehow override
the value of the server socket standy by entering the virtual IP in this
field.

Thanks in advance.


2013/7/23 Raphael Borges 

> Daniel, I had another similar problem. Would you like a procedure similar
> to the socket parameter. It is possible to add a new header and assign the
> parameter socket in server standby somehow?
>
> Thanks in advance.
>
>
> 2013/7/23 Raphael Borges 
>
>> Daniel, I had another similar problem. Would you like a procedure similar
>> to the socket parameter. It is possible to add a new header and assign the
>> parameter socket in server standby somehow?
>>
>> Thanks in advance.
>> Raphael
>>
>>
>> 2013/7/22 Raphael Borges 
>>
>>> Thanks Daniel, your help was very useful.
>>>
>>> With this I created a header by append_hf () before calling the function
>>> t_replicate and standby server retrieved the value of this header and
>>> assigns this value to the parameter avp
>>> Example
>>> $avp(s:rcv) = $hdr(IP-source);
>>>
>>> Best regards
>>> Raphael
>>>
>>>
>>>
>>> Hello,

 the received is taken from an avp specified by parameter received_avp
 of registrar module:

 http://kamailio.org/docs/modules/devel/modules/registrar.html#idp4433296

 You can carry the original details via a header on the replicated
 REGISTER (using append_hf()), then take the header on the second server and
 store its value in the avp.

 Cheers,
 Daniel


 On 7/18/13 9:05 PM, Raphael Borges wrote:

 *Hello,*


 I have two servers in kamailio duality, I am using the function
 t_replicate () for replication log as below:
 Server 1 active
 t_replicate ("xxx.xxx.xxx.2", "5060");
 Server 2 reserves
 t_replicate ("xxx.xxx.xxx.1", "5060");

 But when the record is replicated to the standby server the parameter
 received is being filled with the active server IP, where the IP would
 Correro UAC, registry problems generating the backup server.

 Example
 Server 1 active xxx.xxx.xxx.1

 $ Kamctl ul show
 Domain :: location table = 512 records = 1 = 1 max_slot
  AOR :: 4301
  Contact :: sip: 4...@yyy.yyy.yyy.100; transport = udp
 Q =
  Expires :: 4566
  Callid :: ccd0431c-6a4c-1231-0a94-7356c4f466e6
  CSeq :: 46740150
  User-agent :: stepo_LITE
  Received :: sip: yyy.yyy.yyy.100: 5060
  State :: CS_SYNC
  Flags :: 0
  CFLAG :: 0
  Socket :: udp: xxx.xxx.xxx.1: 5060
  Methods :: 8159

 Server 2 Reserve xxx.xxx.xxx.2

 $ Kamctl ul show
 Domain :: location table = 512 records = 1 = 1 max_slot
  AOR :: 4301
  Contact :: sip: 4...@yyy.yyy.yyy.100; transport = udp
 Q =
  Expires :: 6665
  Callid :: ec7cfd42-6a7c-1231-0f94-7356c4f466e6
  CSeq :: 46750472
  User-agent :: stepo_LITE
  Received :: sip: xxx.xxx.xxx.1: 5060
  State :: CS_SYNC
  Flags :: 0
  CFLAG :: 0
  Socket :: udp: xxx.xxx.xxx.2: 5060
  Methods :: 8159



 Tkanks

 Raphael


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


 --
 Daniel-Constantin Mierla - 
 http://www.asipto.comhttp://twitter.com/#!/miconda - 
 http://www.linkedin.com/in/miconda


 ___
 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

Re: [SR-Users] kamailio error, failed to start ubuntu precisw 12.04LTS

2013-07-24 Thread Daniel-Constantin Mierla 

Hello,

the error is:

0(8883) ERROR: db_mysql [km_my_con.c:109]: db_mysql_new_connection():
driver error: Can't connect to local MySQL server through socket
'/var/run/mysqld/mysqld.sock' (2)

Is mysql server running? Is it installed from packages or sources? What about 
the client library, installed from sources or packages?

Cheers,
Daniel


On 7/24/13 7:49 PM, jhandal wrote:

  Hi All,

I installed  the last version  "Install And Maintain Kamailio Devel Version
 From GIT"

http://www.kamailio.org/wiki/install/devel/git

This is my Log,I will appreciate any ideas.
  0(8881) DEBUG:  [cfg/cfg.c:178]: cfg_declare(): DEBUG:
register_cfg_def(): new config group has been registered: 'core' (num=49,
size=196)
  0(8881) DEBUG:  [cfg/cfg.c:178]: cfg_declare(): DEBUG:
register_cfg_def(): new config group has been registered: 'tcp' (num=26,
size=104)
  0(8881) DEBUG:  [timer.c:272]: init_timer(): init_timer: starting
with *ticks=1148741861
  0(8881) DEBUG:  [timer.c:314]: init_timer(): init_timer: timer_list
between 0x7f9865264a20 and 0x7f98652a8a20
  0(8881) INFO:  [tcp_main.c:4836]: init_tcp(): init_tcp: using
epoll_lt as the io watch method (auto detected)
  0(8883) DEBUG:  [daemonize.c:219]: enable_dumpable(): trying enable
core dumping...
  0(8883) DEBUG:  [daemonize.c:237]: enable_dumpable(): core dumping is
enabled now (1)...
  0(8883) DEBUG:  [daemonize.c:575]: set_core_dump(): core dump limits
set to 18446744073709551615
  0(8883) DEBUG:  [sr_module.c:966]: init_mod(): DEBUG: init_mod:
db_mysql
  0(8883) DEBUG: db_mysql [km_db_mysql.c:93]: kam_mysql_mod_init(): MySQL
client version is 5.5.31
  0(8883) DEBUG:  [sr_module.c:966]: init_mod(): DEBUG: init_mod:
mi_fifo
  0(8883) DEBUG: mi_fifo [mi_fifo.c:124]: mi_mod_init(): testing mi_fifo
existance ...
  0(8883) DEBUG:  [sr_module.c:966]: init_mod(): DEBUG: init_mod: kex
  0(8883) DEBUG:  [sruid.c:100]: sruid_init(): root for sruid is
[srid-51f00b9a-22b3-] (0 / 19)
  0(8883) DEBUG:  [sr_module.c:966]: init_mod(): DEBUG: init_mod: corex
  0(8883) DEBUG:  [sr_module.c:966]: init_mod(): DEBUG: init_mod: tm
  0(8883) DEBUG: tm [tm.c:789]: mod_init(): TM - (sizeof cell=5448,
sip_msg=1768) initializing...
  0(8883) DEBUG: tm [callid.c:105]: init_callid(): Call-ID initialization:
'4afe050751bd8ca9'
  0(8883) DEBUG: tm [lock.c:87]: lock_initialize(): DEBUG: lock_initialize:
lock initialization started
  0(8883) DEBUG: tm [timer.c:226]: tm_init_timers(): tm: tm_init_timers:
fr=480 fr_inv=1920 wait=80 delete=4 t1=500 t2=4000 max_inv_lifetime=2880
max_noninv_lifetime=512
  0(8883) DEBUG:  [cfg/cfg.c:178]: cfg_declare(): DEBUG:
register_cfg_def(): new config group has been registered: 'tm' (num=36,
size=168)
  0(8883) DEBUG:  [md5utils.c:67]: MD5StringArray(): DEBUG: MD5
calculated: 533cb9e91f4b999cf76861cbb9ed54ed
  0(8883) DEBUG:  [md5utils.c:67]: MD5StringArray(): DEBUG: MD5
calculated: a6a1c5f60faecf035a1ae5b6e96e979a
  0(8883) DEBUG:  [sr_module.c:966]: init_mod(): DEBUG: init_mod: tmx
  0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
  0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
  0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
  0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
  0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
  0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
  0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
  0(8883) DEBUG:  [sr_module.c:966]: init_mod(): DEBUG: init_mod: sl
  0(8883) DEBUG:  [md5utils.c:67]: MD5StringArray(): DEBUG: MD5
calculated: b27e1a1d33761e85846fc98f5f3a7e58
  0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
  0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
  0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
  0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
  0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
  0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module

Re: [SR-Users] Memory leak in 3.3.4

2013-07-24 Thread Daniel-Constantin Mierla 

Hello,

I would say that perl_exec() is the one with the highest chances to be 
the reason for the leak. Next is line would be db_mysql module, if liked 
with some custom mysql client library, although even in this case will 
be unlikely.


Back to perl, the module itself does not call any malloc, so it might be 
the embedding Perl API that is not used properly in the module.


Can you use some testbed, set children=1 and run kamailio under 
valgrind, then do some calls and see if it detects the source of the leak?


I'm not using the perl module, I will try to check it whenever I get a 
chance in the next days. What version of perl do you have installed?


Cheers,
Daniel

On 7/24/13 10:31 AM, David Cunningham wrote:

Hello,

We don't do any kamctl commands at all. We do have various modules 
loaded, as follows. The primary functions we use Kamailio for are 
phone registrations through usrloc, and routing calls to Asterisk 
through logic contained in Perl via perl_exec().

Thanks for all your advice so far!

loadmodule "tm.so"
loadmodule "tmx.so"
loadmodule "usrloc.so"
loadmodule "auth.so"
loadmodule "auth_db.so"
loadmodule "ctl.so"
loadmodule "db_mysql.so"
loadmodule "kex.so"
loadmodule "maxfwd.so"
loadmodule "mi_fifo.so"
loadmodule "mi_rpc.so"
loadmodule "nathelper.so"
loadmodule "perl.so"
loadmodule "pv.so"
loadmodule "registrar.so"
loadmodule "rr.so"
loadmodule "sanity.so"
loadmodule "siputils.so"
loadmodule "sl.so"
loadmodule "textops.so"
loadmodule "xlog.so"


On 24 July 2013 16:33, Daniel-Constantin Mierla > wrote:


Hello,


On 7/24/13 4:24 AM, David Cunningham wrote:

Hello,

Thank you very much for the email. In reply:

1. The system ran out of memory. Linux's oom-killer killed Kamailio.

then all the instructions I gave are useless, they are for
debugging kamailio's internal memory manager, which handles pkg
and shm mallocs.

The chances to be from kamailio itself are very low now. Do you do
lot of mi commands (e.g., kamctl ...)? The mi api uses system
malloc, but the rest of code should use internal memory manager
which does not go beyond the limits set with -m and -M, thus not
causing an OS memory exhaustion.

Can you list what modules are you loading? At some point it was a
leak in libssl, in case you use tls a lot. But could be another
external library...

Cheers,
Daniel




2. You're right, DEBUG_MEMORY is a local configuration setting.
If defined it sets memdbg to -2, and memlog to -2. The debug
setting is -1.

3. We'll try setting mem_summary=12, thanks.

4. We'll try setting asynchronous syslog, thanks.

5.  Our configuration totals 338 lines, or approx 8.5kb. Is that
a lot?

6. We'll try setting mem_join=1, thanks.



On 23 July 2013 16:53, Daniel-Constantin Mierla
mailto:mico...@gmail.com>> wrote:

Hello,

first, to clarify, is the system memory or kamailio's pkg/shm
memory running out? If the operating system runs out of
memory, then should be a leak in a library, because kamailio
modules uses only from a pre-allocated chunk, not going over it.


On 7/23/13 7:33 AM, David Cunningham wrote:

Hello,

We're running a Kamailio 3.3.4 system, and Kamailio is
slowly using more and more memory. Over a couple of weeks
it will run out of system memory.

We tried to enable memory debugging doing the following,
but it resulted in Kamailio not responding to any SIP
packets. Would anyone have advice please on how to debug
the situation?

1. In Makefile.defs set MEMDBG to 1 and recompile Kamailio.
2. In kamailio.cfg add the line:
#!define DEBUG_MEMORY 1

do you set something special in config when DEBUG_MEMORY is
1? It is not by default there, so I assume you added some
rules based on this pre-processor directive.

For memory troubleshooting, set memlog to a value lower than
debug parameter in config file and try with mem_summary=12
for a more compact output. See more about these parameters in
the wiki:

- http://www.kamailio.org/wiki/cookbooks/3.3.x/core#memlog

Run kamailio for a while in normal conditions, then restart
it to get the memory usage summaries. There should be
indication if there is some leak, by seeing memory chunks
allocated many times from a function used at runtime. You can
send the memory summary for a process here, we can look at it.



While this was running and Kamailio didn't respond to
packets, it logged lots of lines like this:


Do you have syslog to be configured in asynchronous mode? See
the notes from:

- http://www.kamailio.org/wiki/tutorials/3.2.x/syslog

The memdbg is less than debug value, that m

Re: [SR-Users] Problem with forward on busy

2013-07-24 Thread LAA 
Hello Hero,

Thanks for your help.

May be I'm loosing something. I have changed my config as you
suggested (I thing so...):

if (t_check_status("486|408")) {

revert_uri();
prefix("voicemail");
remove_hf("P-App-Name");
append_hf("P-App-Name: voicemail\r\n");

append_hf("P-App-Param: mod=box;usr= $rU;dom=sipproxy.a.com;uid=$

rU;did=sipproxy.a.com;\r\n");
rewritehostport("192.168.0.197:5080");
$du = $null;
#$du = "sip:192.168.0.197";
append_branch();
t_relay();

}
}

Kamailio sends back 200 OK to the UAC that originated the call, but it
never sends the new INVITE

|Time | 192.168.3.20

| 192.168.0.167 |
| |   | 192.168.0.197 |
|3,151| INVITE SDP ( telephone-event)
|   |SIP From: sip:4095@192.168.0.197
To:sip:4440@192.168.0.197
| |(5060)   -->  (5060)   |   |
|3,159| 407 Proxy Authentication Required
|   |SIP Status
| |(5060)   <--  (5060)   |   |
|3,161| ACK   |   |   |SIP
Request
| |(5060)   -->  (5060)   |   |
|3,161| INVITE SDP ( telephone-event)
|   |SIP From: sip:4095@192.168.0.197
To:sip:4440@192.168.0.197
| |(5060)   -->  (5060)   |   |
|3,174| 100 trying -- your call is important to us
|   |SIP Status
| |(5060)   <--  (5060)   |   |
|3,174|   | INVITE SDP (
telephone-event)  |SIP Request
| |   |(5060)   -->  (5060)   |
|3,176|   | 100 Trying|   |SIP
Status
| |   |(5060)   <--  (5060)   |
|3,177|   | 486 Busy Here |SIP
Status
| |   |(5060)   <--  (5060)   |
|3,180|   | ACK   |   |SIP
Request
| |   |(5060)   -->  (5060)   |
|3,195| 200 OK SDP ( telephone-event)
|   |SIP Status
| |(5060)   <--  (5060)   |   |
|3,200| ACK   |   |   |SIP
Request
| |(5060)   -->  (5060)   |   |
|3,213| RTP (GSM) |   |   |RTP
Num packets:204  Duration:4.069s SSRC:0x8494958
| |(49222)  -->  (10028)  |   |
|7,288| BYE   |   |   |SIP
Request
| |(5060)   -->  (5060)   |   |
|7,295| 200 OK|   |   |SIP
Status
| |(5060)   <--  (5060)   |   |


what am I loosing?

Regards

LAA



*


had the same issue here. you have to manually set $du=$null, else it
doesn't get reset for the failure branch.

On 7/23/13, LAA http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users>>
wrote:
>* Hi all,*>**>* I'm running Kamailio 3.0.0, with SEMS integration as Media 
>Server for Voice*>* mail. I'm trying to get a configuration to forward calls 
>on busy to voice*>* mail. I have followed without success some examples. I'm 
>using*>* revert_uri(), rewritehostport() and append_branch(), within 
>failure_route.*>* It seems to be modifying R-URI properly, and generating the 
>new branch, but*>* Kamailio is sending the new invite packet to the IP address 
>of the original*>* destination UAC, and not to the IP address of the 
>voicemail, that was*>* indicated in the R-URI. Here you can see the packet 
>flow:*>**>* |Time | 192.168.3.20*>* | 192.168.0.167
> |*>* | |   | 192.168.0.197 |*>* |5,069
>| INVITE SDP ( telephone-event)*>* |   |SIP From: 
>sip:4095 at 192.168.0.197 
>*>* To:sip:4440 
>at 192.168.0.197 
>*>* | 
>|(5060)   -->  (5060)   |   |*>* |5,071|   
>  407 Proxy Authentication Required*>* |   |SIP Status*>* 
>| |(5060)   <--  (5060)   |   |*>* 
>|5,074| ACK   |   |   |SIP*>* 
>Request*>* | |(5060)   -->  (5060)   | 
>  |*>* |5,076| INVITE SDP ( telephone-event)*>* |  
> |SIP From: sip:4095 at 192.168.0.197 
>

[SR-Users] kamailio error, failed to start ubuntu precisw 12.04LTS

2013-07-24 Thread jhandal 
 Hi All,

I installed  the last version  "Install And Maintain Kamailio Devel Version
>From GIT"

http://www.kamailio.org/wiki/install/devel/git

This is my Log,I will appreciate any ideas.
 0(8881) DEBUG:  [cfg/cfg.c:178]: cfg_declare(): DEBUG:
register_cfg_def(): new config group has been registered: 'core' (num=49,
size=196)
 0(8881) DEBUG:  [cfg/cfg.c:178]: cfg_declare(): DEBUG:
register_cfg_def(): new config group has been registered: 'tcp' (num=26,
size=104)
 0(8881) DEBUG:  [timer.c:272]: init_timer(): init_timer: starting
with *ticks=1148741861
 0(8881) DEBUG:  [timer.c:314]: init_timer(): init_timer: timer_list
between 0x7f9865264a20 and 0x7f98652a8a20
 0(8881) INFO:  [tcp_main.c:4836]: init_tcp(): init_tcp: using
epoll_lt as the io watch method (auto detected)
 0(8883) DEBUG:  [daemonize.c:219]: enable_dumpable(): trying enable
core dumping...
 0(8883) DEBUG:  [daemonize.c:237]: enable_dumpable(): core dumping is
enabled now (1)...
 0(8883) DEBUG:  [daemonize.c:575]: set_core_dump(): core dump limits
set to 18446744073709551615
 0(8883) DEBUG:  [sr_module.c:966]: init_mod(): DEBUG: init_mod:
db_mysql
 0(8883) DEBUG: db_mysql [km_db_mysql.c:93]: kam_mysql_mod_init(): MySQL
client version is 5.5.31
 0(8883) DEBUG:  [sr_module.c:966]: init_mod(): DEBUG: init_mod:
mi_fifo
 0(8883) DEBUG: mi_fifo [mi_fifo.c:124]: mi_mod_init(): testing mi_fifo
existance ...
 0(8883) DEBUG:  [sr_module.c:966]: init_mod(): DEBUG: init_mod: kex
 0(8883) DEBUG:  [sruid.c:100]: sruid_init(): root for sruid is
[srid-51f00b9a-22b3-] (0 / 19)
 0(8883) DEBUG:  [sr_module.c:966]: init_mod(): DEBUG: init_mod: corex
 0(8883) DEBUG:  [sr_module.c:966]: init_mod(): DEBUG: init_mod: tm
 0(8883) DEBUG: tm [tm.c:789]: mod_init(): TM - (sizeof cell=5448,
sip_msg=1768) initializing...
 0(8883) DEBUG: tm [callid.c:105]: init_callid(): Call-ID initialization:
'4afe050751bd8ca9'
 0(8883) DEBUG: tm [lock.c:87]: lock_initialize(): DEBUG: lock_initialize:
lock initialization started
 0(8883) DEBUG: tm [timer.c:226]: tm_init_timers(): tm: tm_init_timers:
fr=480 fr_inv=1920 wait=80 delete=4 t1=500 t2=4000 max_inv_lifetime=2880
max_noninv_lifetime=512
 0(8883) DEBUG:  [cfg/cfg.c:178]: cfg_declare(): DEBUG:
register_cfg_def(): new config group has been registered: 'tm' (num=36,
size=168)
 0(8883) DEBUG:  [md5utils.c:67]: MD5StringArray(): DEBUG: MD5
calculated: 533cb9e91f4b999cf76861cbb9ed54ed
 0(8883) DEBUG:  [md5utils.c:67]: MD5StringArray(): DEBUG: MD5
calculated: a6a1c5f60faecf035a1ae5b6e96e979a
 0(8883) DEBUG:  [sr_module.c:966]: init_mod(): DEBUG: init_mod: tmx
 0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
 0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
 0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
 0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
 0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
 0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
 0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
 0(8883) DEBUG:  [sr_module.c:966]: init_mod(): DEBUG: init_mod: sl
 0(8883) DEBUG:  [md5utils.c:67]: MD5StringArray(): DEBUG: MD5
calculated: b27e1a1d33761e85846fc98f5f3a7e58
 0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
 0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
 0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
 0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
 0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
 0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
 0(8883) DEBUG:  [sr_module.c:701]: find_mod_export_record():
find_export_record: found  in module tm
[/usr/local/lib64/kamailio/modules/tm.so]
 0(8883) DEBUG:  [sr_module.c:966]: init_mod(): DEBUG: init_mod: rr
 0(8883) DEBUG:  [sr_module.c:707]: find_mod_export_record():
find_export_record:  not found 
 0(8883) INFO: rr [../outbound/api.h:49]: ob_load_api(): Failed to impor

Re: [SR-Users] How to tie Registration with Client TCP connection

2013-07-24 Thread Vitaliy Aleksandrov 
Hello,

Is this option still not available ?
I'm asking because there was a message from, if I recall right, Olle
Johansson that removing stale registrations is on the todo list of someone
from the dev team.

So maybe someone already has this option in its devel branch ?



On Fri, Apr 5, 2013 at 10:48 AM, Daniel-Constantin Mierla  wrote:

> Hello,
>
>
> On 4/4/13 10:43 PM, Krishna Kurapati wrote:
>
>> Hi,
>>
>> With TCP, there is no way Server can establish a TCP connection through
>> client's Firewall/NAT.
>> So, when Client connection is disconnected from the server due to Network
>> issues, the Registration should be removed.
>>
>> I tried to handle this with a Event Route in tcp_read.c. However, There
>> is not an easy way to find the Registration with TCP socket info (IP and
>> Port of the Client).
>>
>> Could anyone suggest a solution?
>>
> you can use set_forward_no_connect
>
> http://www.kamailio.org/wiki/**cookbooks/4.0.x/core#set_**
> forward_no_connect
>
> Local branches will be created, but not forwarded if no connection matches
> the destination.
>
> If you follow the code for this functionality, then you should see how the
> connection is associated with a destination.
>
> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierla - http://www.asipto.com
> http://twitter.com/#!/miconda - 
> http://www.linkedin.com/in/**miconda
> Kamailio World Conference, April 16-17, 2013, Berlin
>  - http://conference.kamailio.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
>
___
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 4.0.1 presence support

2013-07-24 Thread Rupayan Dutta 
Hi Daniel,
Once again i am seeking your help.Actually  I am trying to
build a video conferencing application with sipml5 and kamailio as SIP
server.I have already configured kamailio to run on public IP .Everything
works fine when tested between desktop browsers.But when i tried
conferencing between an android mobile with 3G connection and another
desktop browser users can still login into the SIP server but conferencing
is not happening.I can't identify root cause.Please help.



On Wed, Jul 17, 2013 at 6:43 PM, Rupayan Dutta wrote:

> Sorry Daniel , I missed the WITH_PRESENCE declaration.
>
>
> On Tue, Jul 16, 2013 at 6:26 PM, Rupayan Dutta 
> wrote:
>
>> I have followed the tutorial but when tried to load XCAP server I am
>> getting following error.The following two function are not working.
>>
>> pres_update_watchers("$var(uri)", "presence");
>> pres_refresh_watchers("$var(uri)", "presence", 1);
>> unknown command, missing loadmodule?
>>
>> I am attaching my config file.
>>
>>
>> On Thu, Jun 13, 2013 at 12:48 PM, Daniel-Constantin Mierla <
>> mico...@gmail.com> wrote:
>>
>>>  Hello,
>>>
>>>
>>> On 6/11/13 2:49 PM, Rupayan Dutta wrote:
>>>
>>> Hello,
>>>I've been trying  to make the Presence thing work with kamailio
>>> 4.0.1 and SipML5 browser client .I have loaded only the modules which are
>>> already  in the Kamailio.cfg file
>>>  loadmodule "presence.so"
>>> loadmodule "presence_xml.so"
>>>
>>>
>>>  Is it necessary to load other modules as well?At the same time I
>>> request you to suggest which Sip client I should use in order to make
>>> presence work.
>>>
>>> you may need xcap_server as well for the management of contact list and
>>> access policies.
>>>
>>> You can check this tutorial:
>>> - http://kb.asipto.com/kamailio:presence:k31-made-simple
>>>
>>> It is rather old by now, but should not be difficult to adapt it for 4.0.
>>>
>>> Jitsi is a good choice for testing presence.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> --
>>> Daniel-Constantin Mierla - 
>>> http://www.asipto.comhttp://twitter.com/#!/miconda - 
>>> http://www.linkedin.com/in/miconda
>>> Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
>>>   * http://asipto.com/u/katu *
>>>
>>>
>>> ___
>>> 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

Re: [SR-Users] rtpproxy-ng doesn't work with mediaproxy-ng

2013-07-24 Thread Richard Fuchs 
On 07/24/13 05:45, Khue Nguyen Minh wrote:
> Hi all,
> 
> I am using rtpproxy-ng to control mediaproxy-ng. I was install and
> config follow this guide:
> https://github.com/sipwise/mediaproxy-ng
> when I run kamailio with rtpproxy-ng module and mediaproxy-ng I got error:
> mediaproxy-ng[25216]: Failed to properly parse UDP command line '30514_2
> d7:command4:pinge' from 127.0.0.1:54621 , using
> fallback RE
> ERROR: rtpproxy-ng [rtpproxy.c:1381]: rtpp_test(): proxy responded with
> invalid response

As a quick guess, I'd say that you used the -u option instead of the -n
option (or --listen-udp instead of --listen-ng). Substitute one for the
other and it should work.

cheers



signature.asc
Description: OpenPGP digital signature
___
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] rtpproxy-ng doesn't work with mediaproxy-ng

2013-07-24 Thread Khue Nguyen Minh 
Hi all,

I am using rtpproxy-ng to control mediaproxy-ng. I was install and config
follow this guide:
https://github.com/sipwise/mediaproxy-ng
when I run kamailio with rtpproxy-ng module and mediaproxy-ng I got error:
mediaproxy-ng[25216]: Failed to properly parse UDP command line '30514_2
d7:command4:pinge' from 127.0.0.1:54621, using fallback RE
ERROR: rtpproxy-ng [rtpproxy.c:1381]: rtpp_test(): proxy responded with
invalid response
How I can fix it?

Thanks,
Khue.
___
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] Memory leak in 3.3.4

2013-07-24 Thread David Cunningham 
Hello,

We don't do any kamctl commands at all. We do have various modules loaded,
as follows. The primary functions we use Kamailio for are phone
registrations through usrloc, and routing calls to Asterisk through logic
contained in Perl via perl_exec().
Thanks for all your advice so far!

loadmodule "tm.so"
loadmodule "tmx.so"
loadmodule "usrloc.so"
loadmodule "auth.so"
loadmodule "auth_db.so"
loadmodule "ctl.so"
loadmodule "db_mysql.so"
loadmodule "kex.so"
loadmodule "maxfwd.so"
loadmodule "mi_fifo.so"
loadmodule "mi_rpc.so"
loadmodule "nathelper.so"
loadmodule "perl.so"
loadmodule "pv.so"
loadmodule "registrar.so"
loadmodule "rr.so"
loadmodule "sanity.so"
loadmodule "siputils.so"
loadmodule "sl.so"
loadmodule "textops.so"
loadmodule "xlog.so"


On 24 July 2013 16:33, Daniel-Constantin Mierla  wrote:

>  Hello,
>
>
> On 7/24/13 4:24 AM, David Cunningham wrote:
>
> Hello,
>
> Thank you very much for the email. In reply:
>
> 1. The system ran out of memory. Linux's oom-killer killed Kamailio.
>
> then all the instructions I gave are useless, they are for debugging
> kamailio's internal memory manager, which handles pkg and shm mallocs.
>
> The chances to be from kamailio itself are very low now. Do you do lot of
> mi commands (e.g., kamctl ...)? The mi api uses system malloc, but the rest
> of code should use internal memory manager which does not go beyond the
> limits set with -m and -M, thus not causing an OS memory exhaustion.
>
> Can you list what modules are you loading? At some point it was a leak in
> libssl, in case you use tls a lot. But could be another external library...
>
> Cheers,
> Daniel
>
>
>
> 2. You're right, DEBUG_MEMORY is a local configuration setting. If defined
> it sets memdbg to -2, and memlog to -2. The debug setting is -1.
>
> 3. We'll try setting mem_summary=12, thanks.
>
> 4. We'll try setting asynchronous syslog, thanks.
>
> 5.  Our configuration totals 338 lines, or approx 8.5kb. Is that a lot?
>
> 6. We'll try setting mem_join=1, thanks.
>
>
>
> On 23 July 2013 16:53, Daniel-Constantin Mierla  wrote:
>
>> Hello,
>>
>> first, to clarify, is the system memory or kamailio's pkg/shm memory
>> running out? If the operating system runs out of memory, then should be a
>> leak in a library, because kamailio modules uses only from a pre-allocated
>> chunk, not going over it.
>>
>>
>> On 7/23/13 7:33 AM, David Cunningham wrote:
>>
>>> Hello,
>>>
>>> We're running a Kamailio 3.3.4 system, and Kamailio is slowly using more
>>> and more memory. Over a couple of weeks it will run out of system memory.
>>>
>>> We tried to enable memory debugging doing the following, but it resulted
>>> in Kamailio not responding to any SIP packets. Would anyone have advice
>>> please on how to debug the situation?
>>>
>>> 1. In Makefile.defs set MEMDBG to 1 and recompile Kamailio.
>>> 2. In kamailio.cfg add the line:
>>> #!define DEBUG_MEMORY 1
>>>
>>  do you set something special in config when DEBUG_MEMORY is 1? It is not
>> by default there, so I assume you added some rules based on this
>> pre-processor directive.
>>
>> For memory troubleshooting, set memlog to a value lower than debug
>> parameter in config file and try with mem_summary=12 for a more compact
>> output. See more about these parameters in the wiki:
>>
>> - http://www.kamailio.org/wiki/cookbooks/3.3.x/core#memlog
>>
>> Run kamailio for a while in normal conditions, then restart it to get the
>> memory usage summaries. There should be indication if there is some leak,
>> by seeing memory chunks allocated many times from a function used at
>> runtime. You can send the memory summary for a process here, we can look at
>> it.
>>
>>
>>
>>> While this was running and Kamailio didn't respond to packets, it logged
>>> lots of lines like this:
>>>
>>
>>  Do you have syslog to be configured in asynchronous mode? See the notes
>> from:
>>
>> - http://www.kamailio.org/wiki/tutorials/3.2.x/syslog
>>
>> The memdbg is less than debug value, that means printing few log messages
>> for each memory operation. You can make memdbg higher and rely on memlog
>> for memory summaries, otherwise will be lot of log messages related to
>> memory.
>>
>>
>>> Jul 22 21:32:22 hostname kamailio: :  [mem/q_malloc.c:369]:
>>> qm_malloc(0x4000e008, 128) called from : cfg.lex: addstr(1438)
>>> Jul 22 21:32:22 hostname kamailio: :  [mem/q_malloc.c:413]:
>>> qm_malloc(0x4000e008, 128) returns address 0x40048918 frag. 0x40048900
>>> (size=128) on 1 -th hit
>>> Jul 22 21:32:22 hostname kamailio: :  [mem/q_malloc.c:369]:
>>> qm_malloc(0x4000e008, 128) called from : cfg.lex: addstr(1438)
>>> Jul 22 21:32:22 hostname kamailio: :  [mem/q_malloc.c:413]:
>>> qm_malloc(0x4000e008, 128) returns address 0x400489c8 frag. 0x400489b0
>>> (size=128) on 1 -th hit
>>>
>>  addstr() is a function used only for parsing configuration file, as long
>> as you can still see them, the configuration file parsing was not finish.
>> addstr() is not a source of leaks because it is not used at runtime