<div dir="ltr">Daniel, thank you for your interest. Yes, there were many architectural changes between 1.x and 2.0. The most noticeable is that we've decoupled I/O from the control channel handling and also split I/O into two threads, one for poll/receive and the second one for the sending. We've also refactored our scheduling algorithms to provide much better performance jitter-wise. There are more threads than two in 2.0, but most of them are not using much CPU if any. As such as a rule of thumb you'd want to run max one rtpproxy per two CPU cores with 2.0, up from one instance per core with 1.x. Yes, 1000 bi-directional streams is realistic value, at least in a situation when you have multiple rtpproxy instances running concurrently on the box which creates non-trivial overhead in terms of system calls contention. You can probably go higher than 1,000 if you have single instance and/or latest CPU. There is detailed 2.0 release notes document available at our github project. <div><br></div><div>In terms of cpu usage while idle, I am not aware of any major issues with 2.0. That being said, rtpproxy is known to be somewhat wasteful in general while running with no load, it still does 200 poll's a second and that tends to consume <1% of single core CPU per running instance. I've got some ideas on how to fix it, but that would not be available until 2.2 is out somewhere in 2017. We are working on getting 2.1 out, which would include new plain text accounting module more refinements and improvements. Among those, we've added experimental support for running control channel over TCPv4 and TCPv6 sockets, still something that needs to be integrated back into all children of SER.</div><div><br></div><div>We are aware that packaging is somewhat behind in some distros*. However, we ourselves and most of our biggest customers roll their own builds anyway, so we just rely on the community to take care of. That being said, we always welcome pull requests to get stuff that might help others to package it on FooLinux.</div><div><br></div><div>Please don't hesitate to ask if something is unclear or if you have more questions. Thanks!</div><div><br></div><div>-Max</div><div class="gmail_extra">*) Sometimes I get a feeling that there are too many to chose from these days, but oh well... :)</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 19, 2016 at 1:19 AM, Daniel-Constantin Mierla <span dir="ltr"><<a href="mailto:miconda@gmail.com" target="_blank">miconda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<p>Hello Maxim,<br>
</p>
given the discussion here, I would like to get some updates for
myself regarding 2.0 in terms of capacity and other stuff.<br>
<br>
I was using rtpproxy 1.x with kamailio doing load balancing across
many instances of rtpproxy. I was using 1000 streams as estimation
for one instance and I see it's what you mentioned as well. Is it
the recommended (or the good) value for 2.0? Most of deployments
still use v1.2, given it's presence in stable/old OS distros.<br>
<br>
It's any relevant architectural change in 2.0? Like more threads
used by the app or other I/O refactoring? Iirc, v1.x uses one for
control commands?<br>
<br>
I wanted to report at some point, with v1.x, on some centos (iirc),
when there was no active call, rtpproxy was eating a lot of cpu.
With a call (or more) going on, the cpu went to normal. I think it
was like waiting for I/O was using the cpu. Switching to debian was
a solution at that moment, so might not be rtpproxy, but I am
wondering if you or anyone else faced same issue. Also, if I am not
wrong, the person that reported to me said that 2.0 didn't revealed
the same behaviour.<br>
<br>
Cheers,<br>
Daniel<div><div class="h5"><br>
<br>
<div class="m_8792476622718572238moz-cite-prefix">On 19/10/16 09:46, Maxim Sobolev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Alex, no problem. Nobody knows everything. :)
<div><br>
</div>
<div>-Max</div>
<div><br>
</div>
<div>On Wed, Oct 19, 2016 at 12:35 AM, Alex Balashov <span dir="ltr"><<a href="mailto:abalashov@evaristesys.com" target="_blank">abalashov@evaristesys.com</a>></span>
wrote:
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi
Maxim,<br>
<br>
Duly noted! I certainly did not intend to mislead anyone
or to be disingenuous; I gave information that was, to
the best of my knowledge, true. I appreciate your
followup and clarification, which certainly is useful
for my own knowledge as well!<br>
<br>
My sincere apologies...<br>
<br>
-- Alex<br>
<div>
<div class="m_8792476622718572238h5"><br>
<br>
On October 19, 2016 3:32:24 AM EDT, Maxim Sobolev
<<a href="mailto:sobomax@sippysoft.com" target="_blank">sobomax@sippysoft.com</a>>
wrote:<br>
>Alex, with all due respect, things you said
about rtpproxy capacity is<br>
>somewhat outdated and misleading. We have some
nodes in the field, that<br>
>handle 5,000-6,000 rtp sessions in peak. Those
are running 6 rtpproxy<br>
>instances, 1,000 sessions each. 2-3 year old
CPUs, 12 cores in total.<br>
><br>
>We also have an open source solution called
rtp_cluster, which allows<br>
>building larger scale deployments, for at least
up to 50,000<br>
>bidirectional<br>
>streams using multiple nodes running rtpproxy.
Available here<br>
><a href="https://github.com/sippy/rtp_cluster" rel="noreferrer" target="_blank">https://github.com/sippy/rtp_<wbr>cluster</a>.
You are also welcome to check our<br>
>talk last summer at the opensips devsummit in
Austin where we gave it<br>
>some<br>
>limelight.<br>
><br>
>So you are off by two orders of magnitude
roughly with regards to the<br>
>capacity. :)<br>
><br>
>And yes, we've been happily running large
deployments at AWS for at<br>
>least 6<br>
>years now.<br>
><br>
>Rodrigo, speaking about your original question,
I could not tell much<br>
>about<br>
>rtpengine due to a lack of practical experience
with it. But from what<br>
>I<br>
>read on its website it seems to be logical
continuation of the<br>
>mediaproxy<br>
>package packed with some cutting edge sexy
features.<br>
><br>
>In a nutshell rtpproxy and mediaproxy/rtpengine
are just two<br>
>independently<br>
>developed pieces of software, doing somewhat
similar function. What<br>
>would<br>
>work in your particular setting depends on your
requirements and<br>
>constraints.<br>
><br>
>Here at Sippy Labs we focus on stability,
compatibility and portability<br>
>for<br>
>a predominantly regular audio traffic.<br>
><br>
>We also have a test suite that check
compatibility of the latest<br>
>production<br>
>and development versions of the rtpproxy against
array of different SIP<br>
>engines, including Kamailio. <a href="https://travis-ci.org/sippy/voiptests" rel="noreferrer" target="_blank">https://travis-ci.org/sippy/vo<wbr>iptests</a><br>
><br>
>So with rtpproxy you are not locked in into
single SIP engine, you can<br>
>mix<br>
>and match to fit your particular goal.<br>
><br>
>And yes, last but not least, all our code is BSD
licensed, so you can<br>
>build<br>
>you proprietary box that uses it.<br>
><br>
>Hope it helps.<br>
><br>
>-Max<br>
><br>
>On Oct 17, 2016 11:33 AM, "Alex Balashov" <<a href="mailto:abalashov@evaristesys.com" target="_blank">abalashov@evaristesys.com</a>><br>
>wrote:<br>
><br>
>> On 10/17/2016 02:29 PM, Rodrigo Moreira
wrote:<br>
>><br>
>> What is difference between modules rtpproxy
and rtpengine?<br>
>>><br>
>><br>
>> rtpproxy is a userspace process which,
historically, has a relatively<br>
>> limited call throughput capacity (maybe a
few hundred calls), though<br>
>this<br>
>> might be addressed to some degree in
rtpproxy 2.0. Nevertheless, it<br>
>has<br>
>> been commonly used and well supported in
the *SER family for long<br>
>time.<br>
>><br>
>> RTPEngine is a newer initiative from
Sipwise, and uses kernel-mode<br>
>> forwarding to achieve close to on-the-wire
RTP forwarding speeds. It<br>
>can do<br>
>> 10,000+ concurrent bidirectional RTP
streams. It also has lots of<br>
>other<br>
>> features which can be useful in, for
example, running an RTP relay in<br>
>1:1<br>
>> NAT environments such as AWS, or in
enabling WebRTC.<br>
>><br>
>> However, it is a bit more complicated to
set up than vanilla<br>
>rtpproxy. Not<br>
>> much more, though.<br>
>><br>
>> -- Alex<br>
>><br>
>> --<br>
>> Alex Balashov | Principal | Evariste
Systems LLC<br>
>><br>
>> Tel: <a href="tel:%2B1-706-510-6800" value="+17065106800" target="_blank">+1-706-510-6800</a>
(direct) / <a href="tel:%2B1-800-250-5920" value="+18002505920" target="_blank">+1-800-250-5920</a>
(toll-free)<br>
>> Web: <a href="http://www.evaristesys.com/" rel="noreferrer" target="_blank">http://www.evaristesys.com/</a>,
<a href="http://www.csrpswitch.com/" rel="noreferrer" target="_blank">http://www.csrpswitch.com/</a><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> SIP Express Router (SER) and Kamailio
(OpenSER) - sr-users mailing<br>
>list<br>
>> <a href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a><br>
>> <a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">http://lists.sip-router.org/cg<wbr>i-bin/mailman/listinfo/sr-user<wbr>s</a><br>
>><br>
><br>
><br>
</div>
</div>
>-----------------------------<wbr>------------------------------<wbr>-------------<br>
<span>><br>
>_____________________________<wbr>__________________<br>
>SIP Express Router (SER) and Kamailio (OpenSER) -
sr-users mailing list<br>
><a href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a><br>
><a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">http://lists.sip-router.org/c<wbr>gi-bin/mailman/listinfo/sr-use<wbr>rs</a><br>
<br>
<br>
</span>-- Alex<br>
<br>
--<br>
Principal, Evariste Systems LLC (<a href="http://www.evaristesys.com" rel="noreferrer" target="_blank">www.evaristesys.com</a>)<br>
<br>
Sent from my Google Nexus.<br>
<div class="m_8792476622718572238HOEnZb">
<div class="m_8792476622718572238h5"><br>
<br>
______________________________<wbr>_________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) -
sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org" target="_blank">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" rel="noreferrer" target="_blank">http://lists.sip-router.org/cg<wbr>i-bin/mailman/listinfo/sr-user<wbr>s</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div></div></div></div></blockquote></div></div></div></blockquote></div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><br></div></div>
</div></div>