[SR-Users] RTPProxy

Maxim Sobolev sobomax at sippysoft.com
Wed Oct 19 16:30:16 CEST 2016


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 <miconda at gmail.com
> wrote:

> 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 <abalashov at evaristesys.com
> > wrote:
>
>> 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 at sippysoft.com>
>> wrote:
>> >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" <abalashov at evaristesys.com>
>> >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 at 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
>> >sr-users at 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 at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20161019/b6abd7de/attachment.html>


More information about the sr-users mailing list