23 Jul
2004
23 Jul
'04
5:52 a.m.
On Jul 23, 2004 at 09:54, dhiraj.2.bhuyan(a)bt.com <dhiraj.2.bhuyan(a)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