[OpenSIPS-Users] onreply_route question

[John Nash]

I am using t_on_failure("external_failure"); t_on_reply("external_reply");
before calling do_routing function. I expected failure replies to go
to failure_route[external_failure]  only but failure replies also going
to onreply_route[external_reply] along with failure_route[external_failure]

Is there something wrong I am doing?
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Mediaproxy hanging sessions on high load

[Daniel Zanutti]

Any idea guys?

On Tue, Mar 7, 2017 at 11:10 AM, Daniel Zanutti 
wrote:

> I'm using mediaproxy on several installations and have noticed that when
> the machine is on high load (> 700 sessions), the media-relay process
> starts to hang some sessions.
>
> These sessions doesn't have any RTP being sent/received anymore and they
> never hangup. After some hours of frozen sessions, the media-relay process
> doesn't connect to the dispatcher anymore, but keep using high CPU on the
> machine. Maybe it's on loop internally, not sure.
>
> Is there any solution for this? Maybe a timer to cleanup old sessions (2
> or 4+ hours old).
>
> Thanks
>
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] CDRtool vs CGRATES for Opensips 2.2 +

[Jeff Wilkie]

DanB,

Thanks for the very useful information!

I'm reading that the preferred install OS for CGRATES is Debian.  Most of
our development happens on CENTOS 6.x.  Are there packages yet for CENT?
Or would we be required to install from source if we keep that OS?

Thanks

Jeff Wilkie


On Sun, Mar 5, 2017 at 6:32 AM, DanB  wrote:

> Hi Jeff,
>
> Although it is a slippery ground, in order to have the question answered,
> I can claim having experience with both systems (we used to install CDRTool
> for customers and still have today installs running since like 8 years
> without issues).
>
> CDRTool (CDR rating system):
>
> * Written in php, works closely with db (eg: relies on it's query
> speed with some caching for parts of the rates)
>
> * Mature implementation, not much development changing the code over
> the years (other than bug fixes).
>
> * Simple rating definition and implementation.
>
> * Web interface for rates management as well as CDRs.
>
> * Designed around rating CDRs and maintaining account balance.
>
>
> CGRateS (OCS - online charging system):
>
> * Written in Go, caches almost all information in process, database
> agnostic (abstracts databases into interfaces), database speed does not
> influence the speed of calculations, built on micro-services with full
> asynchronous processing.
>
> * Still in Release Candidate when it comes to architecture, evolved a
> lot over the years, master should be always stable in terms of
> functionality since it runs in production environments (architecture part
> is not yet declared stable - you can expect it to still evolve).
>
> * Complex rating (rates voice calls, data streams, sms, etc) and
> accounting (unlimited number of balances/bundles and failover between them
> during a call).
>
> * API (JSON) driven management (full set) with no official web
> interface available yet.
>
> * Additional functionality: fraud detection with automatic mitigation
> (3 layers: accounts, CDR stats, resources usage), CDR logging with support
> for interim records, QoS LCR and LCR over bundels, real-time (complete in
> memory) call statistics with pattern monitoring and triggers/web hooks
> towards external systems, derive charging (session emulation -
> reseller/distributor scenarios, customer/supplier parallel calculations),
> performance optimized (one CGRateS instance should be able to handle 5k
> requests per second in terms of rating calculations), built-in high
> availability for Diameter setups.
>
>
> So these being said, it is all about the need vs price (time investment)
> you are ready to pay for it by using one system or another (considering
> both systems are opensource and you can extend yourself in one way or
> another). If you don't have complex rating requirements nor the need of
> increased CPS, I trust CDRTool will do the job just fine since it did it
> for us over the years (you get the advantage as said of simple management
> and architecture stability, quick learning curve). CGRateS on the other
> hand should be there if you decide you need more functionality/speed and
> you are also ready to offer it more time and efforts.
>
>
> I hope this helps someone!
>
> DanB
>
>
> ___
> 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] crashing in 2.2.2

[Bogdan-Andrei Iancu]

Hi Richard,

Sorry for the slow reply - is this crash happing only under some ++load 
? do you see any errors from OpenSIPS prior to the crash ?


I noticed that the backtraces in the corefiles are similar - how easy is 
for you to reproduce it ?


Regards,

Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com

OpenSIPS Summit May 2017 Amsterdam
  http://www.opensips.org/events/Summit-2017Amsterdam.html

