[OpenSIPS-Users] Opensips routing

2017-03-06 Thread Denis via Users
Hello! Server:: OpenSIPS (2.2.2 (x86_64/linux)) In the link https://yadi.sk/d/6r2V-d7Y3FBTbV you can find archive with two files:- log of the call;- a part of the cfg file. In the log;1.1.1.1 - caller2.2.2.2 - Opensips3.3.3.3 - callee. The question is, should Opensips, in such situation (have a look log), makes call to the alternative direction (present in dr_carriers) in case of $avp(1229)==1 (have a look cfg) and $var(radius) !==1 (have a look cfg)? Thank you. -- С уважением, Денис.Best regards, Denis   ___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Minimum SIP Headers

2017-03-06 Thread Alex Balashov
There are a lot of philosophical questions around whether OpenSIPS is
obligated to validate SIP requests to the extent that a UAS would,
especially when acting in its normal capacity as a proxy rather than a
UAS.

By one account, its job is to relay requests, not to enforce rules
expressed at the UA layer where failure to adhere to them does not
adversely affect the proxy's ability to relay the message.

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) 
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


[OpenSIPS-Users] Minimum SIP Headers

2017-03-06 Thread Annus Fictus

Hello,

on section 8.1.1 RFC 3261: " A valid SIP request formulated by a UAC 
MUST, at a minimum, contain the following header fields: To, From, CSeq, 
Call-ID, Max-Forwards,and Via;"


I'm sending to OpenSIPs a SIP INVITE (with SIPSAK) with these headers:

Via, From, To, Call-ID and Cseq (without Max-Forwars); OpenSIPs accept 
the message without problems. Is this the expected behavior?


Without other Header (between the six) the result is: 
ERROR:tm:t_lookup_request: too few headers


Thank you

Regards



___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Quest to find memory leak

2017-03-06 Thread John Nash
here is another trace
http://pastebin.com/9Ge2NEVQ

I see lot of alloc request but no free.

On Mon, Mar 6, 2017 at 6:57 PM, John Nash  wrote:

> Ok will try that. Is it possible that wrong usage of drouting may cause
> this to happen instead of actual leak?... What are the things private
> memory is used for?
>
> On Mon, Mar 6, 2017 at 6:48 PM, Răzvan Crainea 
> wrote:
>
>> Hi, John!
>>
>> From the dump you sent, I don't see any leaks. Perhaps some of those
>> fragments increase over time. Can you make a memory dump after the server
>> runs some time, like after it gets 100 messages?
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Solutionswww.opensips-solutions.com
>>
>> On 03/06/2017 03:02 PM, John Nash wrote:
>>
>> Here is the dump
>> http://pastebin.com/DTEHF5Vc
>>
>> On Mon, Mar 6, 2017 at 6:20 PM, Răzvan Crainea 
>> wrote:
>>
>>> None of the "actions" you are talking about have big impact on private
>>> memory, but the shared one. Better do the dump and send it over to point
>>> out what is "eating" memory.
>>>
>>> Best regards,
>>>
>>> Răzvan Crainea
>>> OpenSIPS Solutionswww.opensips-solutions.com
>>>
>>> On 03/06/2017 02:39 PM, John Nash wrote:
>>>
>>> with every call attempt it decreases. I tried some changes by rejecting
>>> invite before drouting call (That means after auth , dispatcher) and found
>>> memory is stable but when drouting sends Invite to external gateway and
>>> external gateway rejects it. Then this issue happens.
>>>
>>> Inuse transactions and active dialogs also 0. Somthing wrong happening
>>> in handling of failure replies. But apart from use_next_gw and setting
>>> some avps for CDR not much going on there.
>>>
>>> On Mon, Mar 6, 2017 at 5:54 PM, Răzvan Crainea 
>>> wrote:
>>>
 Ok, so it is the first listener for the private IP that leaks. Next, is
 the memory stabilizing in time? Or it is continously decreasing?
 Yes, that's how you should make the dump.

 Best regards,

 Răzvan Crainea
 OpenSIPS Solutionswww.opensips-solutions.com

 On 03/06/2017 10:57 AM, John Nash wrote:

 Dear Razvan,

 Below is the info on my processes
 Process::  ID=0 PID=17351 Type=attendant
 Process::  ID=1 PID=17352 Type=MI FIFO
 Process::  ID=2 PID=17353 Type=MI Datagram
 Process::  ID=3 PID=17354 Type=time_keeper
 Process::  ID=4 PID=17355 Type=timer
 Process::  ID=5 PID=17356 Type=SIP receiver udp:1.1.1.1:9094
 Process::  ID=6 PID=17357 Type=SIP receiver udp:1.1.1.1:5060
 Process::  ID=7 PID=17358 Type=SIP receiver udp:192.168.45.5:5064
 Process::  ID=8 PID=17359 Type=Timer handler

 1.1.1.1 is public IP (I changed). The decrease in memory I see is for
 Process::  ID=7 PID=17358 mainly. My call flow is as following

 - New Invite hits the opensips on 1.1.1.1:9094
 - Apart from message validity checks I query DB to check if its a valid
 user (Using local cache also there)
 - Create dialog, Topology_hiding functions are called along with some
 avp population
 - Using dispatcher ds_select_domain Call sent to udp:192.168.45.2:7060
 (using force socket). This 192.168.45.2:7060 is actually freeswitch
 - Call again comes back to opensips on udp:192.168.45.5:5064
 - New dialog is created and topology_hiding is called
 - Drouting function do_routing is called which tries one gateway and
 fails


 Dump i need to create with memlog=4 memdump=1 right?









 On Mon, Mar 6, 2017 at 2:05 PM, Răzvan Crainea 
 wrote:

