Fw: [Serusers] mediaproxy <-> rtpproxy

[Andrei Pelinescu-Onciul]

On Jul 23, 2004 at 09:54, dhiraj.2.bhuyan at bt.com <dhiraj.2.bhuyan at bt.com> wrote:
> Having used both rtpproxy and mediaproxy for quite sometime, here's my bits -
> 
> (NOTE - I used rtpproxy a few months back - and a few changes might have occured during these few months - so some of my comments may be inaccurate).

You probably used the version in stable.

> 
> 1. When I used rtporoxy a few months back, it would not allow chaining two or more rtpproxies and I had to hack the code to make it work that way. To me this is a very important feature. If you are talking of a telco grade VoIP product, having control over the RTP stream is very very important - legal interception for example (I am sure one day our regulatory bodies or the government will force some requirement on this), prevent terminating SIP session and yet continuing the RTP session, privacy etc. And the only way you can have control over the RTP stream is by forcing it go via your rtpproxy/mediaproxy. So I think rtpproxy/mediaproxy has a purpose beyond the nathelper functionality. Mediaproxy can do that already. I am not sure of what changes have happened since I last used rtpproxy - but if this feature is still missing, it will be great to have this feature included.

Yes, it can. You might need the 'f' or 'a' flags or both (I'm not sure
what exactly you are trying to do).
By default nathelper tries to avoid rtpproxy chains, because they are
very bad for nat traversal.

> 
> 2. Loadbalancing is important - particularly if you are thinking of proxing hundreds of calls at any instant. Mediaproxy gives this feature. I would like to see this in rtpproxy.

If you are talking about bandwidth usage I agree, but if you are talking
about cpu load, hundreds of calls are not a problem for rtpproxy.
> 
> 3. While using rtpproxy, when you terminate a call, SER does not send a message to the rtpproxy to terminate the rtp-stream associated with that call. Rather, rtpproxy sits there waiting and eventually times out. This is not good - there should be a tighter control. 

Yes, it does (unforce_rtp_proxy present in 0.8.14 nathelper, or unstable
version both of which work also with 0.8.12).
> 
> 4. rtpproxy is written in C. I like it - maybe because I am a bit more familiar with C. mediaproxy is written in python, and that makes me a bit uncomfortable about performance issues - although I have seen some earlier posting saying that the performance difference isn't much. But I can't say much on this until I do my own testing.
> 



Andrei