RTPmedia managers: rtpengine vs rtpproxy complete quick info

The idea is to permanently listen internally on the UDP port or on a local socket, controlling SIP signals messages. That is to say to control the flow of information and to where the answers are sent by means of these commands. Since these signals do not go directly to the SIP service but to the RTP NAT software, then the SIP service can tell the RTP service "give me that media stream, I know what to do" after sending it internally (to some other service) and receive an answer and then deliver it again and say "here is the flow response, send it to that device".
The SIP service can tell the RTP service "give me that stream, I know what to do" after sending it internally (to some other service) and receive an answer and then deliver it again and say "here is the flow response, send it to that device".

For each media stream, it opens two pairs of UDP ports on the public interface in the range of 20000 and 40000 commonly, depending on which rtpmedia software is being used (rtpproxy/rtpengine), a pair on odd port numbers for media data, and a pair on the next even port number for metadata, for example, RTCP in the case of RTP streams. Each endpoint communicates with a pair for both endpoints (if you use rtpproxy) or a specific pair for both endpoints (if you use rtpengine) to avoid problems in determining where to send a packet.

So we have in this article, quickly:

1.   RTPProxy analized
2.   RTPengine analized
3.   Comparative table
4.   Debian/VenenuX Downloadable packages
5.   Conclusions 

1. RTP Proxy

RTPProxy was developed to enable VoIP SIP calls with NAT traversal also acting as an intermediary for RTP media streams. This software is the predecessor and base of both rtpengine and mediaproxy, works similar to rtpengine but more simplified and less dynamically, is the most used in light and simple deployments, its great advantage is simplicity and that it does not require major configuration changes more than if the ip publishes changes.

Simple but powerfully: It can be used in combination with a signaling element (SIP Proxy or SIP B2BUA) to build complex VoIP networks, optimize traffic flow, collect voice quality information, and so on. With more refined/complicated configuration it can perform several additional functions in RTP transmissions, including call recording, playback of pre-encrypted announcements, copying of transmissions in real time and re-framing of RTP payloads.

Simple and scalable: The RTPproxy supports remote control mode using ICE socket via UDP, allowing the construction of distributed and scalable VoIP SIP networks. The nathelper module included in the SIP Express Router (SER: OpenSIPS or Kamailio), as well as Sippy B2BUA allow the usage of multiple instances of RTPproxy running on remote machines for fault tolerance and load balancing purposes.

CONCLUSION for rptproxy: For little to medium sized environments with a single/couple of SIP/router services this is the choice, inclusively for complex setups with some tricks can be able to server in good way, also are available at Debian repositories (older version but here we offer packages at the end of the article)

2. RTP Engine

Media Relay (called rtpengine) is a software space-based packet redirector and/or routing at the operating system core, controlled by the SIP proxy. For each media stream (e.g., a voice and/or video stream), it maintains a pair of ports in the port number range of 30000 to 40000. When media streams are negotiated, rtpengine opens the ports in the user space (even if it works in the system/software space) and begins retransmitting the packets to the announced addresses (it can be back to endpoints or another internal service before delivering them to them).

Iptables NAT level: has the feature, if packets arrive from different source addresses than those announced in the SDP body of the SIP message, the source address is implicitly changed to the address from which the packets are received. Once the call has been established and the rtpengine has received media packets from both endpoints for this call, the media stream is pushed into the kernel and then handled by a custom iptables module to increase system performance and reduce media packet latency.

Kernel iptables level: this dynamic feature are provided through an iptables kernel level module with the destination space name RTPENGINE; yes! is a module that modifies iptables depending on the source and destination, making this system very dynamic, so you have to be careful: if you install additional firewall or packet filtering rules, it is imperative that this rule remains intact and stays in place. Otherwise, if the rule is removed from iptables, the kernel will not be able to forward the media packets and the forwarding will fall to the userspace service. Packets will continue to be forwarded normally, but performance will be much worse in these circumstances, which will be especially noticeable when many media streams are active at the same time.
CONCLUSION for rtpengine: Therefore using rtpengine is ideal for media controlling and streaming redirection for advanced levels also supports huge and granular configurations but it's quite complicated, each rtpengine service must be a dedicated server if there's more than one service and many iptables rules alongside those services.