> Hi, John!
>
> Transactions are stored in shared memory, not in the private one. So
> the possible leak you are facing its not related to transactions.
> During runtime, OpenSIPS might resize some internal structures, which
> may lead to increase memory usage. However, after a while, these
> allocations should stabilize .
> Can you post the output of the kill -SIGUSR1 on pastebin so we can
> take a look? Also, what type of process is the one you are seeing the leak
> into? You can find out using the 'opensipsctl ps' command.
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 03/06/2017 09:55 AM, John Nash wrote:
>
> I am using OpenSIPS (2.1.5 (x86_64/linux)) in production. I observed
> private memory is decreasing constantly for one process mainly and
> ultimately leading to memory errors and crash.
>
> To debug this issue I prepared a test server and compiled opensips as
> per https://www.opensips.org/Documentation/TroubleShooting-OutOfMem
>
> I made only one single call (which was rejected by opensips as it was
> not authorized user) and I saw private free memory decreased. I was hoping
> since transaction is done ideally 

Re: [OpenSIPS-Users] Quest to find memory leak

2017-03-06 Thread John Nash
Ok will try that. Is it possible that wrong usage of drouting may cause
this to happen instead of actual leak?... What are the things private
memory is used for?

On Mon, Mar 6, 2017 at 6:48 PM, Răzvan Crainea  wrote:

> Hi, John!
>
> From the dump you sent, I don't see any leaks. Perhaps some of those
> fragments increase over time. Can you make a memory dump after the server
> runs some time, like after it gets 100 messages?
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 03/06/2017 03:02 PM, John Nash wrote:
>
> Here is the dump
> http://pastebin.com/DTEHF5Vc
>
> On Mon, Mar 6, 2017 at 6:20 PM, Răzvan Crainea 
> wrote:
>
>> None of the "actions" you are talking about have big impact on private
>> memory, but the shared one. Better do the dump and send it over to point
>> out what is "eating" memory.
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Solutionswww.opensips-solutions.com
>>
>> On 03/06/2017 02:39 PM, John Nash wrote:
>>
>> with every call attempt it decreases. I tried some changes by rejecting
>> invite before drouting call (That means after auth , dispatcher) and found
>> memory is stable but when drouting sends Invite to external gateway and
>> external gateway rejects it. Then this issue happens.
>>
>> Inuse transactions and active dialogs also 0. Somthing wrong happening in
>> handling of failure replies. But apart from use_next_gw and setting some
>> avps for CDR not much going on there.
>>
>> On Mon, Mar 6, 2017 at 5:54 PM, Răzvan Crainea 
>> wrote:
>>
>>> Ok, so it is the first listener for the private IP that leaks. Next, is
>>> the memory stabilizing in time? Or it is continously decreasing?
>>> Yes, that's how you should make the dump.
>>>
>>> Best regards,
>>>
>>> Răzvan Crainea
>>> OpenSIPS Solutionswww.opensips-solutions.com
>>>
>>> On 03/06/2017 10:57 AM, John Nash wrote:
>>>
>>> Dear Razvan,
>>>
>>> Below is the info on my processes
>>> Process::  ID=0 PID=17351 Type=attendant
>>> Process::  ID=1 PID=17352 Type=MI FIFO
>>> Process::  ID=2 PID=17353 Type=MI Datagram
>>> Process::  ID=3 PID=17354 Type=time_keeper
>>> Process::  ID=4 PID=17355 Type=timer
>>> Process::  ID=5 PID=17356 Type=SIP receiver udp:1.1.1.1:9094
>>> Process::  ID=6 PID=17357 Type=SIP receiver udp:1.1.1.1:5060
>>> Process::  ID=7 PID=17358 Type=SIP receiver udp:192.168.45.5:5064
>>> Process::  ID=8 PID=17359 Type=Timer handler
>>>
>>> 1.1.1.1 is public IP (I changed). The decrease in memory I see is for
>>> Process::  ID=7 PID=17358 mainly. My call flow is as following
>>>
>>> - New Invite hits the opensips on 1.1.1.1:9094
>>> - Apart from message validity checks I query DB to check if its a valid
>>> user (Using local cache also there)
>>> - Create dialog, Topology_hiding functions are called along with some
>>> avp population
>>> - Using dispatcher ds_select_domain Call sent to udp:192.168.45.2:7060
>>> (using force socket). This 192.168.45.2:7060 is actually freeswitch
>>> - Call again comes back to opensips on udp:192.168.45.5:5064
>>> - New dialog is created and topology_hiding is called
>>> - Drouting function do_routing is called which tries one gateway and
>>> fails
>>>
>>>
>>> Dump i need to create with memlog=4 memdump=1 right?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Mon, Mar 6, 2017 at 2:05 PM, Răzvan Crainea 
>>> wrote:
>>>
 Hi, John!

 Transactions are stored in shared memory, not in the private one. So
 the possible leak you are facing its not related to transactions.
 During runtime, OpenSIPS might resize some internal structures, which
 may lead to increase memory usage. However, after a while, these
 allocations should stabilize .
 Can you post the output of the kill -SIGUSR1 on pastebin so we can take
 a look? Also, what type of process is the one you are seeing the leak into?
 You can find out using the 'opensipsctl ps' command.

 Best regards,

 Răzvan Crainea
 OpenSIPS Solutionswww.opensips-solutions.com

 On 03/06/2017 09:55 AM, John Nash wrote:

 I am using OpenSIPS (2.1.5 (x86_64/linux)) in production. I observed
 private memory is decreasing constantly for one process mainly and
 ultimately leading to memory errors and crash.

 To debug this issue I prepared a test server and compiled opensips as
 per https://www.opensips.org/Documentation/TroubleShooting-OutOfMem

 I made only one single call (which was rejected by opensips as it was
 not authorized user) and I saw private free memory decreased. I was hoping
 since transaction is done ideally it should release memory and should show
 me same memory as startup but it did not. I verified this with many call
 attempts and i see free memory is always decreasing slowly.

 I used kill -SIGUSR1  to create memory dump. But i am
 unable to make sense of it. It shows log like ...

Re: [OpenSIPS-Users] t_uac_dlg command through mi_datagram socket gives 400 bad headers

2017-03-06 Thread Husnain Taseer
Hi,

I have got hint from ctd.sh script and modified my string as per the string
being used in that script for INVITE. After modification I am getting error
Content-Type missing. The string is now as follows:

message=""":t_uac_dlg:
MESSAGE
sip:212897645@192.168.1.20
.
.
"From: \\r\\nTo:
\\r\\nContent-Type:
text/plain\\r\\np-identifier: Local_Socket_V1.0\\r\\n
"
"Hi
"
"""

