Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries

2020-06-12 Thread Alex Balashov 

On 6/12/20 9:11 PM, Calvin Ellison wrote:

You suggested to "Monitor your receive queue scrupulously at a very high 
timing resolution". How do I do this?


If using pre-systemd systems, e.g. EL6:

# netstat --inet -n -l | grep 5060

If it's systemd and beyond -- I'm sure Ubuntu Server 18 is, though I 
have no experience with it:


# ss -4nl | grep 5060

Example:

---
[root@allegro-1 ~]# ss -4nl | grep 5060
udpUNCONN 0  0  10.150.20.5:5060  *:* 

udpUNCONN 0  0  10.150.20.2:5060  *:* 

udpUNCONN 0  0  209.51.167.66:5060  *:* 

tcpLISTEN 0  12810.150.20.2:5060  *:* 


---

The third column there (all-0s) is the RecvQ, as can be gleaned from the 
header this command outputs:



Netid  State  Recv-Q Send-Q Local Address:Port   Peer 
Address:Port

---

For `netstat`, it would be the second column.

To monitor it at a low interval, for example 200 ms (5 times per sec), 
you could do something like:


---
#!/bin/bash

while : ; do
echo -n "$(date +"%T.%3N"): "
ss -4nl | grep 5060 | head -1 | awk '{print $3}'
sleep 0.2
done
---

That should give you some idea of where the value sits in general.

You propose there is a pathological issue and the increased buffer size 
is masking it. How do I determine what that issue is?


Without knowing what your exact routing workflow is, I can't say.

However, 99.9% of the time, it occurs in blocking queries to databases 
or other data sources.


I've asked repeatedly about children, shared memory, process 
memory, timer_partitions, etc. but the only answers have been "try 
more". I've been trying more and less of these things two weeks and 
changing the buffers was the only thing that appeared to have any 
immediate impact. How do I know when enough is enough versus too much?


I wrote this article several years ago for Kamailio, but the same basic 
considerations apply to OpenSIPS:


http://www.evaristesys.com/blog/tuning-kamailio-for-high-throughput-and-performance/

"Try more" is definitely not the answer except in cases where the 
workload is overwhelmingly network I/O-bound and/or database-bound. 
Otherwise, the most natural course of action would be to spawn a 
functionally infinite number of children. However, children create 
context switches, contend with each other for CPU time (less a concern 
if most of the workload is waiting on blocking external I/O) and fight 
for various global shared memory structures and locks (still a concern 
regardless). So, there is a point of diminishing returns for any given 
workload. All other things being equal, as per the article, the 
reasonable number of child processes is equal to the number of available 
CPU threads (in /proc/cpuinfo). This number can be increased if the 
workload is very I/O-bound, but only to a point. It's hard to say 
exactly what that point is, and it does have to be empirically 
determined, but I would not run more than 2 * (CPU threads).


Note, there have been no memory-related log messages. The 16-thread 
servers have 48GB RAM and the 8-thread servers have 16GB. I'm happy to 
give all that to OpenSIPS once I know the right way to carve it up.


I see no rationality in giving it all to OpenSIPS.

It's worth bearing in mind that there are two kinds of memory allocations:

- Shared memory, used by the system for global/system-wide data 
constructs, such as transaction memory, dialog state, etc.;


- Package memory, memory that is private to each process and used for 
handling the immediate message. That means every child process 
pre-allocates the package memory requested, so this value should of 
course be much, much smaller than your shared memory pool size.


But still, when you consider all the data that OpenSIPS needs to keep in 
the course of call processing, a lot of it is ephemeral and 
transaction-associated. Once the call is set up, the INVITE transaction 
is disposed. Other call state may add up to a few kilobytes per call at 
most (notwithstanding page sizes and blocks in the underlying 
allocator), but nothing on the order of gigabytes upon gigabytes. 
Assuming 4 KB per call and 200,000 concurrent calls, that's ~800 MB, and 
that is a very generous assumption indeed.


-- Alex

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

Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries

2020-06-12 Thread Calvin Ellison 
On Fri, Jun 12, 2020 at 5:23 PM Alex Balashov 
wrote:

> One should see the forest for the trees, instead of cultivating a myopic
> preoccupation with short-term, stop-gap solutions.
>

Understanding that text lacks tone, this a rather offputting comment for a
mailing list intended to help users. I appreciate your time and feedback,
there's no need to be insulting. Perhaps you could stop assuming what my
preoccupations and scope of vision are and concentrate on the problem and
the solution? The question now is why increasing buffers made any
difference at all.

You suggested to "Monitor your receive queue scrupulously at a very high
timing resolution". How do I do this?

You propose there is a pathological issue and the increased buffer size is
masking it. How do I determine what that issue is?

I've asked repeatedly about children, shared memory, process
memory, timer_partitions, etc. but the only answers have been "try more".
I've been trying more and less of these things two weeks and changing the
buffers was the only thing that appeared to have any immediate impact. How
do I know when enough is enough versus too much?

Note, there have been no memory-related log messages. The 16-thread servers
have 48GB RAM and the 8-thread servers have 16GB. I'm happy to give all
that to OpenSIPS once I know the right way to carve it up.

Should I even be using 2.4?
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries

2020-06-12 Thread Alex Balashov 

On 6/12/20 8:03 PM, Calvin Ellison wrote:

That's been the point of this discussion. Unfortunately, there answers 
so far have added to up "keep changing settings until you find what 
works best" and "buffers are a Ponzi scheme" despite and immediate 3x 
performance increase.


Perhaps if one adopts a rather esoteric understanding of "performance 
increase" ... in principle, queueing more packets indicates the 
opposite. In that light, one could look at a lower receive queue depth 
as an optimisation, actually.


