Alex,
We use our own kernel-based mediaproxy in our systems, so I can't tell much about rtpproxy, beside that our ngcp-mediaproxy-ng uses the same control protocol (or a basic sub-set of it, e.g. no recording or stream forking etc), so you can use it as drop-in replacement of rtpproxy.
See http://deb.sipwise.com/spce/2.2/pool/main/n/ngcp-mediaproxy-ng/ , it's part of the open-source sip:provider CE system (http://www.sipwise.com/products/spce/), which uses kamailio, sems and mediaproxy-ng for SIP and RTP.
Andreas
On 10/10/2011 09:37 PM, Alex Balashov wrote:
Andreas,
Good to know. These tens of thousands of concurrent calls are bridged signaling-only, I assume? What about RTP relay performance?
One of the reasons I've always liked rtpproxy is that it forwards quite a respectable number of streams concurrently, for a userspace process, and is easy to horizontally scale by just adding more rtpproxies to the set, and/or binding additional instances to additional CPU cores.
-- This message was painstakingly thumbed out on my mobile, so apologies for brevity, errors, and general sloppiness.
Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
On Oct 10, 2011, at 3:34 PM, Andreas Granig agranig@sipwise.com wrote:
Alex,
We've had huge performance and stability issues with SEMS in the past as well, but together with the Frafos guys we've brought version 1.4 with thread-pool enabled into a stable state for large-scale deployments.
We're running it in production in various deployments with thousands of parallel calls without issues for months now. Load tests have shown that we can run it with >100 caps and tens of thousands of parallel calls over several days without significant load or cpu usage.
Andreas
On 10/10/2011 08:56 PM, Alex Balashov wrote:
In theory, this sounds appealing. But we have had a lot of problems with SEMS performance and stability with a large number of calls. We are rather fond of the proxy-based approach because it works, and works well.
-- This message was painstakingly thumbed out on my mobile, so apologies for brevity, errors, and general sloppiness.
Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
On Oct 10, 2011, at 2:03 PM, Juha Heinanen jh@tutpro.com wrote:
Alex Balashov writes:
Stateless replies have that name for a reason; they lack state. They don't trigger any TM callbacks that the dialog module can latch onto. So, figuring out how to remove a dialog to which a stateless final failure reply has been sent is actually quite difficult, and requires significant architectural changes.
one can always use sems to limit number of simultaneous calls (see cc_pcalls sbc module).
lets face it: if you want to be dialog aware, it is better to do it with right tool (= sbc) than to try to twist sip proxy to do something that it is not by definition good for.
once you have bitten the bullet, you can easily handle rtp proxying, topology hiding, reliable accounting, anonymity, etc. with one single tool.
-- juha
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
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