[SR-Users] limiting concurrent calls with dialog module

[Andreas Granig]

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 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
> 
> _______________________________________________
> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20111010/f5b2beb6/attachment.pgp>