One should see the forest for the trees, instead of cultivating a myopic 
preoccupation with short-term, stop-gap solutions.


Two things are logically possible:

(1) The receive queue backlog keeps stacking up until the size of 16.7m 
is exhausted as well; this is clearly not happening, or it would not be 
triumphantly claimed as a solution;


(2) The higher buffer provides the elasticity needed to cope with 
stochastic I/O wait conditions which, for a given base CPS load, occur 
within a certain range of latencies and at a certain frequency 
distribution. Because the blocking conditions are not always uniformly 
present--they're stochastic, after all--in those low-tide moments, the 
receive queue drains.


The larger buffer solves #2, but not by way of providing for a 
"performance increase". Nothing is performing better. It's a lever--a 
quite imperfect one--to cope with the fact that something is performing 
_quite poorly_. However, fortunately for you, it happens on an 
intermittent basis, otherwise you'd have quickly encountered scenario #1.


#2 is a better and more manageable problem than #1, in strictly relative 
terms, but both are pathological and need to be addressed. To say that 
this amounts to a "tuning" or "optimisation" that yields a "performance 
increase" is profoundly misleading.


-- Alex

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

Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries

2020-06-12 Thread Alex Balashov 
The value is perfectly reasonable for an application that is properly 
coping with its request load.


On 6/12/20 7:49 PM, David Villasmil wrote:
Keep in mundo the don’t make Ubuntu for SIP applications, which have 
their own idiosyncrasies. They make it general purpose. So finding a 
value that doesn’t work perfectly with what you need for this very 
specific application, is not a big deal.


On Sat, 13 Jun 2020 at 00:38, Calvin Ellison > wrote:


I doubt the system will be using all of that buffer. I also don't
know if the issue was in the receive buffer or send buffer since I
changed both at once. Many resources are available online from
people who have already done much more scientific testing that
indicate the default values should be increased for certain
applications, which is the reason I changed it to begin with.
There's no one-size-fits all for server configurations, and what
works for this UDP application with a small number of clients might
not work well for a different application with many TCS connections.

"absolutely terrible" may be too strong of a way to put it, but that
the before and after don't lie.

On Fri, Jun 12, 2020 at 4:02 PM Alex Balashov
mailto:abalas...@evaristesys.com>> wrote:

