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 <agra...@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 <j...@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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ 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