​The debug logs for mi_datagram module are as follows:
​
Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:identify_command: the command starts here:
t_uac_dlg:#012MESSAGE#012sip:212897645@192.168.1.20#012.#012.#012"
From: \r\nTo:
\r\nContent-Type:
text/plain\r\np-identifier: Local_Socket_V1.0\r\n#012"#012"Hi#012"
Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:identify_command: the command is t_uac_dlg
Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:identify_command: dtgram->len is 195
Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:identify_command: dtgram->len is 183
Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:mi_datagram_server: we have a valid command
Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:mi_datagram_server: after identifing the command, the
received datagram is MESSAGE#012sip:212897645@192.168.1.20#012.#012.#012"From:
\r\nTo:
\r\nContent-Type:
text/plain\r\np-identifier: Local_Socket_V1.0\r\n#012"#012"Hi#012"

Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:mi_datagram_parse_tree: adding node <> ; val \r\nTo:
\r\nContent-Type:
text/plain\r\np-identifier: Local_Socket_V1.0\r\n#012>
Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:mi_datagram_parse_tree: the remaining datagram has 7 bytes
Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:mi_datagram_parse_node: the remaining datagram to be parsed
is #012"Hi#012"#012 and 7 in length
Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:mi_datagram_parse_node: we have a  quoted value, "Hi#012"
Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:mi_datagram_parse_node: " found p is "
Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:mi_datagram_parse_node: we have reached the end of attr
value, p is "
Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:mi_datagram_parse_node: attr value  found
Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:mi_datagram_parse_node: line ended properly case1
Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:mi_datagram_parse_node: 1 data->len is 7
Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:mi_datagram_parse_node: 2 data->len is 1
Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:mi_datagram_parse_tree: adding node <> ; val 
Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:mi_datagram_parse_tree: the remaining datagram has 1 bytes
Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:mi_datagram_parse_node: the remaining datagram to be parsed
is #012 and 1 in length
Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:mi_datagram_server: done parsing the mi tree
Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:mi_datagram_server: command process (t_uac_dlg)succeded
Mar  6 16:01:53 VoIPDevSys opensips[26600]:
DBG:mi_datagram:mi_datagram_server: the response: 400 Content-Type
missin#012 has been sent in 24 octets

​From above logs I can see that Content-Type is present in the request but
still I am getting this error and opensips is sending back 400 Content-Type
missin#012​. The above logs are not complete if you need complete logs I
can give you on pastebin.


Regards,
*Husnain Taseer*
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Quest to find memory leak

2017-03-06 Thread Răzvan Crainea

Hi, John!

From the dump you sent, I don't see any leaks. Perhaps some of those 
fragments increase over time. Can you make a memory dump after the 
server runs some time, like after it gets 100 messages?


Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 03/06/2017 03:02 PM, John Nash wrote:

Here is the dump
http://pastebin.com/DTEHF5Vc

On Mon, Mar 6, 2017 at 6:20 PM, Răzvan Crainea > wrote:


None of the "actions" you are talking about have big impact on
private memory, but the shared one. Better do the dump and send it
over to point out what is "eating" memory.

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com 

On 03/06/2017 02:39 PM, John Nash wrote:

with every call attempt it decreases. I tried some changes by
rejecting invite before drouting call (That means after auth ,
dispatcher) and found memory is stable but when drouting sends
Invite to external gateway and external gateway rejects it. Then
this issue happens.

Inuse transactions and active dialogs also 0. Somthing wrong
happening in handling of failure replies. But apart from
use_next_gw and setting some avps for CDR not much going on there.

On Mon, Mar 6, 2017 at 5:54 PM, Răzvan Crainea
> wrote:

Ok, so it is the first listener for the private IP that
leaks. Next, is the memory stabilizing in time? Or it is
continously decreasing?
Yes, that's how you should make the dump.

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com 

On 03/06/2017 10:57 AM, John Nash wrote:

Dear Razvan,

Below is the info on my processes
Process::  ID=0 PID=17351 Type=attendant
Process::  ID=1 PID=17352 Type=MI FIFO
Process::  ID=2 PID=17353 Type=MI Datagram
Process::  ID=3 PID=17354 Type=time_keeper
Process::  ID=4 PID=17355 Type=timer
Process::  ID=5 PID=17356 Type=SIP receiver udp:1.1.1.1:9094

Process::  ID=6 PID=17357 Type=SIP receiver udp:1.1.1.1:5060

Process::  ID=7 PID=17358 Type=SIP receiver
udp:192.168.45.5:5064 
Process::  ID=8 PID=17359 Type=Timer handler

1.1.1.1 is public IP (I changed). The decrease in memory I
see is for Process::  ID=7 PID=17358 mainly. My call flow is
as following

- New Invite hits the opensips on 1.1.1.1:9094

- Apart from message validity checks I query DB to check if
its a valid user (Using local cache also there)
- Create dialog, Topology_hiding functions are called along
with some avp population
- Using dispatcher ds_select_domain Call sent to
udp:192.168.45.2:7060  (using
force socket). This 192.168.45.2:7060
 is actually freeswitch
- Call again comes back to opensips on udp:192.168.45.5:5064

- New dialog is created and topology_hiding is called
- Drouting function do_routing is called which tries one
gateway and fails


Dump i need to create with memlog=4 memdump=1 right?









On Mon, Mar 6, 2017 at 2:05 PM, Răzvan Crainea
> wrote:

Hi, John!

Transactions are stored in shared memory, not in the
private one. So the possible leak you are facing its not
related to transactions.
During runtime, OpenSIPS might resize some internal
structures, which may lead to increase memory usage.
However, after a while, these allocations should stabilize.
Can you post the output of the kill -SIGUSR1 on pastebin
so we can take a look? Also, what type of process is the
one you are seeing the leak into? You can find out using
the 'opensipsctl ps' command.

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com


On 03/06/2017 09:55 AM, John Nash wrote:

I am using OpenSIPS (2.1.5 (x86_64/linux)) in
production. I observed private memory is decreasing
constantly for one process mainly and ultimately
leading to memory errors and crash.

To debug this issue I prepared a test server and
compiled opensips as per
https://www.opensips.org/Documentation/TroubleShooting-OutOfMem