But increasing the depth of the queue by 78x (if I'm not mistaken,
212992 is the default--at least, it is on all my CentOS 7.x and 8.x

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

--
Regards,

David Villasmil
email: david.villasmil.w...@gmail.com 


phone: +34669448337

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



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

Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries

2020-06-12 Thread Calvin Ellison 
On Fri, Jun 12, 2020 at 4:35 PM David Villasmil <
david.villasmil.w...@gmail.com> wrote:

> Basically, the application is not processing the received packets as
> quickly as it should, so the kernel stores the packets in the buffer so it
> doesn’t have to throw them away.
>
> It’s not so difficult to understand. If this is happening all the time,
> you won’t solve this by making the buffer bigger. You solve this by
> figuring out why the application is not processing the packets fast enough.
>

That's been the point of this discussion. Unfortunately, there answers so
far have added to up "keep changing settings until you find what works
best" and "buffers are a Ponzi scheme" despite and immediate 3x performance
increase.
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries

2020-06-12 Thread Calvin Ellison 
Agreed it's not a big deal that the kernel default is 212992, it's that
value because it's enough for lots of things. It is a big deal not being
aware of its effect on things could be the difference between less than
3,000 CPS and more than 10,000.

On Fri, Jun 12, 2020 at 4:50 PM David Villasmil <
david.villasmil.w...@gmail.com> wrote:

> Keep in mundo the don’t make Ubuntu for SIP applications, which have their
> own idiosyncrasies. They make it general purpose. So finding a value that
> doesn’t work perfectly with what you need for this very specific
> application, is not a big deal.
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries

2020-06-12 Thread David Villasmil 
Keep in mundo the don’t make Ubuntu for SIP applications, which have their
own idiosyncrasies. They make it general purpose. So finding a value that
doesn’t work perfectly with what you need for this very specific
application, is not a big deal.

On Sat, 13 Jun 2020 at 00:38, Calvin Ellison 
wrote:

> I doubt the system will be using all of that buffer. I also don't know if
> the issue was in the receive buffer or send buffer since I changed both at
> once. Many resources are available online from people who have already done
> much more scientific testing that indicate the default values should be
> increased for certain applications, which is the reason I changed it to
> begin with. There's no one-size-fits all for server configurations, and
> what works for this UDP application with a small number of clients might
> not work well for a different application with many TCS connections.
>
> "absolutely terrible" may be too strong of a way to put it, but that the
> before and after don't lie.
>
> On Fri, Jun 12, 2020 at 4:02 PM Alex Balashov 
> wrote:
>
>> But increasing the depth of the queue by 78x (if I'm not mistaken,
>> 212992 is the default--at least, it is on all my CentOS 7.x and 8.x
>>
>> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
-- 
Regards,

David Villasmil
email: david.villasmil.w...@gmail.com
phone: +34669448337
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries

2020-06-12 Thread Calvin Ellison 
I doubt the system will be using all of that buffer. I also don't know if
the issue was in the receive buffer or send buffer since I changed both at
once. Many resources are available online from people who have already done
much more scientific testing that indicate the default values should be
increased for certain applications, which is the reason I changed it to
begin with. There's no one-size-fits all for server configurations, and
what works for this UDP application with a small number of clients might
not work well for a different application with many TCS connections.

"absolutely terrible" may be too strong of a way to put it, but that the
before and after don't lie.

On Fri, Jun 12, 2020 at 4:02 PM Alex Balashov 
wrote:

> But increasing the depth of the queue by 78x (if I'm not mistaken,
> 212992 is the default--at least, it is on all my CentOS 7.x and 8.x
>
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries

2020-06-12 Thread David Villasmil 
Basically, the application is not processing the received packets as
quickly as it should, so the kernel stores the packets in the buffer so it
doesn’t have to throw them away.

It’s not so difficult to understand. If this is happening all the time, you
won’t solve this by making the buffer bigger. You solve this by figuring
out why the application is not processing the packets fast enough.


On Sat, 13 Jun 2020 at 00:28, Alex Balashov 
wrote:

> On 6/12/20 7:20 PM, Calvin Ellison wrote:
>
> > I think the important point here is that the receive buffers are used to
> > hold received data until it is read by the application. In fact, too
> > small of a receive buffer would cause packets to be discarded outright,
> > regardless of how fast the application can respond. Not knowing how
> > large of a buffer is needed was the problem, not the raw processing
> > power. It doesn't matter how fast I can eat if the server only has very
> > small plates to bring the food every trip from the kitchen.
>
> In absolute terms, this is true. But if your kitchen is putting out so
> much food that not even ~200,000 plates "in flight" will do, you've got
> a bigger problem to address and adding more plates is just papering it
> over.
>
> Monitor your receive queue scrupulously at a very high timing
> resolution. If you found default values for rmem_max to be "absolutely
> terrible", that means the backlog was increasing monotonically until you
> ran out of space. If you increase the queue depth, you will be able to
> prolong this effect for a while.
>
> The kernel's packet queue is a backstop--an emergency release valve, not
> a main thoroughfare. It's there to help you deal with ephemeral
> congestion caused by things like periodic big-lock background process
> contention, scheduler hiccups, disk controller patrol reads, etc.  But
> the base load should result in a long-run queue backlog of zero.
> Applications which properly cope with their workload don't cause
> non-trivial packet or connection queueing on the OS side.
>
> -- Alex
>
> --
> 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
>
-- 
Regards,

David Villasmil
email: david.villasmil.w...@gmail.com
phone: +34669448337
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries

2020-06-12 Thread Alex Balashov 

On 6/12/20 7:20 PM, Calvin Ellison wrote:

I think the important point here is that the receive buffers are used to 
hold received data until it is read by the application. In fact, too 
small of a receive buffer would cause packets to be discarded outright, 
regardless of how fast the application can respond. Not knowing how 
large of a buffer is needed was the problem, not the raw processing 
power. It doesn't matter how fast I can eat if the server only has very 
small plates to bring the food every trip from the kitchen.


In absolute terms, this is true. But if your kitchen is putting out so 
much food that not even ~200,000 plates "in flight" will do, you've got 
a bigger problem to address and adding more plates is just papering it 
over.


Monitor your receive queue scrupulously at a very high timing 
resolution. If you found default values for rmem_max to be "absolutely 
terrible", that means the backlog was increasing monotonically until you 
ran out of space. If you increase the queue depth, you will be able to 
prolong this effect for a while.


The kernel's packet queue is a backstop--an emergency release valve, not 
a main thoroughfare. It's there to help you deal with ephemeral 
congestion caused by things like periodic big-lock background process 
contention, scheduler hiccups, disk controller patrol reads, etc.  But 
the base load should result in a long-run queue backlog of zero. 
Applications which properly cope with their workload don't cause 
non-trivial packet or connection queueing on the OS side.


-- Alex

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

Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries

2020-06-12 Thread Calvin Ellison 
I think the important point here is that the receive buffers are used to
hold received data until it is read by the application. In fact, too small
of a receive buffer would cause packets to be discarded outright,
regardless of how fast the application can respond. Not knowing how large
of a buffer is needed was the problem, not the raw processing power. It
doesn't matter how fast I can eat if the server only has very small plates
to bring the food every trip from the kitchen.


On Fri, Jun 12, 2020 at 4:02 PM Alex Balashov 
wrote:

> Perhaps a simpler way look at it: buffers. It's in the name - they
> buffer things.
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries

2020-06-12 Thread Alex Balashov 

On 6/12/20 7:08 PM, Calvin Ellison wrote:

I don't disagree that there is a physical limit to what any hardware can 
achieve. However, there was a dramatic difference between the default 
setting and the increased setting.
I do: the default setting leaves packets beyond the depth of the queue 
dropped, which, in the case of SIP requests and some responses, causes 
them to be retransmitted, which creates a positive feedback loop. 
Letting them stack up allows more of them to be attended to eventually, 
reducing that dynamic.


But telling the OS network stack to hold more packets because you can't 
process them fast enough isn't a solution to the problem of not 
processing them fast enough. You're infinitely better off just 
processing them faster.


-- Alex

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

Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries

2020-06-12 Thread Calvin Ellison 
I don't disagree that there is a physical limit to what any hardware can
achieve. However, there was a dramatic difference between the default
setting and the increased setting. I have no explanation for this, as I am
not a kernel or network developer.  I'm happy to run the load test again
both ways and see if there was any difference in response times.


On Fri, Jun 12, 2020 at 3:51 PM Alex Balashov 
wrote:

> There's no free lunch, but it seems like you and others want one. :-)
>
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries

2020-06-12 Thread Alex Balashov 
Perhaps a simpler way look at it: buffers. It's in the name - they 
buffer things.


If your "work queue" buffer (which is what the packet RecvQ 
fundamentally is) is chronically full, to the degree that it needs 
increased significantly, it means things aren't consistently leaving out 
at the other end at the same velocity that they're coming in.


In small amounts, this regulating capacity is acceptable and 
necessary--that's why buffers exist.


But increasing the depth of the queue by 78x (if I'm not mistaken, 
212992 is the default--at least, it is on all my CentOS 7.x and 8.x 
systems, which I guess also have "absolutely terrible sysctl defaults") 
is faker than a Ponzi scheme. In some other contexts, this would be 
called morally bankrupt and intellectually fraudulent. I guess here we 
call it "mad dialer CPS" or whatever.


-- Alex

On 6/12/20 6:50 PM, Alex Balashov wrote:
There's no free lunch, but it seems like you and others want one. :-) 
Increasing these values just increases the depth of the kernel's packet 
queue for the sync processes to consume as able. It doesn't mean they're 
able, and accordingly, request response time will go up.


A healthy system that is able to keep up with the load you're throwing 
at it should show a receive queue at +/- 0 most of the time, maybe with 
some ephemeral spikes but generally trending around 0. If packets are 
stacking up in the RecvQ, it means the SIP worker processes aren't 
available enough to consume them all in a timely fashion.


Leaning on async won't help here if the workload is largely CPU-bound. 
If it's largely bound over waiting on network I/O from external 
services, it merely deputises the problem of notifying you when there's 
a response from those services to the kernel. But - vitally - it won't 
get your requests processed faster, and setup latency is a very 
important consideration in real-time communications, especially from the 
perspective of interoperability with the synchronous/circuit-switched PSTN.


In short, async isn't magic, and neither is increasing the receive 
queue. It's simple thermodynamics; there's only so much CPU available, 
and depending on the nature of the workload, throughput becomes more a 
linear function of available CPU hardware threads, or less, but slower, 
if it's largely I/O-bound.


The metaphor of a balloon is appropriate. You're pushing the problem 
around by squeezing one part of the balloon, causing another to enlarge. 
Various parts of the balloon can be squeezed - async vs. sync, various 
queues and buffers, etc. But the internal volume of air held by the 
balloon is more or less the same. A little slack can be added into the 
system through your rmem_max technique, as long as you're willing to 
tolerate increased processing latency--and it will generate increased 
latency; if it didn't, you wouldn't need to increase it--but ultimately, 
you're just pushing the air around the balloon. A fixed amount of CPU 
and memory is available to accommodate the large number of processes 
that sleep on an external I/O-bound workload, and there are diminishing 
returns from both internal OpenSIPS contention and context switching.


I'm not saying there aren't some local minima and maxima, but they 
aren't as magnitudinal as folks think. It's not that Ubuntu Server is 
mistuned, it's that you're abusing it. :-) You can't put the milk back 
in the cow, although it's quite a spectacle ...


-- Alex

On 6/12/20 6:02 PM, Calvin Ellison wrote:
I noticed a way-too-small receive buffer value in the OpenSIPS startup 
messages and it turns out that a fresh Ubuntu 18 Server install has 
absolutely terrible sysctl defaults for high-performance networking. I 
got my 8-core lab from less than 2,000 CPS up to 14,000 CPS using a 
spread of all dips in non-async mode just by setting the following to 
match "maxbuffer=16777216":


net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

Does OpenSIPS have guidelines for sysclt and other OS parameters?

    Async requires the TM module which adds additional overhead and
    memory allocation.


According to with the docs:
"By requiring less processes to complete the same amount of work in the
same amount of time, process context switching is minimized and
overall CPU usage is improved. Less processes will also eat up less
system memory."

So which is it? When should async be used, and when should async not 
be used? One can only invest so many hours in load testing 
combinations of sync/async, the number of children, timer_partitions, 
etc. Some fuzzy math based on CPU core count, SpecInt Rate, BogoMIPS, 
etc. would be a great starting point.


Regards,

*Calvin Ellison*
Senior Voice Operations Engineer
calvin.elli...@voxox.com 


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





--
Alex Balashov | Principal | Evariste Systems LLC

Tel:

Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries

2020-06-12 Thread Alex Balashov 
There's no free lunch, but it seems like you and others want one. :-) 
Increasing these values just increases the depth of the kernel's packet 
queue for the sync processes to consume as able. It doesn't mean they're 
able, and accordingly, request response time will go up.


A healthy system that is able to keep up with the load you're throwing 
at it should show a receive queue at +/- 0 most of the time, maybe with 
some ephemeral spikes but generally trending around 0. If packets are 
stacking up in the RecvQ, it means the SIP worker processes aren't 
available enough to consume them all in a timely fashion.


Leaning on async won't help here if the workload is largely CPU-bound. 
If it's largely bound over waiting on network I/O from external 
services, it merely deputises the problem of notifying you when there's 
a response from those services to the kernel. But - vitally - it won't 
get your requests processed faster, and setup latency is a very 
important consideration in real-time communications, especially from the 
perspective of interoperability with the synchronous/circuit-switched PSTN.


In short, async isn't magic, and neither is increasing the receive 
queue. It's simple thermodynamics; there's only so much CPU available, 
and depending on the nature of the workload, throughput becomes more a 
linear function of available CPU hardware threads, or less, but slower, 
if it's largely I/O-bound.


The metaphor of a balloon is appropriate. You're pushing the problem 
around by squeezing one part of the balloon, causing another to enlarge. 
Various parts of the balloon can be squeezed - async vs. sync, various 
queues and buffers, etc. But the internal volume of air held by the 
balloon is more or less the same. A little slack can be added into the 
system through your rmem_max technique, as long as you're willing to 
tolerate increased processing latency--and it will generate increased 
latency; if it didn't, you wouldn't need to increase it--but ultimately, 
you're just pushing the air around the balloon. A fixed amount of CPU 
and memory is available to accommodate the large number of processes 
that sleep on an external I/O-bound workload, and there are diminishing 
returns from both internal OpenSIPS contention and context switching.


I'm not saying there aren't some local minima and maxima, but they 
aren't as magnitudinal as folks think. It's not that Ubuntu Server is 
mistuned, it's that you're abusing it. :-) You can't put the milk back 
in the cow, although it's quite a spectacle ...


-- Alex

On 6/12/20 6:02 PM, Calvin Ellison wrote:
I noticed a way-too-small receive buffer value in the OpenSIPS startup 
messages and it turns out that a fresh Ubuntu 18 Server install has 
absolutely terrible sysctl defaults for high-performance networking. I 
got my 8-core lab from less than 2,000 CPS up to 14,000 CPS using a 
spread of all dips in non-async mode just by setting the following to 
match "maxbuffer=16777216":


net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

Does OpenSIPS have guidelines for sysclt and other OS parameters?

Async requires the TM module which adds additional overhead and
memory allocation.


According to with the docs:
"By requiring less processes to complete the same amount of work in the
same amount of time, process context switching is minimized and
overall CPU usage is improved. Less processes will also eat up less
system memory."

So which is it? When should async be used, and when should async not be 
used? One can only invest so many hours in load testing combinations of 
sync/async, the number of children, timer_partitions, etc. Some fuzzy 
math based on CPU core count, SpecInt Rate, BogoMIPS, etc. would be a 
great starting point.


Regards,

*Calvin Ellison*
Senior Voice Operations Engineer
calvin.elli...@voxox.com 


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



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

Re: [OpenSIPS-Users] Fine tuning high CPS and msyql queries

2020-06-12 Thread Calvin Ellison 
 I noticed a way-too-small receive buffer value in the OpenSIPS startup
messages and it turns out that a fresh Ubuntu 18 Server install has
absolutely terrible sysctl defaults for high-performance networking. I got
my 8-core lab from less than 2,000 CPS up to 14,000 CPS using a spread of
all dips in non-async mode just by setting the following to match
"maxbuffer=16777216":

net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

Does OpenSIPS have guidelines for sysclt and other OS parameters?

Async requires the TM module which adds additional overhead and memory
> allocation.


According to with the docs:
"By requiring less processes to complete the same amount of work in the
same amount of time, process context switching is minimized and
overall CPU usage is improved. Less processes will also eat up less
system memory."

So which is it? When should async be used, and when should async not be
used? One can only invest so many hours in load testing combinations of
sync/async, the number of children, timer_partitions, etc. Some fuzzy math
based on CPU core count, SpecInt Rate, BogoMIPS, etc. would be a great
starting point.

Regards,

*Calvin Ellison*
Senior Voice Operations Engineer
calvin.elli...@voxox.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] opensipsctl fifo dlg_list not working on 3.1

