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@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@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@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@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@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@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users



--
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sales@sippysoft.com
Skype: SippySoft


_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

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