This must be an incredibly dumb question, but why would anyone ever use mediaproxy over rtpproxy?
If one is written in Python and one in C, it seems to me that the performance and scalability makes the choice of rtpproxy a no-brainer.
What benefit is there to using mediaproxy? More features and capabilities, ease of configuration perhaps?
Alex Balashov writes:
alex,
mediaproxy 2.0 is using linux kernel (not python code) to relay media packets and the claim is close to wire speed performance.
What benefit is there to using mediaproxy? More features and capabilities, ease of configuration perhaps?
mediaproxy is easy to use and set up. i don't have experience with rtpproxy.
unfortunately i just discovered that there may be a serious problem with mediaproxy 2.0 that was not there in mediaproxy 1.9. looks like mediaproxy 2.0 does not allow nated ua1 behind one mediaproxy to talk to nated ua2 behind another mediaproxy. dead lock happens and both mediaproxies are waiting packets from each other and don't forward packets that they have received from their uas.
so far i have not got any response to this from the developers.
-- juha
Juha Heinanen wrote:
mediaproxy 2.0 is using linux kernel (not python code) to relay media packets and the claim is close to wire speed performance.
Ah, I see. I was following some outdated information on this issue from Flavio's book.
How does it use the kernel? Some sort of kernel-side module that has plumbing into the IP routing/forwarding subsystem? Or some sort of ALG module with hooks?
Juha Heinanen wrote:
Do you have any perspective on how this performs compared to various high-end commercial SBCs?
I imagine rather favourably, especially since many of them are embedded systems built on Linux.
Juha Heinanen wrote:
Some of them do have ASIC-driven media processing. But many don't, and are actually just glorified PC hardware.
-
Alex Balashov -
jh＠tutpro.com