Proxy de alto rendimiento para transmisiones RTP que puede funcionar junto con Sippy B2BUA, Kamailio, OpenSIPS y SER

Comparte en redes sociales

Dentro de la seguridad informática la disponibilidad es un factor muy importante que normalmente se le suele menospreciar. Entendemos por disponibilidad a la garantía de que los usuarios autorizados puedan acceder a la información y recursos de red cuando los necesiten. La disponibilidad es un factor imprescindible un sistema de telefonía VoIP.

RTPproxy es un software proxy extremadamente confiable y razonablemente de alto rendimiento para transmisiones RTP que puede funcionar junto con OpenSIPS , Kamailio o Sippy B2BUA. Originalmente creado para manejar escenarios NAT, también puede actuar como un relé genérico de datagramas en tiempo real, así como sesiones de protocolo en tiempo real (RTP) entre redes IPv4 e IPv6.

RTPproxy admite muchas características avanzadas y es controlable a través de una multitud de protocolos de Capa 4, incluidos Unix Domain, UDP, UDPv6, TCP y TCPv6. El software permite construir redes SIP distribuidas y escalables. El módulo rtpproxy incluido en el software OpenSIPS o Kamailio SIP Proxy permite usar múltiples instancias RTPproxy que se ejecutan en máquinas remotas con fines de tolerancia a fallas y equilibrio de carga. El clúster avanzado de alta capacidad y el equilibrio de carga están disponibles mediante el uso de middleware RTP Cluster . El software también admite MOH/inyección de medios pregrabados, retransmisión de video y grabación de sesiones a un archivo local o escuchas remotas UDP. Además, pone a disposición una variedad de contadores de sesión en tiempo real o casi en tiempo real, tanto por sesión como por instancia.

Rtpproxy han sido diseñados por Maxim Sobolev y ahora está siendo mantenida por la forma activa de Sippy Software, Inc . Con la gran ayuda de numerosos contribuyentes comunitarios, tanto privados como institucionales. Sin mencionar el ejército de robots despachados con gracia a la necesidad por el CI de Travis. La idea original ha inspirado e influido directamente en multitud de implementaciones independientes, que incluyen, entre otras, Mediaproxy, erlrtpproxy y más recientemente RTP Engine, cada proyecto se centra en su propia área del vasto espacio funcional.

Como funciona

Este proxy funciona de la siguiente manera:

Cuando el controlador SIP, ya sea proxy o B2BUA, recibe la solicitud INVITE, extrae la identificación de la llamada y la comunica al proxy a través del canal de control. Proxy busca una sesión existente con dicha identificación, si la sesión existe, devuelve el puerto UDP para esa sesión, si no, crea una nueva sesión, se une a un primer par de puertos UDP seleccionados al azar disponibles y devuelve el número del primer puerto. Después de recibir la respuesta del proxy, el controlador SIP reemplaza los medios ip: puerto en el SDP para apuntar al proxy y reenvía la solicitud como de costumbre;
cuando el Controlador SIP recibe una respuesta SIP no negativa con SDP, nuevamente extrae la identificación de la llamada junto con las etiquetas de sesión y la comunica al proxy. En este caso, el proxy no asigna una nueva sesión si no existe, sino que simplemente realiza una búsqueda entre las sesiones existentes y devuelve un número de puerto si se encuentra la sesión o un código de error que indica que no hay sesión con dicha identificación . Después de recibir una respuesta positiva del proxy, el controlador SIP reemplaza los medios ip: puerto en la respuesta SIP para apuntar al proxy y reenvía la respuesta como de costumbre;
después de que se ha creado la sesión, el proxy escucha en el puerto que ha asignado para esa sesión y espera recibir al menos un paquete UDP de cada una de las dos partes que participan en la llamada. Una vez que se recibe dicho paquete, el proxy llena una de las dos estructuras ip: port asociadas con cada llamada con la fuente ip: puerto de ese paquete. Cuando se completan ambas estructuras, el proxy comienza a retransmitir paquetes UDP entre las partes;
el proxy rastrea el tiempo de inactividad para cada una de las sesiones existentes (es decir, el tiempo dentro del cual no se retransmitieron paquetes), y limpia automáticamente las sesiones cuyos tiempos de inactividad exceden el valor especificado en el tiempo de compilación (60 segundos por defecto).