Hi,
On 04/02/2013 05:14 PM, Dani Popa wrote:
as far as i know, mediaproxy by AG Projects it's
also kernel based
forwarding, so i don't understand what is the reasons to use another
mediaproxy let's say mediaproxy-ng.
Well, mediaproxy-ng development has started like 6 years ago as a
replacement for mediaproxy (which at that point was python based and
didn't do any kernel stuff) in our commercial solutions. This is the
reason why there is still the "tcp" option in mediaproxy-ng to support
the old control protocol used by kamailio's "mediaproxy" module. Around
2-3 years ago we made it open source along with the sip:provider CE
appliance.
The mediaproxy project has since evolved also to a kernel based project,
and afaik the control protocol has changed as well, so both projects are
not compatible anymore. I can't tell for sure the status of mediaproxy
as we didn't use it since years. They are more opensips focused, but it
probably works with kamailio as well (don't know though).
Since we switched to rtpproxy control protocol, it's a drop-in
replacement for the rtpproxy project, which is pure user-space. There is
some other rtpproxy control protocol compatible media replay
(ipt_rtpproxy?) which I haven't used myself either.
So all in all, it's just about diversity, choose whatever suits you
best. The only thing I can say for that matter is that Sipwise actively
implements new features on top of mediaproxy-ng (with the new
rtpproxy-ng kamailio module using a dictionary-based control protocol,
which makes extending the protocol much easier in the future, and which
passes back and forth the whole SDP body instead of just passing in some
parameters and getting back out a new IP and port, which allows for
advanced stuff like ICE manipulation, and in the future also transcoding
etc).
Andreas