[SR-Users] limiting concurrent calls with dialog module

[Alex Balashov]

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