NAT traversal signal: rtpproxy vs rtpengine – que usar

NAT traversal signal y kamailio

La idea es la escucha permanente internamente en el puerto UDP o en un socket local, los mensajes de control para las señales SIP. Es decir controlar el flujo de informacion y hacia donde se envia la respuestas por medio de estos comandos. Dado que estas señales no llegan directo al servicio SIP sino al software RTP NAT, entonces el servicio SIP puede decirle al servicio RTP “dame ese flujo, yo se que hacer” despues de enviarlo internamente y recibir una respuesta lo vuelve entregar y decir “aqui esta el flujo respuesta, envialo a tal dispositivo”.




— el servicio SIP puede decirle al servicio RTP “dame ese flujo, yo se que hacer” despues de enviarlo internamente y recibir una respuesta lo vuelve entregar y decir “aqui esta el flujo respuesta, envialo a tal dispositivo”.
Para cada secuencia de medios, abre dos pares de puertos UDP en la interfaz pública en el rango de 20000 y 40000 por defecto dependiendo de que software rtpmedia se este usando (rtpproxy/rtpengine), un par en números de puerto impares para los datos de medios, y un par en el siguiente número de puerto par para los metadatos, por ejemplo, RTCP en el caso de secuencias RTP. Cada punto final se comunica con un par para ambos puntos finales (si emplea rtpproxy) o un par especifico para estos (si emplea rtpengine) para evitar problemas a la hora de determinar a dónde enviar un paquete.
Tenemos entonces:

1. RTPProxy resumido
2. RTPengine resumido
3. Tabla comparativa
4. Paquetes para descargar

1. RTP Proxy

RTPProxy fue desarrollado para habilitar llamadas VoIP SIP con NAT actuando como un intermediario para los flujos RTP. Este software es el predecesor y base de tanto rtpengine asi como de mediaproxy, funciona similar a rtpengine pero mas simplificado, es el mayormente usado en despliegues livianos y simples, su gran ventaja es que no requiere mayores cambios de configuracion mas que si la ip publica cambia.
Se puede utilizar en combinación con un elemento de señalización (SIP Proxy o SIP B2BUA) para construir redes VoIP complejas, optimizar el flujo de tráfico, recopilar información de calidad de voz, etc. Puede realizar varias funciones adicionales en transmisiones RTP, incluyendo grabación de llamadas, reproducción de anuncios pre-codificados, copia de transmisiones en tiempo real y re-encuadre de cargas útiles RTP.
El RTPproxy soporta algunas características avanzadas, como el modo de control remoto (usando socket ICE via UDP), permitiendo la construcción de redes SIP VoIP distribuidas y escalables. El módulo nathelper incluido en el SIP Express Router (SER: OpenSIPS o Kamailio), así como Sippy B2BUA permiten el uso de múltiples instancias de RTPproxy que se ejecutan en máquinas remotas con fines de tolerancia a fallos y equilibrio de carga.
CONCLUSION: Para entornos medianos con un solo servicio SIP/router esta es la eleccion, inclusive esta en debian (version vieja aun)

2. RTP Engine

El Media Relay (llamado rtpengine) es un redireccionador/reenviador de paquetes basado espacio de software del núcleo del sistema operativo, y controlado por el proxy SIP. Para cada flujo de medios (por ejemplo, un flujo de voz y/o vídeo), mantiene un par de puertos en el rango de números de puerto de 30000 a 40000. Cuando se negocian los flujos de medios, rtpengine abre los puertos en el espacio de usuario (aunque trabaje en el espacio de el sistema/software) y comienza a retransmitir los paquetes a las direcciones anunciadas (puede ser de nuevo a “endpoints” o a otro servicio interno antes de entregarlos a estos).
Usando NAT: Si los paquetes llegan desde direcciones de origen diferentes a las anunciadas en el cuerpo SDP del mensaje SIP (por ejemplo, en el caso de NAT), la dirección de origen se cambia implícitamente por la dirección de la que se reciben los paquetes. Una vez que se ha establecido la llamada y el rtpengine ha recibido paquetes de medios de ambos endpoints para esta llamada, el flujo de medios es empujado al kernel y luego es manejado por un módulo iptables personalizado de Sipwise para aumentar el rendimiento del sistema y reducir la latencia de los paquetes de medios.
Kernel e iptables: La parte interna del kernel del rtpengine se facilita a través de un módulo iptables con el nombre de destino RTPENGINE; si! es un modulo que modifica iptables dependiendo del origen y destino, haciendo este sistema muy dinamico, por lo que se tiene delicado cuidado: si se instalan reglas adicionales de cortafuegos o de filtrado de paquetes, es imperativo que esta regla permanezca intacta y se mantenga en su lugar. De lo contrario, si la regla se elimina de iptables, el núcleo no podrá reenviar los paquetes de medios y el reenvío recaerá en el servicio del espacio de usuario. Los paquetes seguirán siendo reenviados normalmente, pero el rendimiento será mucho peor en esas circunstancias, lo que se notará especialmente cuando muchos flujos de medios estén activos al mismo tiempo.
CONCLUSION: Por ende usar rtpengine es para niveles avanzados y de mucho cuidado!

Tabla comparativa

RTP media	Patrocinador	Programado	Balanceo carga	En kamailio	A/V streams	SQL log	TP reenvio	version
RTPproxy	Sippy Software	C	delegado/kamailio	rtpproxy	limitado	No	software	1.2.1/2009-10-19
Rtpengine	Sipwise	C+kernel	automatico/interno	rtpengine	cualquiera	Si	kernel/user	2.1/2013-02-11
MediaProxy	AG Projects	python+kernel	automatico/interno	mediaproxy	cualquiera	Si	kernel	2.5.2/2011-09-09
erlrtpproxy	Peter Lemenkov	erlang	delegado/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.

Paquetes

A) RTPProxy:
En el caso de rtpproxy en Debian oficial esta uan version vieja, y aunque hay un request abierto: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=917456 explicando que no soporta NAT traversal con ip de advertise la respuesta de debian es bastante obtusa lo que es de esperar ya que muchos winbunteros son los empaquetadores ahora.
Para los que deseen un rtpproxy actualizado y debianizado correctamente usar: https://build.opensuse.org/package/show/home:vegnuli:voip/rtpproxy
B) RTPEngine
En el caso de rtpengine ha sidfo un dolor en Debian oficial debido a sus dependencias y el tema de licenciamiento y patentes, esta abierto el ITP como https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916126 pero el avance es lento, el proyecto original tiene la estructura para construir paquetes pero no se garantiza la integracion de calidad con Debian en actualizaciones y menos seguridad. Se esta empaquetando en VenenuX en https://build.opensuse.org/package/show/home:vegnuli:voip/rtpengine tambien