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