On 03/07/2017 12:28 PM, Richard Robson wrote:

Hi,

I've gone over the script and as far as I can see its working as 
expected until the traffic remps up and then opensips crashes.


cores:
http://pastebin.com/CgN0h40K
http://pastebin.com/ay5TS8zD
http://pastebin.com/PGn3AqmU

Regards,

Richard

On 06/03/2017 12:14, Richard Robson wrote:

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 

Re: [OpenSIPS-Users] SIP password auth mechanism

[Bogdan-Andrei Iancu]

Hi Abdul,

Besides the digest auth, there is no other standard auth mechanism for 
SIP, AFAIK.


If you have control over the SIP UAC, of course, you could try to build 
your own auth mechanism - OpenSIPS offers enough flexibility in terms of 
both header manipulation and data computing.


Regards,

Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com

OpenSIPS Summit May 2017 Amsterdam
  http://www.opensips.org/events/Summit-2017Amsterdam.html

On 03/07/2017 10:26 AM, Abdul Basit wrote:

Hi,

I have a scenario where I will create password HASH = SALT + STRING 
and save SALT and resulted HASH only in DB.


I will transport random STRING value to my custom sip application as 
password.


Digest authentication is not comply with this requirement.

Is that any supported authentication mechanism that can fulfill this 
requirement.
or is there any more appropriate authentication mechanism by 
opensips/kamailio?


One of the objectives is in case DB will compromise, users passwords 
will not available because random STRING will not store in DB.


Looking forward for suggestions and comments.

--
regards,

abdul basit


___
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] Opensips Routing Module Latency

[Bogdan-Andrei Iancu]

Hi Khaled,

What version of OpenSIPS do you have ?

Regards,

Bogdan-Andrei Iancu
  OpenSIPS Founder and Developer
  http://www.opensips-solutions.com

OpenSIPS Summit May 2017 Amsterdam
  http://www.opensips.org/events/Summit-2017Amsterdam.html

On 03/07/2017 01:51 PM, Eng. Khaled Chehab wrote:

Dears

I have between 5 and 8 dr rules , reloading these dr_rules to apply  
changes  takes between 5 to 8 minutes I am using Mysql DB 1-how can  make that 
faster and if I should change the DB engine what do you recommend 2-while 
reloading what will be the status of the incoming calls , will be dropped or 
get a response 404 not found ?


Regards




___
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] MongoDB driver enhance in OpenSIPS 2.3!

[Liviu Chircu]

Hi all,

It is my pleasure to announce that a MongoDB module enhancement will 
make it into the OpenSIPS 2.3 beta! It will include the following:


* support for MongoDB 3.0+ servers
* full support for database commands
* compatibility with libmongoc versions 1.0.0 - 1.6.0

You may learn more about the new module from this OpenSIPS Blog post [1]

Best regards,

[1]: 
https://blog.opensips.org/2017/03/07/how-to-use-the-enhanced-mongodb-module-in-opensips-2-3/


--
Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

OpenSIPS Summit May 2017 Amsterdam
  http://www.opensips.org/events/Summit-2017Amsterdam.html


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

Re: [OpenSIPS-Users] Compiler flags disabled

[John Nash]

please ignore i had selected wrong option to clean.

On Tue, Mar 7, 2017 at 9:09 PM, John Nash  wrote:

> I was trying to compile on fresh linux cent OS. But when i run make
> menuconfig i find that I am not able to see "Configure Compile Flags "
> seems disabled. Other options I can go inside like exclude modules etc
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Compiler flags disabled

[John Nash]

I was trying to compile on fresh linux cent OS. But when i run make
menuconfig i find that I am not able to see "Configure Compile Flags "
seems disabled. Other options I can go inside like exclude modules etc
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

[OpenSIPS-Users] Mediaproxy hanging sessions on high load

[Daniel Zanutti]

I'm using mediaproxy on several installations and have noticed that when
the machine is on high load (> 700 sessions), the media-relay process
starts to hang some sessions.

These sessions doesn't have any RTP being sent/received anymore and they
never hangup. After some hours of frozen sessions, the media-relay process
doesn't connect to the dispatcher anymore, but keep using high CPU on the
machine. Maybe it's on loop internally, not sure.

Is there any solution for this? Maybe a timer to cleanup old sessions (2 or
4+ hours old).

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

Re: [OpenSIPS-Users] rest_client behavior change in module version 2.2.3?