2020-06-12 Thread mrsanvicente 
Ohh!   Thank  you Bogdan.

Mario San Vicente
Best regards

> El 12 jun 2020, a la(s) 16:22, Bogdan-Andrei Iancu  
> escribió:
> 
>  Hey MArio,
> 
> Starting 3.0 the MI interface changed as syntax and the opensipsctl was 
> deprecated in favour of the opensips-cli
> https://github.com/OpenSIPS/opensips-cli
> 
> Regards,
>  Bogdan-Andrei Iancu
> 
> OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
> 
> On 6/12/20 9:48 PM, Mario San Vicente wrote:
>> Hello Everybody!,
>> 
>> I have been using "opensipsctl fifo dlg_list" on opensips 2.4 to count the 
>> active calls and it works fine.  Now that i have migrated to 3.1, the call 
>> flow is working fine,  but the same command is not working, after typing the 
>> command it just hang out.
>> 
>> I get the following error on the logs :
>> 
>> localhost /usr/local/sbin/opensips[25782]: ERROR:mi_fifo:mi_fifo_server: 
>> cannot parse command: osips_rply_7bcc7ad0
>> 
>> [root@localhost opensips]# opensips -V
>> version: opensips 3.1.0-beta (x86_64/linux)
>> flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC, 
>> F_MALLOC, HP_MALLOC, DBG_MALLOC, CC_O0, 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, sigio_rt, select.
>> git revision: 5fb9059
>> main.c compiled on 13:01:28 Jun 12 2020 with gcc 4.8.5
>> 
>> 
>> Can you confirm if this is a bug?  Do you need any other information?
>> 
>> Thanks
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Mario San Vicente
>> Cheers!
>> 
>> 
>> ___
>> 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] opensipsctl fifo dlg_list not working on 3.1

