Hi Maxim, 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! My sincere apologies... -- Alex On October 19, 2016 3:32:24 AM EDT, Maxim Sobolev <sobomax(a)sippysoft.com> wrote: -- Alex -- Principal, Evariste Systems LLC (www.evaristesys.com) Sent from my Google Nexus.

Hello Maxim, given the discussion here, I would like to get some updates for myself regarding 2.0 in terms of capacity and other stuff. 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. 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? 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. Cheers, Daniel On 19/10/16 09:46, Maxim Sobolev wrote: -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com

Arsen, there is no readily-made solution with rtpproxy unfortunately for that. Some time around 1.0 times circa 2007-2009, somebody submitted a very rough patch to implement master/hot-standby scenario, but the patch was not production-ready back then and the contributor was not available to refine it further, so it ended up stashed somewhere on the branch in git. I'd be happy to say we are working on that, but our resources are limited and priority is to get features like SRTP, trans-coding and video support. As always, pull requests/patches are welcome. With 2.x code is much more modular, so it should be easier to get something like that working. -Max On Wed, Oct 19, 2016 at 3:55 AM, Arsen <arsen.semionov(a)gmail.com> wrote:

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. 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. 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. Please don't hesitate to ask if something is unclear or if you have more questions. Thanks! -Max *) Sometimes I get a feeling that there are too many to chose from these days, but oh well... :) On Wed, Oct 19, 2016 at 1:19 AM, Daniel-Constantin Mierla &lt;miconda(a)gmail.com > Hello Maxim, > given the discussion here, I would like to get some updates for myself > regarding 2.0 in terms of capacity and other stuff. > > 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. > > 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? > > 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. > > Cheers, > Daniel > > > On 19/10/16 09:46, Maxim Sobolev wrote: > > Alex, no problem. Nobody knows everything. :) > > -Max > > On Wed, Oct 19, 2016 at 12:35 AM, Alex Balashov &lt;abalashov(a)evaristesys.com > > >> Hi Maxim, >> >> 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! >> >> My sincere apologies... >> >> -- Alex >> >> >> On October 19, 2016 3:32:24 AM EDT, Maxim Sobolev &lt;sobomax(a)sippysoft.com&gt; >>> >Alex, with all due respect, things you said about rtpproxy capacity is >> >somewhat outdated and misleading. We have some nodes in the field, that >> >handle 5,000-6,000 rtp sessions in peak. Those are running 6 rtpproxy >> >instances, 1,000 sessions each. 2-3 year old CPUs, 12 cores in total. >> > >> >We also have an open source solution called rtp_cluster, which allows >> >building larger scale deployments, for at least up to 50,000 >> >bidirectional >> >streams using multiple nodes running rtpproxy. Available here >> >https://github.com/sippy/rtp_cluster. You are also welcome to check our >> >talk last summer at the opensips devsummit in Austin where we gave it >> >some >> >limelight. >> > >> >So you are off by two orders of magnitude roughly with regards to the >> >capacity. :) >> > >> >And yes, we've been happily running large deployments at AWS for at >> >least 6 >> >years now. >> > >> >Rodrigo, speaking about your original question, I could not tell much >> >about >> >rtpengine due to a lack of practical experience with it. But from what >> >I >> >read on its website it seems to be logical continuation of the >> >mediaproxy >> >package packed with some cutting edge sexy features. >> > >> >In a nutshell rtpproxy and mediaproxy/rtpengine are just two >> >independently >> >developed pieces of software, doing somewhat similar function. What >> >would >> >work in your particular setting depends on your requirements and >> >constraints. >> > >> >Here at Sippy Labs we focus on stability, compatibility and portability >> >for >> >a predominantly regular audio traffic. >> > >> >We also have a test suite that check compatibility of the latest >> >production >> >and development versions of the rtpproxy against array of different SIP >> >engines, including Kamailio. https://travis-ci.org/sippy/voiptests >> > >> >So with rtpproxy you are not locked in into single SIP engine, you can >> >mix >> >and match to fit your particular goal. >> > >> >And yes, last but not least, all our code is BSD licensed, so you can >> >build >> >you proprietary box that uses it. >> > >> >Hope it helps. >> > >> >-Max >> > >> >On Oct 17, 2016 11:33 AM, "Alex Balashov" &lt;abalashov(a)evaristesys.com&gt; >> >wrote: >> > >> >> On 10/17/2016 02:29 PM, Rodrigo Moreira wrote: >> >> >> >> What is difference between modules rtpproxy and rtpengine? >> >>> >> >> >> >> rtpproxy is a userspace process which, historically, has a relatively >> >> limited call throughput capacity (maybe a few hundred calls), though >> >this >> >> might be addressed to some degree in rtpproxy 2.0. Nevertheless, it >> >has >> >> been commonly used and well supported in the *SER family for long >> >time. >> >> >> >> RTPEngine is a newer initiative from Sipwise, and uses kernel-mode >> >> forwarding to achieve close to on-the-wire RTP forwarding speeds. It >> >can do >> >> 10,000+ concurrent bidirectional RTP streams. It also has lots of >> >other >> >> features which can be useful in, for example, running an RTP relay in >> >1:1 >> >> NAT environments such as AWS, or in enabling WebRTC. >> >> >> >> However, it is a bit more complicated to set up than vanilla >> >rtpproxy. Not >> >> much more, though. >> >> >> >> -- Alex >> >> >> >> -- >> >> Alex Balashov | Principal | Evariste Systems LLC >> >> >> >> Tel: +1-706-510-6800 (direct) / +1-800-250-5920 (toll-free) >> >> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/ >> >> >> >> _______________________________________________ >> >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing >> >list >> >> sr-users(a)lists.sip-router.org >> >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> >> >> > >> > >> >------------------------------------------------------------------------ >> > >> >_______________________________________________ >> >SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >> &gt;sr-users(a)lists.sip-router.org >> >http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> >> >> -- Alex >> >> -- >> Principal, Evariste Systems LLC (www.evaristesys.com) >> >> Sent from my Google Nexus. >> >> >> _______________________________________________ >> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list >> sr-users(a)lists.sip-router.org >> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users >> > > > >

Hello, thanks for all those details, very useful ... To be clear -- the issue of using high cpu on idle (no active calls) was with rtpproxy v1.2 on a centos (iirc, v6), not with rtpproxy 2.0. On debian, same version of rtpproxy was not exposing this. I was just curios to see if anyone else saw it ... might have been just that system... Cheers, Daniel On 19/10/16 20:00, Maxim Sobolev wrote: -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio Advanced Training, Berlin, Oct 24-26, 2016 - http://www.asipto.com