Re: [OpenSIPS-Users] Quest to find memory leak

2017-03-06 Thread John Nash
Here is the dump
http://pastebin.com/DTEHF5Vc

On Mon, Mar 6, 2017 at 6:20 PM, Răzvan Crainea  wrote:

> None of the "actions" you are talking about have big impact on private
> memory, but the shared one. Better do the dump and send it over to point
> out what is "eating" memory.
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 03/06/2017 02:39 PM, John Nash wrote:
>
> with every call attempt it decreases. I tried some changes by rejecting
> invite before drouting call (That means after auth , dispatcher) and found
> memory is stable but when drouting sends Invite to external gateway and
> external gateway rejects it. Then this issue happens.
>
> Inuse transactions and active dialogs also 0. Somthing wrong happening in
> handling of failure replies. But apart from use_next_gw and setting some
> avps for CDR not much going on there.
>
> On Mon, Mar 6, 2017 at 5:54 PM, Răzvan Crainea 
> wrote:
>
>> Ok, so it is the first listener for the private IP that leaks. Next, is
>> the memory stabilizing in time? Or it is continously decreasing?
>> Yes, that's how you should make the dump.
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Solutionswww.opensips-solutions.com
>>
>> On 03/06/2017 10:57 AM, John Nash wrote:
>>
>> Dear Razvan,
>>
>> Below is the info on my processes
>> Process::  ID=0 PID=17351 Type=attendant
>> Process::  ID=1 PID=17352 Type=MI FIFO
>> Process::  ID=2 PID=17353 Type=MI Datagram
>> Process::  ID=3 PID=17354 Type=time_keeper
>> Process::  ID=4 PID=17355 Type=timer
>> Process::  ID=5 PID=17356 Type=SIP receiver udp:1.1.1.1:9094
>> Process::  ID=6 PID=17357 Type=SIP receiver udp:1.1.1.1:5060
>> Process::  ID=7 PID=17358 Type=SIP receiver udp:192.168.45.5:5064
>> Process::  ID=8 PID=17359 Type=Timer handler
>>
>> 1.1.1.1 is public IP (I changed). The decrease in memory I see is for
>> Process::  ID=7 PID=17358 mainly. My call flow is as following
>>
>> - New Invite hits the opensips on 1.1.1.1:9094
>> - Apart from message validity checks I query DB to check if its a valid
>> user (Using local cache also there)
>> - Create dialog, Topology_hiding functions are called along with some avp
>> population
>> - Using dispatcher ds_select_domain Call sent to udp:192.168.45.2:7060
>> (using force socket). This 192.168.45.2:7060 is actually freeswitch
>> - Call again comes back to opensips on udp:192.168.45.5:5064
>> - New dialog is created and topology_hiding is called
>> - Drouting function do_routing is called which tries one gateway and fails
>>
>>
>> Dump i need to create with memlog=4 memdump=1 right?
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Mar 6, 2017 at 2:05 PM, Răzvan Crainea 
>> wrote:
>>
>>> Hi, John!
>>>
>>> Transactions are stored in shared memory, not in the private one. So the
>>> possible leak you are facing its not related to transactions.
>>> During runtime, OpenSIPS might resize some internal structures, which
>>> may lead to increase memory usage. However, after a while, these
>>> allocations should stabilize .
>>> Can you post the output of the kill -SIGUSR1 on pastebin so we can take
>>> a look? Also, what type of process is the one you are seeing the leak into?
>>> You can find out using the 'opensipsctl ps' command.
>>>
>>> Best regards,
>>>
>>> Răzvan Crainea
>>> OpenSIPS Solutionswww.opensips-solutions.com
>>>
>>> On 03/06/2017 09:55 AM, John Nash wrote:
>>>
>>> I am using OpenSIPS (2.1.5 (x86_64/linux)) in production. I observed
>>> private memory is decreasing constantly for one process mainly and
>>> ultimately leading to memory errors and crash.
>>>
>>> To debug this issue I prepared a test server and compiled opensips as
>>> per https://www.opensips.org/Documentation/TroubleShooting-OutOfMem
>>>
>>> I made only one single call (which was rejected by opensips as it was
>>> not authorized user) and I saw private free memory decreased. I was hoping
>>> since transaction is done ideally it should release memory and should show
>>> me same memory as startup but it did not. I verified this with many call
>>> attempts and i see free memory is always decreasing slowly.
>>>
>>> I used kill -SIGUSR1  to create memory dump. But i am unable
>>> to make sense of it. It shows log like ...
>>>
>>> r  6 07:29:19 Server3021 opensips[13276]: Memory status (pkg):
>>> Mar  6 07:29:19 Server3021 opensips[13276]: qm_status (0x7f5b8ebba010):
>>> Mar  6 07:29:19 Server3021 opensips[13276]:  heap size= 4194304
>>> Mar  6 07:29:19 Server3021 opensips[13276]:  used= 346768,
>>> used+overhead=848792, free=3345512
>>> Mar  6 07:29:19 Server3021 opensips[13276]:  max used (+overhead)= 931920
>>> Mar  6 07:29:19 Server3021 opensips[13276]: dumping all alloc'ed.
>>> fragments:
>>> Mar  6 07:29:19 Server3021 opensips[13276]:   0. N
>>>  address=0x7f5b8ebef528 frag=0x7f5b8ebef4f8 size=40 used=1
>>> Mar  6 07:29:19 Server3021 opensips[13276]: alloc'd from
>>> script_cb.c: 

Re: [OpenSIPS-Users] Quest to find memory leak

2017-03-06 Thread Răzvan Crainea
None of the "actions" you are talking about have big impact on private 
memory, but the shared one. Better do the dump and send it over to point 
out what is "eating" memory.


Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 03/06/2017 02:39 PM, John Nash wrote:
with every call attempt it decreases. I tried some changes by 
rejecting invite before drouting call (That means after auth , 
dispatcher) and found memory is stable but when drouting sends Invite 
to external gateway and external gateway rejects it. Then this issue 
happens.


Inuse transactions and active dialogs also 0. Somthing wrong happening 
in handling of failure replies. But apart from use_next_gw and setting 
some avps for CDR not much going on there.