2020-06-12 Thread Bogdan-Andrei Iancu 

Hey MArio,

Starting 3.0 the MI interface changed as syntax and the opensipsctl was 
deprecated in favour of the opensips-cli

    https://github.com/OpenSIPS/opensips-cli

Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com

On 6/12/20 9:48 PM, Mario San Vicente wrote:

Hello Everybody!,

I have been using "opensipsctl fifo dlg_list" on opensips 2.4 to count 
the active calls and it works fine.  Now that i have migrated to 3.1, 
the call flow is working fine,  but the same command is not working, 
after typing the command it just hang out.


I get the following error on the logs :

localhost /usr/local/sbin/opensips[25782]: 
ERROR:mi_fifo:mi_fifo_server: cannot parse command: osips_rply_7bcc7ad0


[root@localhost opensips]# opensips -V
version: opensips 3.1.0-beta (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, 
Q_MALLOC, F_MALLOC, HP_MALLOC, DBG_MALLOC, CC_O0, 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, sigio_rt, select.
git revision: 5fb9059
main.c compiled on 13:01:28 Jun 12 2020 with gcc 4.8.5


Can you confirm if this is a bug?  Do you need any other information?

Thanks





--
Mario San Vicente
Cheers!

___
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] opensipsctl fifo dlg_list not working on 3.1

