Hi,
Someone does need to do a study to see if kernel vs. userspace forwarding really makes that much of a difference, though. I suspect that although it does make a difference, it is not nearly as much of a difference as is commonly thought.
We did a benchmark (only cpu usage for now) comparing the standard rtpproxy with mediaproxy-ng, a proprietary implementation of Sipwise (implemented as iptables module based on the mediaproxy dispatcher protocol). The results should be pretty equal for mediaproxy2 and iptrtpproxy as well, although I don't know anything about their design.
http://pub.sipwise.com/OpenSER.rtpproxy.benchmark.2009.06.24.pdf
The machine is a Dual-CPU Intel(R) Xeon(TM) CPU 2.80GHz with 2GB of RAM. Test-Setup is done with sipp (rtp is sent via pre-recorded pcap and echoed via "-rtp-echo" option on UAS).
Some observations we found:
- rtpproxy seems to not take advantage of SMP - jitter is reduced in mediaproxy-ng compared to rtpproxy because socket polling is eliminated in kernel - delay is reduced in kernel-space due to elimination of context switching - the peaks in mediaproxy-ng are a result of the mediaproxy-ng design (relaying is done in user-space until all ip/port information is available by receiving rtp packets from both sides, besides some other processing like packet inspection etc. [although cpu usage can be lowered even more by further optimizing the userspace part])
Andreas