10 Oct
2011
10 Oct
'11
4 p.m.
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(a)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:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users 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(a)tutpro.com> wrote:
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users 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(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users