2020-06-12 Thread Mario San Vicente 
Hello Everybody!,

I have been using "opensipsctl fifo dlg_list" on opensips 2.4 to count the
active calls and it works fine.  Now that i have migrated to 3.1, the call
flow is working fine,  but the same command is not working, after typing
the command it just hang out.

I get the following error on the logs :

localhost /usr/local/sbin/opensips[25782]: ERROR:mi_fifo:mi_fifo_server:
cannot parse command: osips_rply_7bcc7ad0

[root@localhost opensips]# opensips -V
version: opensips 3.1.0-beta (x86_64/linux)
flags: STATS: On, DISABLE_NAGLE, USE_MCAST, SHM_MMAP, PKG_MALLOC, Q_MALLOC,
F_MALLOC, HP_MALLOC, DBG_MALLOC, CC_O0, 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, sigio_rt, select.
git revision: 5fb9059
main.c compiled on 13:01:28 Jun 12 2020 with gcc 4.8.5


Can you confirm if this is a bug?  Do you need any other information?

Thanks





-- 
Mario San Vicente
Cheers!
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] opensips-cli error

2020-06-12 Thread Mark Farmer 
That got it Liviu :)

Thank you!
Mark.


On Fri, 12 Jun 2020 at 13:37, Liviu Chircu  wrote:

> On 12.06.2020 15:28, Mark Farmer wrote:
> > locate opensipscli
> >
> /usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO
>
> OK, so let's clear the install and redo it:
>
> sudo rm -fr /usr/local/lib/python3.6/dist-packages/opensipscli*
>
> cd /usr/local/src/opensips-cli
>
> git pull --rebase
>
> sudo python3 setup.py install clean
>
> cd # go back to home dir
>
> opensips-cli
>
> Hopefully, the last command should work!  Curious to see if it works on
> your system as well, as it often solves this problem for me (although I
> still don't quite understand what I'm doing...)
>
> PS: you don't have to do this on every "git pull --rebase".  Just when
> it "breaks"...
>
> Regards,
>
> --
> Liviu Chircu
> www.twitter.com/liviuchircu | www.opensips-solutions.com
>
>
> ___
> Users mailing list
> Users@lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>


-- 
Mark Farmer
farm...@gmail.com
___
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users

Re: [OpenSIPS-Users] opensips-cli error

2020-06-12 Thread Liviu Chircu 

On 12.06.2020 15:28, Mark Farmer wrote:

locate opensipscli
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO


OK, so let's clear the install and redo it:

sudo rm -fr /usr/local/lib/python3.6/dist-packages/opensipscli*

cd /usr/local/src/opensips-cli

git pull --rebase

sudo python3 setup.py install clean

cd # go back to home dir

opensips-cli

Hopefully, the last command should work!  Curious to see if it works on 
your system as well, as it often solves this problem for me (although I 
still don't quite understand what I'm doing...)


PS: you don't have to do this on every "git pull --rebase".  Just when 
it "breaks"...


Regards,

--
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com


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

Re: [OpenSIPS-Users] opensips-cli error

2020-06-12 Thread Mark Farmer 
Hi Liviu, as requested:

locate opensipscli
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0.egg-info
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO/PKG-INFO
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO/SOURCES.txt
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO/dependency_links.txt
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO/not-zip-safe
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO/requires.txt
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO/scripts
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO/top_level.txt
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/EGG-INFO/scripts/opensips-cli
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__init__.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__pycache__
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/cli.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/comm.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/communication
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/config.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/db.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/defaults.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/logger.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/main.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/module.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__pycache__/__init__.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__pycache__/cli.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__pycache__/comm.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__pycache__/config.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__pycache__/db.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__pycache__/defaults.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__pycache__/logger.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__pycache__/main.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/__pycache__/module.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/communication/__init__.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/communication/__pycache__
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/communication/fifo.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/communication/http.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/communication/jsonrpc_helper.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/communication/__pycache__/__init__.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/communication/__pycache__/fifo.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/communication/__pycache__/http.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/communication/__pycache__/jsonrpc_helper.cpython-36.pyc
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/__init__.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/__pycache__
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/database.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/diagnose.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/instance.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/mi.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/tls.py
/usr/local/lib/python3.6/dist-packages/opensipscli-0.1.0-py3.6.egg/opensipscli/modules/trace.py

Re: [OpenSIPS-Users] opensips-cli error

2020-06-12 Thread Liviu Chircu 

On 12.06.2020 15:10, Mark Farmer wrote:

root@sbc-pstn-els-1:/usr/local/src/opensips-cli# opensips-cli
Traceback (most recent call last):
  File "/usr/local/bin/opensips-cli", line 4, in 
__import__('pkg_resources').run_script('opensipscli==0.1.0', 
'opensips-cli')
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", 
line 658, in run_script

    self.require(requires)[0].run_script(script_name, ns)
  File "/usr/lib/python3/dist-packages/pkg_resources/__init__.py", 
line 1429, in run_script

    .format(**locals()),
pkg_resources.ResolutionError: Script 'scripts/opensips-cli' not found 
in metadata at None


As before I can run it OK from the source dir:

python3 bin/opensips-cli