3. Tabla comparativa

RTP media	PAtron	Devel	Load	Kam mod	A/V streams	SQL log	TP reenvio	version
RTPproxy	Sippy Software	C	delay/kamailio	rtpproxy	limitado	No	software	1.2.1/2009-10-19
Rtpengine	Sipwise	C +kernel	auto/interno	rtpengine	cualquiera	Si	kernel/user	2.1/2013-02-11
MediaProxy	AG Projects	python +kernel	auto/interno	mediaproxy	cualquiera	Si	kernel	2.5.2/2011-09-09
erlrtpproxy	Peter Lemenkov	erlang	delay/erlang	rtpproxy	limitado	No	no	sin stable version

Adicional todos tienen:

• Apagado gradual, que termina el servicio solo cuando todas las señales hayan finalizado
• Grabacion de medios, aunque inestable en rtpengine y mejorado en rtpproxy
• Soporte de ambas tipos de IP : IPv4, IPv6.
• Soporte de socket ICE de control: limitado en rtpproxy, completo en rtpengine.

4. Packages

A) RTPProxy:

In the case of rtpproxy in official Debian there an old version, and although there is an open request: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917456 explaining that it does not support NAT traversal with ip of advertise; but the response of debian is quite obtuse what is to be expected since many win-buntu's are the packagers now.

For those who want an updated and debianized rtpproxy correctly use from VenenuX the instructions here: https://build.opensuse.org/package/show/home:vegnuli:voip/rtpproxy and you can use it according to those instructions in Debian 7, 8 and 9. For Debian squeeze and lenny see venenux mail lists.

In Debian after install respective kamailio and rtpproxy (carefully, that repository already offers kamailio too), do that:

service rtpproxy stop
export ipext=1.2.3.4
export ipint=192.168.0.10
cat > /etc/default/rtpproxy << EOF
USER=rtpproxy
GROUP=rtpproxy
# The control socket.
# To listen on an UDP socket, uncomment this line:
CONTROL_SOCK=udp:127.0.0.1:7722
# Additional options that are passed to the daemon.
EXTRA_OPTS="-l $ipint -A $ipext -F -m 20000 -M 30000"
EOF
service rtpproxy start

By default in Debian and VenenuX the kamailio Open SIP server are configured to use rtpproxy in that default configuration.

B) RTPEngine

In the case of rtpengine has been a pain in official Debian due to its dependencies and issues with licensing and patents, are open the ITP as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916126 but progress is slow, the original project has the structure to build packages but there is no guarantee of quality integration with Debian in upgrades and obviously are less secure.

It is being packaged in VenenuX debianized rtpengine correctly with instructions here: https://build.opensuse.org/package/show/home:vegnuli:voip/rtpengine and can be used according to those instructions in Debian 7, 8 and 9. For Debian squeeze and lenny see venenux mail lists.

In Debian after install respective kamailio and rtpengine (carefully, that repository already offers kamailio too), do that:

service rtpengine stop

apt-get install module-assistant rtpengine-kernel-source

m-a install rptengine-kernel

cat > /etc/default/rtpengine-daemon << EOF
RUN_RTPENGINE=yes 

CONFIG_FILE=/etc/rtpengine/rtpengine.conf
PIDFILE=/run/rtpengine-daemon.pid
MANAGE_IPTABLES=yes
TABLE=0 

EOF

export ipext=1.2.3.4
export ipint=192.168.0.10
cp /etc/rptengine/rptengine.sample.conf /etc/rptengine/rptengine.conf

sed "/^[# ]*interface/cinterface = internal/$ipint;external/$ipext" -i /etc/rtpengine/rtpengine.conf

service rtpengine start

No changes any occurrence in kamailio.cfg of "rtpproxy" to "rtpengine" and the control sock line must be "modparam("rtpengine", "rtpengine_sock", "udp:localhost:22222")" configured to use rtpengine in that default configuration.

5. Conclusions

If you don't want complications, sure get rtpproxy, but if you need granular and special needs prepare to be brave and try the rtpengine.. for starter needs and mediane to common clusters be firts with rtpproxy.