[Liviu Chircu]

Hi Andreas,

Although we saw it as a bugfix (404 response is not a transfer error!), 
I will add a mention regarding this patch in the migration page. Maybe 
it will help avoid more issues similar to yours remaining undetected 
after upgrading to 2.2.3.


Best regards,

Liviu Chircu
OpenSIPS Developer
http://www.opensips-solutions.com

OpenSIPS Summit May 2017 Amsterdam
  http://www.opensips.org/events/Summit-2017Amsterdam.html

On 07.03.2017 14:51, Andreas Sikkema wrote:

Hi,

I did make the code a little more robust by not only checking if the 
rest_get() call succeeded, but also checking if $var(rcode) equalled 
"200" before doing the magic. This solved my problem.





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

Re: [OpenSIPS-Users] rest_client behavior change in module version 2.2.3?

[Andreas Sikkema]

Hi,

I did make the code a little more robust by not only checking if the 
rest_get() call succeeded, but also checking if $var(rcode) equalled 
"200" before doing the magic. This solved my problem.


--
Andreas Sikkema

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

[OpenSIPS-Users] Accounting B2BUA market scenario

[Andreas Bøckmann]

Hello,

I am trying to generate acc records for the marketing scenario example
(B2BUA) and execute it as such:

opensipsctl fifo b2b_trigger_scenario marketing sip:+12345@external.domain1
sip:+23456@external.domain2 sip:+23456@external.domain1

The only records I get in the database on the OpenSIPS-B2BUA is "BYE"
records; without an initial INVITE so there is no duration etc.

How do you properly handle accounting for the B2B-module; and in my
specific case how do I generate records on UAC generated INVITE in OpenSIPS?

route[b2b_request] {
   do_accounting("db");
   #do_accounting("db|log", "cdr|missed", "acc");
}

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

[OpenSIPS-Users] Opensips Routing Module Latency

[Eng. Khaled Chehab]

Dears

I have between 5 and 8 dr rules , reloading these dr_rules to apply  
changes  takes between 5 to 8 minutes I am using Mysql DB 1-how can  make that 
faster and if I should change the DB engine what do you recommend 2-while 
reloading what will be the status of the incoming calls , will be dropped or 
get a response 404 not found ?


Regards




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

[OpenSIPS-Users] rest_client behavior change in module version 2.2.3?

[Andreas Sikkema]

Hi,

I am using the rest_client to retrieve some information about an 
incoming call using the following:


if 
(!rest_get("http://127.0.0.1:/dir/search?number_a=$fU_b=$rU;, 
"$var(name)", "$var(ct)", "$var(rcode)")) {

xlog("Error code $var(rcode) in HTTP GET!\n");
}
else {
xlog("Received $var(name) using REST for A number $fU and B number 
$rU\n");
# magic
}

In rest_client module versions 2.2.2 (?) and before this worked like a 
charm. When the web server returned a 404 or another error, the script 
would log the error and go on. When rest_get() received a 200 OK, magic 
would happen.


Since we upgraded to rest_client module version 2.2.3 this morning this 
behavior changed. When the server returns a 404, rest_get doesn't error 
out, but goes on as before, and my script now tries to do magic on a 404 
message's HTML body. Which is not what I want...


Did I use the rest_get() return values incorrectly, or is it a bug?

--
Andreas Sikkema

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

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

[John Nash]

version: opensips 2.1.5 (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC,
DBG_QM_MALLOC, FAST_LOCK-ADAPTIVE_WAIT
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
MAX_URI_SIZE 1024, BUF_SIZE 65535
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
git revision: 39b19dd
main.c compiled on 19:27:59 Mar  5 2017 with gcc 4.4.7


On Tue, Mar 7, 2017 at 4:25 PM, Răzvan Crainea  wrote:

> What allocator are you using? Can you post the output of 'opensips -V'?
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 03/07/2017 12:23 PM, John Nash wrote:
>
> Please note when i call do_routing in such a way that its unable to find
> any rules matching and reject call i do not see free memory drop. But if it
> finds a route, sends call to that gateway memory drops with each attempt.
>
> On Tue, Mar 7, 2017 at 3:17 PM, John Nash  wrote:
>
>> only 6 or 7 calls
>>
>> On Tue, Mar 7, 2017 at 3:09 PM, Răzvan Crainea 
>> wrote:
>>
>>> So I understand that after ~3K calls, that process completely runs out
>>> of memory?
>>> How many calls have you done before this trace:
>>> http://pastebin.com/9Ge2NEVQ
>>>
>>> Best regards,
>>>
>>> Răzvan Crainea
>>> OpenSIPS Solutionswww.opensips-solutions.com
>>>
>>> On 03/07/2017 11:32 AM, John Nash wrote:
>>>
>>> when I check stats after a call attempt pkmem:7-free_size:: 3304280
>>>
>>> In this entry with every call I see a drop of 1000 bytes around and this
>>> never restores.
>>>
>>> On Tue, Mar 7, 2017 at 2:16 PM, Răzvan Crainea 
>>> wrote:
>>>
 Hi, John!

 Again, this trace doesn't show any leak.
 Are you sure you are having a private memory leak and not a shared
 memory leak?

 Best regards,

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

 On 03/06/2017 08:09 PM, John Nash wrote:

 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


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


>>>
>>>
>>> ___
>>> 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
>>
>> ___

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

[Răzvan Crainea]

What allocator are you using? Can you post the output of 'opensips -V'?

Best regards,

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

On 03/07/2017 12:23 PM, John Nash wrote:
Please note when i call do_routing in such a way that its unable to 
find any rules matching and reject call i do not see free memory drop. 
But if it finds a route, sends call to that gateway memory drops with 
each attempt.


On Tue, Mar 7, 2017 at 3:17 PM, John Nash > wrote:


only 6 or 7 calls

On Tue, Mar 7, 2017 at 3:09 PM, Răzvan Crainea
> wrote:

So I understand that after ~3K calls, that process completely
runs out of memory?
How many calls have you done before this trace:
http://pastebin.com/9Ge2NEVQ

Best regards,

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

On 03/07/2017 11:32 AM, John Nash wrote:

when I check stats after a call attempt pkmem:7-free_size::
3304280

In this entry with every call I see a drop of 1000 bytes
around and this never restores.

On Tue, Mar 7, 2017 at 2:16 PM, Răzvan Crainea
> wrote:

Hi, John!

Again, this trace doesn't show any leak.
Are you sure you are having a private memory leak and not
a shared
memory leak?

Best regards,

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


On 03/06/2017 08:09 PM, John Nash wrote:

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 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 

Re: [OpenSIPS-Users] crashing in 2.2.2

[Richard Robson]

Hi,

I've gone over the script and as far as I can see its working as 
expected until the traffic remps up and then opensips crashes.


cores:
http://pastebin.com/CgN0h40K
http://pastebin.com/ay5TS8zD
http://pastebin.com/PGn3AqmU

Regards,

Richard

On 06/03/2017 12:14, Richard Robson wrote:

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})) {
 

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

[John Nash]

Please note when i call do_routing in such a way that its unable to find
any rules matching and reject call i do not see free memory drop. But if it
finds a route, sends call to that gateway memory drops with each attempt.

On Tue, Mar 7, 2017 at 3:17 PM, John Nash  wrote:

> only 6 or 7 calls
>
> On Tue, Mar 7, 2017 at 3:09 PM, Răzvan Crainea 
> wrote:
>
>> So I understand that after ~3K calls, that process completely runs out of
>> memory?
>> How many calls have you done before this trace:
>> http://pastebin.com/9Ge2NEVQ
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Solutionswww.opensips-solutions.com
>>
>> On 03/07/2017 11:32 AM, John Nash wrote:
>>
>> when I check stats after a call attempt pkmem:7-free_size:: 3304280
>>
>> In this entry with every call I see a drop of 1000 bytes around and this
>> never restores.
>>
>> On Tue, Mar 7, 2017 at 2:16 PM, Răzvan Crainea 
>> wrote:
>>
>>> Hi, John!
>>>
>>> Again, this trace doesn't show any leak.
>>> Are you sure you are having a private memory leak and not a shared
>>> memory leak?
>>>
>>> Best regards,
>>>
>>> Răzvan Crainea
>>> OpenSIPS Solutionswww.opensips-solutions.com
>>>
>>> On 03/06/2017 08:09 PM, John Nash wrote:
>>>
>>> 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
>>>
>>>
>>> ___
>>> Users mailing list
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>>
>>
>>
>> ___
>> 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

[John Nash]

only 6 or 7 calls

On Tue, Mar 7, 2017 at 3:09 PM, Răzvan Crainea  wrote:

> So I understand that after ~3K calls, that process completely runs out of
> memory?
> How many calls have you done before this trace:
> http://pastebin.com/9Ge2NEVQ
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 03/07/2017 11:32 AM, John Nash wrote:
>
> when I check stats after a call attempt pkmem:7-free_size:: 3304280
>
> In this entry with every call I see a drop of 1000 bytes around and this
> never restores.
>
> On Tue, Mar 7, 2017 at 2:16 PM, Răzvan Crainea 
> wrote:
>
>> Hi, John!
>>
>> Again, this trace doesn't show any leak.
>> Are you sure you are having a private memory leak and not a shared
>> memory leak?
>>
>> Best regards,
>>
>> Răzvan Crainea
>> OpenSIPS Solutionswww.opensips-solutions.com
>>
>> On 03/06/2017 08:09 PM, John Nash wrote:
>>
>> 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
>>
>>
>> ___
>> Users mailing list
>> Users@lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>>
>
>
> ___
> 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

[Răzvan Crainea]

So I understand that after ~3K calls, that process completely runs out 
of memory?

How many calls have you done before this trace: http://pastebin.com/9Ge2NEVQ

Best regards,

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

On 03/07/2017 11:32 AM, John Nash wrote:

when I check stats after a call attempt pkmem:7-free_size:: 3304280

In this entry with every call I see a drop of 1000 bytes around and 
this never restores.


On Tue, Mar 7, 2017 at 2:16 PM, Răzvan Crainea > wrote:


Hi, John!

Again, this trace doesn't show any leak.
Are you sure you are having a private memory leak and not a shared
memory leak?

Best regards,

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

On 03/06/2017 08:09 PM, John Nash wrote:

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 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




___
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


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

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

[John Nash]

when I check stats after a call attempt pkmem:7-free_size:: 3304280

In this entry with every call I see a drop of 1000 bytes around and this
never restores.

On Tue, Mar 7, 2017 at 2:16 PM, Răzvan Crainea  wrote:

> Hi, John!
>
> Again, this trace doesn't show any leak.
> Are you sure you are having a private memory leak and not a shared
> memory leak?
>
> Best regards,
>
> Răzvan Crainea
> OpenSIPS Solutionswww.opensips-solutions.com
>
> On 03/06/2017 08:09 PM, John Nash wrote:
>
> 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
>
>
> ___
> 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] Minimum SIP Headers