Beyond that I'm rather stuck. Any ideas?


Hi, Mark!

Can you please do:

sudo updatedb
locate opensipscli

... and provide the output?  I suspect there are some lingering 
directories under "/usr/local/lib/python..." which we must "rm -fr", 
then the install will be clean.


Regards,

--
Liviu Chircu
www.twitter.com/liviuchircu | www.opensips-solutions.com


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

Re: [OpenSIPS-Users] opensips-cli error

2020-06-12 Thread Mark Farmer 
This one has reared it's head again today. I did a fresh install on 2 boxes
but I forgot to make sure the deps were installed one of them.
Now when I try to run opensips-cli I get the error again. The other box
with the deps preinstalled is fine. I've tried reinstalling opensips-cli
several times but no luck.

This is the install log & error:

/usr/local/src/opensips-cli# python3 setup.py install clean
/usr/lib/python3.6/distutils/dist.py:261: UserWarning: Unknown distribution
option: 'long_description_content_type'
  warnings.warn(msg)
running install
running bdist_egg
running egg_info
creating opensipscli.egg-info
writing opensipscli.egg-info/PKG-INFO
writing dependency_links to opensipscli.egg-info/dependency_links.txt
writing requirements to opensipscli.egg-info/requires.txt
writing top-level names to opensipscli.egg-info/top_level.txt
writing manifest file 'opensipscli.egg-info/SOURCES.txt'
reading manifest file 'opensipscli.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
warning: no files found matching 'MANIFEST'
writing manifest file 'opensipscli.egg-info/SOURCES.txt'
installing library code to build/bdist.linux-x86_64/egg
running install_lib
running build_py
creating build
creating build/lib
creating build/lib/opensipscli
copying opensipscli/__init__.py -> build/lib/opensipscli
copying opensipscli/main.py -> build/lib/opensipscli
copying opensipscli/comm.py -> build/lib/opensipscli
copying opensipscli/db.py -> build/lib/opensipscli
copying opensipscli/cli.py -> build/lib/opensipscli
copying opensipscli/module.py -> build/lib/opensipscli
copying opensipscli/config.py -> build/lib/opensipscli
copying opensipscli/logger.py -> build/lib/opensipscli
copying opensipscli/defaults.py -> build/lib/opensipscli
creating build/lib/opensipscli/modules
copying opensipscli/modules/__init__.py -> build/lib/opensipscli/modules
copying opensipscli/modules/tls.py -> build/lib/opensipscli/modules
copying opensipscli/modules/diagnose.py -> build/lib/opensipscli/modules
copying opensipscli/modules/trap.py -> build/lib/opensipscli/modules
copying opensipscli/modules/instance.py -> build/lib/opensipscli/modules
copying opensipscli/modules/user.py -> build/lib/opensipscli/modules
copying opensipscli/modules/mi.py -> build/lib/opensipscli/modules
copying opensipscli/modules/trace.py -> build/lib/opensipscli/modules
copying opensipscli/modules/database.py -> build/lib/opensipscli/modules
creating build/lib/opensipscli/communication
copying opensipscli/communication/__init__.py ->
build/lib/opensipscli/communication
copying opensipscli/communication/http.py ->
build/lib/opensipscli/communication
copying opensipscli/communication/fifo.py ->
build/lib/opensipscli/communication
copying opensipscli/communication/jsonrpc_helper.py ->
build/lib/opensipscli/communication
creating build/bdist.linux-x86_64
creating build/bdist.linux-x86_64/egg
creating build/bdist.linux-x86_64/egg/opensipscli
copying build/lib/opensipscli/__init__.py ->
build/bdist.linux-x86_64/egg/opensipscli
copying build/lib/opensipscli/main.py ->
build/bdist.linux-x86_64/egg/opensipscli
creating build/bdist.linux-x86_64/egg/opensipscli/modules
copying build/lib/opensipscli/modules/__init__.py ->
build/bdist.linux-x86_64/egg/opensipscli/modules
copying build/lib/opensipscli/modules/tls.py ->
build/bdist.linux-x86_64/egg/opensipscli/modules
copying build/lib/opensipscli/modules/diagnose.py ->
build/bdist.linux-x86_64/egg/opensipscli/modules
copying build/lib/opensipscli/modules/trap.py ->
build/bdist.linux-x86_64/egg/opensipscli/modules
copying build/lib/opensipscli/modules/instance.py ->
build/bdist.linux-x86_64/egg/opensipscli/modules
copying build/lib/opensipscli/modules/user.py ->
build/bdist.linux-x86_64/egg/opensipscli/modules
copying build/lib/opensipscli/modules/mi.py ->
build/bdist.linux-x86_64/egg/opensipscli/modules
copying build/lib/opensipscli/modules/trace.py ->
build/bdist.linux-x86_64/egg/opensipscli/modules
copying build/lib/opensipscli/modules/database.py ->
build/bdist.linux-x86_64/egg/opensipscli/modules
copying build/lib/opensipscli/comm.py ->
build/bdist.linux-x86_64/egg/opensipscli
copying build/lib/opensipscli/db.py ->
build/bdist.linux-x86_64/egg/opensipscli
copying build/lib/opensipscli/cli.py ->
build/bdist.linux-x86_64/egg/opensipscli
copying build/lib/opensipscli/module.py ->
build/bdist.linux-x86_64/egg/opensipscli
copying build/lib/opensipscli/config.py ->
build/bdist.linux-x86_64/egg/opensipscli
creating build/bdist.linux-x86_64/egg/opensipscli/communication
copying build/lib/opensipscli/communication/__init__.py ->
build/bdist.linux-x86_64/egg/opensipscli/communication
copying build/lib/opensipscli/communication/http.py ->
build/bdist.linux-x86_64/egg/opensipscli/communication
copying build/lib/opensipscli/communication/fifo.py ->
build/bdist.linux-x86_64/egg/opensipscli/communication
copying build/lib/opensipscli/communication/jsonrpc_helper.py ->
build/bdist.linux-x86_64/egg/opensipscli/communication
copying

