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).
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.
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.
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.
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.
Dhiraj Bhuyan Network Security Specialist, BT Exact Business Assurance Solutions
Tel: +44 1473 643932 Mob: +44 7962 012145 Email: dhiraj.2.bhuyan@bt.com
-----Original Message----- From: serusers-bounces@iptel.org [mailto:serusers-bounces@lists.iptel.org]On Behalf Of Atle Samuelsen Sent: 23 July 2004 07:21 To: Gustavo Russo Cc: serusers@lists.iptel.org Subject: Re: Fw: [Serusers] mediaproxy <-> rtpproxy
Both work :-)
- Atle
* Gustavo Russo grusso@netex.com.ar [040723 01:15]:
Arne :
Several times many people on this list and once myself too, made a similar question, in every case nobody answered.
It seems that due to the copyright discussion between nathelper and mediaproxy, many listers are afraid of beginning a flame war by comparing the two.
Regards, Gustavo Russo
----- Original Message ----- From: "Arne Scheffer" arne.scheffer@ritstele.com To: serusers@lists.iptel.org Sent: Thursday, July 22, 2004 6:06 PM Subject: [Serusers] mediaproxy <-> rtpproxy
Hello all,
Can anyone give an indication of what direction the project is moving with mediaproxy and rtpproxy ?
From the mediaproxy readme I understand the advantages of being able to
have multiple mediaproxies. (sonds good)
On the mailing list I have found limited questions on the mediaproxy so I get the impression it is not being used a lot (yet) ?
I have installed it on a box with the latest CVS head.
I am experencing may problems with diffent NAT types, some work (eg e-tech ADSL modem with NAT) but others don't (linux debian with iptables).
What is the most compatible solution at present ?
thanks in advance, Arne.
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________ Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
On Jul 23, 2004 at 09:54, dhiraj.2.bhuyan@bt.com dhiraj.2.bhuyan@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.
- 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.
- 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.
- 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).
- 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