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