Re: [OpenSIPS-Users] adding and reading a SIP header to a 302 Redirect

2020-06-12 Thread Bogdan-Andrei Iancu 

Take a look at the append_to_reply() [1] function.

[1] 
https://opensips.org/docs/modules/3.1.x/sipmsgops.html#func_append_to_reply


Regards,

Bogdan-Andrei Iancu

OpenSIPS Founder and Developer
  https://www.opensips-solutions.com

On 5/30/20 3:14 PM, Saint Michael wrote:

I need to add a new SIP header to the response below.


if ($rm=="INVITE") {
    /* add the redirect destinations as branches */
    $branch = "sip:bat...@gotham.com ";
    $branch = $avp(my_custom_uri);
    /* sending a 3xx reply will automatically push all
     * existing branches as Contact URIs */
    send_reply("302","Moved Temporarily");
    exit;
}
the final result should be:

SIP/2.0 302 Moved Temporarily
Via: SIP/2.0/UDP 
172.16.7.254:52169;rport=52169;received=47.205.172.89;branch=z9hG4bK-524287-1---129f4244aaba9f04

Call-ID: 102650Mzg4NmFiNTQzOGY5NDJmNjM3OTYzNmE5MzNlZDIwZmI
From: "X" ;tag=81a25c36
To: 
;tag=9e198dc4-7ce8-433d-ae23-05b9bc14d55a

Identity:eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2VuIiwieDV1IjoiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6WyI2MzE3OTE4Mzc4Il19LCJpYXQiOjE1OTA4MTEyMzgsIm9yaWciOnsidG4iOiI3Mjc0NDMzMDE5In0sIm9yaWdpZCI6IjEyM2U0NTY3LWU4OWItMTJkMy1hNDU2LTQyNjY1NTQ0MDAwMCJ9.AKViDWA3uonP6tt5cKBh0FUPY5zBuJnwZLQNTrp9LCWJ-vLY1Xx5i3_oXGh1ERL4tnD-KK5wsP3FdByDa_cjGw;info=;alg=ES256;ppt=shaken
CSeq: 1 INVITE
Server: Asterisk PBX 16.10.0
Contact: 
Reason: Q.850;cause=0
Content-Length:  0

also if I get that packet at my end, how do I extract the Identity 
header and apply it to the next INVITE?

Is this even doable?




___
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] install RTPEngine on Centos 8

2020-06-12 Thread Denys Pozniak 
Hello,

Did you add external repos (rpmfusion and epel)?
https://rpmfusion.org/Configuration/

[root@localhost ~]# rpm -qa | grep rtpengine
ngcp-rtpengine-kernel-8.4.1.1-2.el8.x86_64
ngcp-rtpengine-debugsource-8.4.1.1-2.el8.x86_64
ngcp-rtpengine-debuginfo-8.4.1.1-2.el8.x86_64
ngcp-rtpengine-8.4.1.1-2.el8.x86_64
ngcp-rtpengine-recording-8.4.1.1-2.el8.x86_64
ngcp-rtpengine-recording-debuginfo-8.4.1.1-2.el8.x86_64
ngcp-rtpengine-dkms-8.4.1.1-2.el8.noarch
ngcp-rtpengine-kernel-debuginfo-8.4.1.1-2.el8.x86_64

[root@localhost ~]# cat /etc/redhat-release
CentOS Linux release 8.1.1911 (Core)


чт, 11 июн. 2020 г. в 23:38, Dragomir Haralambiev :

> Hello,
>
> Thanks for your reply.
> I try to instal RTPEngine but receive follow errors:
> # dnf install ngcp-rtpengine
> Last metadata expiration check: 0:28:59 ago on Thu 11 Jun 2020 10:33:39 PM
> EEST.
> Error:
> Problem: conflicting requests
> - nothing provides libavcodec.so.58()(64bit) needed by
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libavcodec.so.58(LIBAVCODEC_58)(64bit) needed by
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libavfilter.so.7()(64bit) needed by
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libavformat.so.58()(64bit) needed by
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libavformat.so.58(LIBAVFORMAT_58)(64bit) needed by
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libavutil.so.56()(64bit) needed by
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libavutil.so.56(LIBAVUTIL_56)(64bit) needed by
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libswresample.so.3()(64bit) needed by
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides libswresample.so.3(LIBSWRESAMPLE_3)(64bit) needed by
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
> - nothing provides ffmpeg-libs needed by
> ngcp-rtpengine-8.4.1.1-1.el8.x86_64
>
> What I do to install this package?
>
> На чт, 4.06.2020 г. в 15:35 Denys Pozniak 
> написа:
>
>> Hello!
>> Try to use my build (not tested, as is):
>> https://copr.fedorainfracloud.org/coprs/denysp/rtpengine-centos8/
>>
>>
>> чт, 4 июн. 2020 г. в 12:20, Dragomir Haralambiev :
>>
>>> Hello,
>>>
>>> I need to  install RTPEngine on Centos 8?
>>> Any help
>>>
>>> Best regards,
>>> Dragomir
>>> ___
>>> Users mailing list
>>> Users@lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>
>>
>>
>> --
>>
>> BR,
>> Denys Pozniak
>>
>>
>> ___
>> 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
>


-- 

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