[Annus Fictus]

Thank you for your response.

I was just curious to know if there was a particular reason behind this 
behavior


Regards

El 06/03/2017 a las 18:01, Alex Balashov escribió:

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.




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

Re: [OpenSIPS-Users] Minimum SIP Headers

[Annus Fictus]

Thank you,

I don't knew this function

Regards


El 07/03/2017 a las 03:45, Răzvan Crainea escribió:
If you really want to enforce SIP message validation, you can use the 
sipmsg_validate() function[1].


[1] 
http://www.opensips.org/html/docs/modules/2.3.x/sipmsgops.html#id294262


Best regards,

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

On 03/07/2017 01:01 AM, Alex Balashov wrote:

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.




___
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

[Răzvan Crainea]

Hi, John!

Again, this trace doesn't show any leak.
Are you sure you are having a private memory leak and not a shared
memory leak?

Best regards,

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

On 03/06/2017 08:09 PM, John Nash wrote:

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 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


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

Re: [OpenSIPS-Users] Minimum SIP Headers

[Răzvan Crainea]

If you really want to enforce SIP message validation, you can use the 
sipmsg_validate() function[1].


[1] http://www.opensips.org/html/docs/modules/2.3.x/sipmsgops.html#id294262

Best regards,

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

On 03/07/2017 01:01 AM, Alex Balashov wrote:

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.




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

[OpenSIPS-Users] SIP password auth mechanism

[Abdul Basit]

Hi,

I have a scenario where I will create password HASH = SALT + STRING and
save SALT and resulted HASH only in DB.

I will transport random STRING value to my custom sip application as
password.

Digest authentication is not comply with this requirement.

Is that any supported authentication mechanism that can fulfill this
requirement.
or is there any more appropriate authentication mechanism by
opensips/kamailio?

One of the objectives is in case DB will compromise, users passwords will
not available because random STRING will not store in DB.

Looking forward for suggestions and comments.

--
regards,

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