On Mon, Mar 6, 2017 at 5:54 PM, Răzvan Crainea > wrote:


Ok, so it is the first listener for the private IP that leaks.
Next, is the memory stabilizing in time? Or it is continously
decreasing?
Yes, that's how you should make the dump.

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com 

On 03/06/2017 10:57 AM, John Nash wrote:

Dear Razvan,

Below is the info on my processes
Process::  ID=0 PID=17351 Type=attendant
Process::  ID=1 PID=17352 Type=MI FIFO
Process::  ID=2 PID=17353 Type=MI Datagram
Process::  ID=3 PID=17354 Type=time_keeper
Process::  ID=4 PID=17355 Type=timer
Process::  ID=5 PID=17356 Type=SIP receiver udp:1.1.1.1:9094

Process::  ID=6 PID=17357 Type=SIP receiver udp:1.1.1.1:5060

Process::  ID=7 PID=17358 Type=SIP receiver udp:192.168.45.5:5064

Process::  ID=8 PID=17359 Type=Timer handler

1.1.1.1 is public IP (I changed). The decrease in memory I see is
for Process::  ID=7 PID=17358 mainly. My call flow is as following

- New Invite hits the opensips on 1.1.1.1:9094 
- Apart from message validity checks I query DB to check if its a
valid user (Using local cache also there)
- Create dialog, Topology_hiding functions are called along with
some avp population
- Using dispatcher ds_select_domain Call sent to
udp:192.168.45.2:7060  (using force
socket). This 192.168.45.2:7060  is
actually freeswitch
- Call again comes back to opensips on udp:192.168.45.5:5064

- New dialog is created and topology_hiding is called
- Drouting function do_routing is called which tries one gateway
and fails


Dump i need to create with memlog=4 memdump=1 right?









On Mon, Mar 6, 2017 at 2:05 PM, Răzvan Crainea
> wrote:

Hi, John!

Transactions are stored in shared memory, not in the private
one. So the possible leak you are facing its not related to
transactions.
During runtime, OpenSIPS might resize some internal
structures, which may lead to increase memory usage. However,
after a while, these allocations should stabilize.
Can you post the output of the kill -SIGUSR1 on pastebin so
we can take a look? Also, what type of process is the one you
are seeing the leak into? You can find out using the
'opensipsctl ps' command.

Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com 

On 03/06/2017 09:55 AM, John Nash wrote:

I am using OpenSIPS (2.1.5 (x86_64/linux)) in production. I
observed private memory is decreasing constantly for one
process mainly and ultimately leading to memory errors and
crash.

To debug this issue I prepared a test server and compiled
opensips as per
https://www.opensips.org/Documentation/TroubleShooting-OutOfMem


I made only one single call (which was rejected by opensips
as it was not authorized user) and I saw private free memory
decreased. I was hoping since transaction is done ideally it
should release memory and should show me same memory as
startup but it did not. I verified this with many call
attempts and i see free memory is always decreasing slowly.

I used kill -SIGUSR1  to create memory dump. But
i am unable to make sense of it. It shows log like ...

r  6 07:29:19 Server3021 opensips[13276]: Memory status (pkg):
Mar  6 07:29:19 Server3021 opensips[13276]: qm_status
(0x7f5b8ebba010):
Mar  6 07:29:19 Server3021 opensips[13276]:  heap size= 4194304
Mar  6 07:29:19 Server3021 opensips[13276]:  used= 346768,

Re: [OpenSIPS-Users] Quest to find memory leak

2017-03-06 Thread John Nash
with every call attempt it decreases. I tried some changes by rejecting
invite before drouting call (That means after auth , dispatcher) and found
memory is stable but when drouting sends Invite to external gateway and
external gateway rejects it. Then this issue happens.

Inuse transactions and active dialogs also 0. Somthing wrong happening in
handling of failure replies. But apart from use_next_gw and setting some
avps for CDR not much going on there.

On Mon, Mar 6, 2017 at 5:54 PM, Răzvan Crainea  wrote:

> Ok, so it is the first listener for the private IP that leaks. Next, is
> the memory stabilizing in time? Or it is continously decreasing?
> Yes, that's how you should make the dump.
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 03/06/2017 10:57 AM, John Nash wrote:
>
> Dear Razvan,
>
> Below is the info on my processes
> Process::  ID=0 PID=17351 Type=attendant
> Process::  ID=1 PID=17352 Type=MI FIFO
> Process::  ID=2 PID=17353 Type=MI Datagram
> Process::  ID=3 PID=17354 Type=time_keeper
> Process::  ID=4 PID=17355 Type=timer
> Process::  ID=5 PID=17356 Type=SIP receiver udp:1.1.1.1:9094
> Process::  ID=6 PID=17357 Type=SIP receiver udp:1.1.1.1:5060
> Process::  ID=7 PID=17358 Type=SIP receiver udp:192.168.45.5:5064
> Process::  ID=8 PID=17359 Type=Timer handler
>
> 1.1.1.1 is public IP (I changed). The decrease in memory I see is for
> Process::  ID=7 PID=17358 mainly. My call flow is as following
>
> - New Invite hits the opensips on 1.1.1.1:9094
> - Apart from message validity checks I query DB to check if its a valid
> user (Using local cache also there)
> - Create dialog, Topology_hiding functions are called along with some avp
> population
> - Using dispatcher ds_select_domain Call sent to udp:192.168.45.2:7060
> (using force socket). This 192.168.45.2:7060 is actually freeswitch
> - Call again comes back to opensips on udp:192.168.45.5:5064
> - New dialog is created and topology_hiding is called
> - Drouting function do_routing is called which tries one gateway and fails
>
>
> Dump i need to create with memlog=4 memdump=1 right?
>
>
>
>
>
>
>
>
>
> On Mon, Mar 6, 2017 at 2:05 PM, Răzvan Crainea 
> wrote:
>
>> Hi, John!
>>
>> Transactions are stored in shared memory, not in the private one. So the
>> possible leak you are facing its not related to transactions.
>> During runtime, OpenSIPS might resize some internal structures, which may
>> lead to increase memory usage. However, after a while, these allocations
>> should stabilize .
>> Can you post the output of the kill -SIGUSR1 on pastebin so we can take a
>> look? Also, what type of process is the one you are seeing the leak into?
>> You can find out using the 'opensipsctl ps' command.
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Solutionswww.opensips-solutions.com
>>
>> On 03/06/2017 09:55 AM, John Nash wrote:
>>
>> I am using OpenSIPS (2.1.5 (x86_64/linux)) in production. I observed
>> private memory is decreasing constantly for one process mainly and
>> ultimately leading to memory errors and crash.
>>
>> To debug this issue I prepared a test server and compiled opensips as per
>> https://www.opensips.org/Documentation/TroubleShooting-OutOfMem
>>
>> I made only one single call (which was rejected by opensips as it was not
>> authorized user) and I saw private free memory decreased. I was hoping
>> since transaction is done ideally it should release memory and should show
>> me same memory as startup but it did not. I verified this with many call
>> attempts and i see free memory is always decreasing slowly.
>>
>> I used kill -SIGUSR1  to create memory dump. But i am unable
>> to make sense of it. It shows log like ...
>>
>> r  6 07:29:19 Server3021 opensips[13276]: Memory status (pkg):
>> Mar  6 07:29:19 Server3021 opensips[13276]: qm_status (0x7f5b8ebba010):
>> Mar  6 07:29:19 Server3021 opensips[13276]:  heap size= 4194304
>> Mar  6 07:29:19 Server3021 opensips[13276]:  used= 346768,
>> used+overhead=848792, free=3345512
>> Mar  6 07:29:19 Server3021 opensips[13276]:  max used (+overhead)= 931920
>> Mar  6 07:29:19 Server3021 opensips[13276]: dumping all alloc'ed.
>> fragments:
>> Mar  6 07:29:19 Server3021 opensips[13276]:   0. N
>>  address=0x7f5b8ebef528 frag=0x7f5b8ebef4f8 size=40 used=1
>> Mar  6 07:29:19 Server3021 opensips[13276]: alloc'd from
>> script_cb.c: add_callback(60)
>> Mar  6 07:29:19 Server3021 opensips[13276]: start
>> check=f0f0f0f0f0f0f0f0, end check= c0c0c0c0c0c0c0c0, abcdefedabcdefed
>> Mar  6 07:29:19 Server3021 opensips[13276]:   1. N
>>  address=0x7f5b8ebef5b0
>>
>> I pasted only few lines in this mail. What should be my next step?...How
>> can i really trace what is wrong in my script or any other memory leak?
>>
>>
>>
>> ___
>> Users mailing 
>> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>> 

Re: [OpenSIPS-Users] crashing in 2.2.2

2017-03-06 Thread Richard Robson

Hi<

I've tested this on the latest 2.2.3 with the same results.

http://pastebin.com/Uixb3v8G

there were a few of these in the logsd too just before the crash:
Mar  5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: 
WARNING:core:utimer_ticker: utimer task  already scheduled 
for 204079170 ms (now 204079270 ms), it may overlap..
Mar  5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: 
WARNING:core:utimer_ticker: utimer task  already scheduled 
for 204079170 ms (now 204079360 ms), it may overlap..
Mar  5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: 
WARNING:core:utimer_ticker: utimer task  already scheduled 
for 204079170 ms (now 204079460 ms), it may overlap..
Mar  5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: 
WARNING:core:utimer_ticker: utimer task  already scheduled 
for 204079170 ms (now 204079560 ms), it may overlap..
Mar  5 22:02:27 gl-sip-03 /usr/sbin/opensips[29875]: 
WARNING:core:utimer_ticker: utimer task  already scheduled 
for 204079170 ms (now 204079660 ms), it may overlap..
Mar  5 22:02:28 gl-sip-03 /usr/sbin/opensips[29875]: 
WARNING:core:utimer_ticker: utimer task  already scheduled 
for 204079170 ms (now 204079760 ms), it may overlap..



Regards,

Richard



On 03/03/2017 13:15, Richard Robson wrote:

More cores

http://pastebin.com/MXW2VBhi
http://pastebin.com/T7JFAP2U
http://pastebin.com/u44aaVpWquit
http://pastebin.com/SFKKcGxE
http://pastebin.com/dwSgMsJi
http://pastebin.com/9HdGLm96

I've put 2.2.3 on the dev box now and will try to replicate on that 
box, but its difficult to replicate the traffic artificially. I'll try 
to replicate the fault on the dev box over the weekend. I cant do it 
on the live gateways because it will affect customer traffic.


Regards,

Richard


On 03/03/2017 11:28, Richard Robson wrote:
I've revisited the gateway failover mechanism I had developed in 
order to re route calls to the next gateway on 500's due to capacity 
on the gateways we are using.


we have 3 gateways from one carrier and one from another. The 3 have 
4 cps and will return a 503 or 500 if we breach this. The single 
gateway from the other carrier has plenty of capacity and should not 
be a problem so we want to catch this . and route to the next gateway.


We are counting the CPS and channel limits and are routing to the 
next gateway if we exceed the limit set, but There are still 
occasions where a 5XX is generated, which results in a rejected call.



We want to stop these rejected calls and therefore want to implement 
the failover mechanism for the 5XX responses. For 6 months we have 
been failing over if we think the counts are to high on any one 
gateway without a problem. But when I implement a failover on a 5XX 
response opensips starts crashing.


It's difficult to generate artificial traffic to mimic the real 
traffic, but I've not had a problem with the script in testing. Last 
night I rolled out the new script but by 09:15 this morning opensips 
started crashing 10 times in 5 minutes. This was as the traffic 
ramped up. I rolled back the script and it restarted OK and has not 
crashed since. Therefore the Failover Mechanism in the script is 
where the crash is happening


Core dump: http://pastebin.com/CqnESCm4

I'll add more dumps later

Regards,

Richard


this is the failure route catching the 5XX

