Re: [Serusers] deference between rtpproxy and mediaproxy

I don't think that's entirely fair. We've seen deployments of rtpproxy with several thousand streams (compared to a few dozen on mediaproxy). The biggest problem, of course, becomes that then you're into the gigabits of bandwidth realm.... which gets pricey. The biggest differences between mediaproxy and rtpproxy: mediaproxy: -written in python -uses DNS srv records to allow you to distribute the load onto multuple servers regionally, geographically, etc. -has a nifty web interface to let you look at statistics of the server (ongoing streams, etc). -can't handle a WHOLE lot of streams per box rtpproxy: -written in C -doesn't handle distribution of load (for this, you'd need to do some tricks with load balancing on your own -- local, or geographical load balancing. Not easy, but possible). -doesn't have any sort of useful interface to gather information about the server and what it's doing -handles a LOT of streams on a decently-powered box There are limits to both, of course. You're best off limiting the number of users who require the use of mediaproxy or rtpproxy with some effective coding and standards (in reality, the ONLY people who should be using it are people who are connecting via a symmetric NAT) to avoid bottlenecks. Like ANY thing else in the massive deployment world, there is always a bottleneck in any SIP scenario, but also like any other massive deployment, you need to analyse your particular environment and decide what works best for you to minimise the bottlenecks using good network design, not just good software. N. On Sun, 10 Sep 2006 18:26:57 -0400, Script Head wrote ----------------------------------------------------------------------- Do you Yahoo!?