failure_route[dr_fo] {
xlog (" [dr]  Recieved reply to method $rm From: $fd, $fn, 
$ft, $fu, $fU, $si, $sp, To: $ru");

if (t_was_cancelled()) {
xlog("[dr]call cancelled by internal caller");
rtpengine_manage();
do_accounting("db", "cdr|missed");
exit;
}

if ( t_check_status("[54]03")) {
route(relay_failover);
}
if ( t_check_status("500")) {
route(relay_failover);
}

do_accounting("db", "cdr|missed");
rtpengine_manage();
exit;
}

This is the route taken on the failure


route[relay_failover]{

if (use_next_gw()) {
xlog("[relay_failover-route] Selected Gateway is $rd");
$avp(trunkratelimit)=$(avp(attrs){s.select,0,:});
$avp(trunkchannellimit)=$(avp(attrs){s.select,1,:});

### check channel limit ##
get_profile_size("outbound","$rd","$var(size)");
xlog("[relay_failover-route] Selected Gateway is $rd 
var(size) = $var(size)");
xlog("[relay_failover-route] Selected Gateway is $rd 
avp(trunkcalllimit) = $avp(trunkchannellimit)");
xlog("[relay_failover-route] Selected Gateway is $rd  
result = ( $var(size) > $avp(trunkchannellimit))");
if ( $(var(size){s.int}) > 
$(avp(trunkchannellimit){s.int})) {
xlog("[relay_failover-route] Trunk $rd 
exceeded $avp(trunkchannellimit) concurrent calls $var(size)");

route(relay_failover);
}
} else {
   send_reply("503", "Gateways Exhusted");
   exit;

Re: [OpenSIPS-Users] Question regarding rtpengine and websocket connection in opensips-2.2.2

2017-03-06 Thread Sasmita Panda
Example :

 A (pjsip client )---> Opensips -> B (sipml5)

1. A calls B : working fine .
2. B hold the call : working fine
3. B Resume the call : working fine
4. A hold the call : Not working . While forwarding the call to browser ,
Opensips is not able to do proper conversion .

What should I change in the config . I have given my config file in the
above mail . Please help me . I am stuck in a critical stage .




*Thanks & Regards*
*Sasmita Panda*
*Network Testing and Software Engineer*
*3CLogic , ph:07827611765*

On Mon, Mar 6, 2017 at 4:16 PM, Sasmita Panda  wrote:

> Hi All ,
>
>
>  I am useing opensips-2.2.2 with rtpengine and proto_ws module .
>
>  I have followd the bellow doc for doing the configuration .
>
> *** http://www.opensips.org/Documentation/Tutorials-WebSocket-2-2
>
>  This is working fine in general scenario . But when I am holding the
> call from my client side to browser , The script is not able to convert the
> RTP format .
>
> In case of loose route it should convert the RTP as it converted in
> the initial INVITE , but it is always going through the last option in the
> route block . And browser wont support this . My call get disconnected .
> What should I do for this .
>
> else if (!isflagset(SRC_WS) && !isbflagset(DST_WS))
>
> $var(rtpengine_flags) = "RTP/AVP replace-session-connection 
> replace-origin ICE=remove";
>
>
> * Bellow is my config file . Please help me .*
>
> *Thanks & Regards*
> *Sasmita Panda*
> *Network Testing and Software Engineer*
> *3CLogic , ph:07827611765*
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


[OpenSIPS-Users] Question regarding rtpengine and websocket connection in opensips-2.2.2

2017-03-06 Thread Sasmita Panda
Hi All ,


 I am useing opensips-2.2.2 with rtpengine and proto_ws module .

 I have followd the bellow doc for doing the configuration .

*** http://www.opensips.org/Documentation/Tutorials-WebSocket-2-2

 This is working fine in general scenario . But when I am holding the
call from my client side to browser , The script is not able to convert the
RTP format .

In case of loose route it should convert the RTP as it converted in the
initial INVITE , but it is always going through the last option in the
route block . And browser wont support this . My call get disconnected .
What should I do for this .

else if (!isflagset(SRC_WS) && !isbflagset(DST_WS))

$var(rtpengine_flags) = "RTP/AVP replace-session-connection
replace-origin ICE=remove";


* Bellow is my config file . Please help me .*

*Thanks & Regards*
*Sasmita Panda*
*Network Testing and Software Engineer*
*3CLogic , ph:07827611765*


sasmita.cfg
Description: Binary data
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Quest to find memory leak

2017-03-06 Thread John Nash
Dear Razvan,

Below is the info on my processes
Process::  ID=0 PID=17351 Type=attendant
Process::  ID=1 PID=17352 Type=MI FIFO
Process::  ID=2 PID=17353 Type=MI Datagram
Process::  ID=3 PID=17354 Type=time_keeper
Process::  ID=4 PID=17355 Type=timer
Process::  ID=5 PID=17356 Type=SIP receiver udp:1.1.1.1:9094
Process::  ID=6 PID=17357 Type=SIP receiver udp:1.1.1.1:5060
Process::  ID=7 PID=17358 Type=SIP receiver udp:192.168.45.5:5064
Process::  ID=8 PID=17359 Type=Timer handler

1.1.1.1 is public IP (I changed). The decrease in memory I see is for
Process::  ID=7 PID=17358 mainly. My call flow is as following

- New Invite hits the opensips on 1.1.1.1:9094
- Apart from message validity checks I query DB to check if its a valid
user (Using local cache also there)
- Create dialog, Topology_hiding functions are called along with some avp
population
- Using dispatcher ds_select_domain Call sent to udp:192.168.45.2:7060
(using force socket). This 192.168.45.2:7060 is actually freeswitch
- Call again comes back to opensips on udp:192.168.45.5:5064
- New dialog is created and topology_hiding is called
- Drouting function do_routing is called which tries one gateway and fails


Dump i need to create with memlog=4 memdump=1 right?









On Mon, Mar 6, 2017 at 2:05 PM, Răzvan Crainea  wrote:

> Hi, John!
>
> Transactions are stored in shared memory, not in the private one. So the
> possible leak you are facing its not related to transactions.
> During runtime, OpenSIPS might resize some internal structures, which may
> lead to increase memory usage. However, after a while, these allocations
> should stabilize .
> Can you post the output of the kill -SIGUSR1 on pastebin so we can take a
> look? Also, what type of process is the one you are seeing the leak into?
> You can find out using the 'opensipsctl ps' command.
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 03/06/2017 09:55 AM, John Nash wrote:
>
> I am using OpenSIPS (2.1.5 (x86_64/linux)) in production. I observed
> private memory is decreasing constantly for one process mainly and
> ultimately leading to memory errors and crash.
>
> To debug this issue I prepared a test server and compiled opensips as per
> https://www.opensips.org/Documentation/TroubleShooting-OutOfMem
>
> I made only one single call (which was rejected by opensips as it was not
> authorized user) and I saw private free memory decreased. I was hoping
> since transaction is done ideally it should release memory and should show
> me same memory as startup but it did not. I verified this with many call
> attempts and i see free memory is always decreasing slowly.
>
> I used kill -SIGUSR1  to create memory dump. But i am unable
> to make sense of it. It shows log like ...
>
> r  6 07:29:19 Server3021 opensips[13276]: Memory status (pkg):
> Mar  6 07:29:19 Server3021 opensips[13276]: qm_status (0x7f5b8ebba010):
> Mar  6 07:29:19 Server3021 opensips[13276]:  heap size= 4194304
> Mar  6 07:29:19 Server3021 opensips[13276]:  used= 346768,
> used+overhead=848792, free=3345512
> Mar  6 07:29:19 Server3021 opensips[13276]:  max used (+overhead)= 931920
> Mar  6 07:29:19 Server3021 opensips[13276]: dumping all alloc'ed.
> fragments:
> Mar  6 07:29:19 Server3021 opensips[13276]:   0. N
>  address=0x7f5b8ebef528 frag=0x7f5b8ebef4f8 size=40 used=1
> Mar  6 07:29:19 Server3021 opensips[13276]: alloc'd from
> script_cb.c: add_callback(60)
> Mar  6 07:29:19 Server3021 opensips[13276]: start
> check=f0f0f0f0f0f0f0f0, end check= c0c0c0c0c0c0c0c0, abcdefedabcdefed
> Mar  6 07:29:19 Server3021 opensips[13276]:   1. N
>  address=0x7f5b8ebef5b0
>
> I pasted only few lines in this mail. What should be my next step?...How
> can i really trace what is wrong in my script or any other memory leak?
>
>
>
> ___
> Users mailing 
> listUsers@lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


Re: [OpenSIPS-Users] Quest to find memory leak

2017-03-06 Thread Răzvan Crainea

Hi, John!

Transactions are stored in shared memory, not in the private one. So the 
possible leak you are facing its not related to transactions.
During runtime, OpenSIPS might resize some internal structures, which 
may lead to increase memory usage. However, after a while, these 
allocations should stabilize.
Can you post the output of the kill -SIGUSR1 on pastebin so we can take 
a look? Also, what type of process is the one you are seeing the leak 
into? You can find out using the 'opensipsctl ps' command.


Best regards,

Răzvan Crainea
OpenSIPS Solutions
www.opensips-solutions.com

On 03/06/2017 09:55 AM, John Nash wrote:
I am using OpenSIPS (2.1.5 (x86_64/linux)) in production. I observed 
private memory is decreasing constantly for one process mainly and 
ultimately leading to memory errors and crash.


To debug this issue I prepared a test server and compiled opensips as 
per https://www.opensips.org/Documentation/TroubleShooting-OutOfMem


I made only one single call (which was rejected by opensips as it was 
not authorized user) and I saw private free memory decreased. I was 
hoping since transaction is done ideally it should release memory and 
should show me same memory as startup but it did not. I verified this 
with many call attempts and i see free memory is always decreasing slowly.


I used kill -SIGUSR1  to create memory dump. But i am 
unable to make sense of it. It shows log like ...


r  6 07:29:19 Server3021 opensips[13276]: Memory status (pkg):
Mar  6 07:29:19 Server3021 opensips[13276]: qm_status (0x7f5b8ebba010):
Mar  6 07:29:19 Server3021 opensips[13276]:  heap size= 4194304
Mar  6 07:29:19 Server3021 opensips[13276]:  used= 346768, 
used+overhead=848792, free=3345512

Mar  6 07:29:19 Server3021 opensips[13276]:  max used (+overhead)= 931920
Mar  6 07:29:19 Server3021 opensips[13276]: dumping all alloc'ed. 
fragments:
Mar  6 07:29:19 Server3021 opensips[13276]:   0. N 
 address=0x7f5b8ebef528 frag=0x7f5b8ebef4f8 size=40 used=1
Mar  6 07:29:19 Server3021 opensips[13276]: alloc'd from script_cb.c: 
add_callback(60)
Mar  6 07:29:19 Server3021 opensips[13276]: start 
check=f0f0f0f0f0f0f0f0, end check= c0c0c0c0c0c0c0c0, abcdefedabcdefed
Mar  6 07:29:19 Server3021 opensips[13276]:   1. N 
 address=0x7f5b8ebef5b0


I pasted only few lines in this mail. What should be my next 
step?...How can i really trace what is wrong in my script or any other 
memory leak?




___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users


[OpenSIPS-Users] t_uac_dlg command through mi_datagram socket gives 400 bad headers

2017-03-06 Thread Husnain Taseer
Hi Folks!

I am trying to generate a MESSAGE packet using t_uac_dlg command from a
management script written in Python. I have tried different combination of
argument string but either getting parsing error or 400 bad headers error.
The string which I am sending to mi_datagram socket in my Python script is:

*message = ''':t_uac_dlg:\nMESSAGE\nsip:212897645@192.168.1.20
\n.\n.\n"From: >\\r\\nTo: >\\r\\np-identifier:
Local_Socket_V1.0\\r\\nContent-Type: text/plain\\r\\n"\n"Hi This is a Test
Message"\n'''*

When I print the above string it gives me the value given below:

:t_uac_dlg:
MESSAGE
sip:212897645@192.168.1.20
.
.
"From: \r\nTo:
\r\np-identifier:
Local_Socket_V1.0\r\nContent-Type: text/plain\r\n"
"Hi This is a test"

When I send this string to mi_datagram socket it gives me *400 Bad
headers *Please
guide where I am doing wrong.


Regards,
*Husnain Taseer*
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users