[NO PUBLICAR] Liberación del media path de forma muy controlada en entornos de SIP/RTP

Muy buenas !

SDP, RTP Path  – de esto es lo lo que os queremos hablar hoy.

¿Por qué nos debería preocupar/interesar?

Si has llegado aquí, seguramente es o bien que te interesan estos temas, o bien una necesidad específica de hacer que el famoso  SIP/RTP trapezoid se cumpla de verdad verdadera:

Con dicha ilustración, se ve claramente que la principal ventaja es de calidad perceptible, si conectamos directamente a caller/callee de forma directa a nivel de media, nos ahorramos latencias, riesgos de packet loss / jitter, entre otras ventajas que aporta dicha cercanía.

Y, por otra parte, dependiendo del elemento / proyecto en el que queramos aplicar esto, es posible que nos ahorremos mucha computación y carga, si el elemento del que vamos a liberar el media no está preparando específicamente para ello, la ventaja pasa a ser casi «mandatory».

En este post no vamos a hablar de ICE (ya lo hicimos en su momento), nos queremos centrar más bien en el elemento que expuesto/frontera (SBC) hacia la parte externa.

Este tipo de manipulaciones a SDP’s que vamos a comentar la verdad es que las aplicamos mucho, sobre todo ahora que estamos trabajando para cada vez más operadores/telcos, cada una de ellas con sus necesidades | redes mpls/X | entorno híbrido Y o lo que tengan.

Presentando personajes: El B2BUA – aKa dialog breaker

Como os comentábamos, si nos centramos en la parte IP PBX, el concepto clásico de B2BUA es el que aplica prácticamente siempre.

Un diálogo SIP desde el endpoint hasta la parte IP PBX, quien a su vez lanza esa segunda pata en un dialogo totalmente independiente (B2BUA), dónde no siempre lo que sucede en uno está trasladado de forma línea hacia otro.

Es decir, si lo ilustramos fácilmente:

 

Este elemento IP PBX es generalmente dónde más configuración se realiza y dónde la lógica de negocio está más alineada con la red en si. Es decir, aquí es dónde es perfectamente posible agrupar por sede/red dónde se sabe que el ancho de banda es X o Y , a modo de ejemplo. A parte de todas las otras áreas habituales de configuración.

A lo cual, si añadimos la clásica salida a la PSTN vía un carrier, con el componente de SBC que indicábamos:

En este esquema lo hemos ilustrado como SBC que actúa de proxy (con topo hiding, lo que queramos), pero podemos hacerlo también en B2BUA.

 

El objetivo

Lo dicho en el título: queremos poder garantizar que nos quitamos del media path y conectamos directamente el SBC con el endpoint:

Las reglas del juego

Las reglas del juego las marcan los RFC’s, eso está claro, para bien o para mal. Tampoco queremos entrar en el desmadre o discusiones, para eso ya le tenemos a IBC 😉 , pero lo que está claro es que al menos para lo que es negociar la sesión, se ha liado bastante la cosa :

Bromas a parte, lo más importante que tendríamos que tener cercano:

1. Que Bob hable un codec no significa que Alice hablará el mismo.
2. Que Alice lance un invite con un sdp ofreciendo codecs en un determinado orden tampoco garantiza que, aunque los soporte el otro extremo todos, se acabe hablando el que prefiera Alice, de hecho, tampoco el de Bob (ver punto 1 😉 ) jiji.

Y esto es así, por mucho que no nos guste. Tampoco http gustaba al principio (AJAX …) y hoy por hoy la world wide web es la reina en sí misma.

Objetivos de la partida

Queremos hacer que el SIP Endpoint hable directamente con el SBC siempre intentando que lo haga en el codec que preferimos, pero si no es posible, en otro.

Así de corto para definirlo 🙂

Enemigos

El primero es: Lo desconocido 😉 Con el crecimiento de los ITSP’s, cada vez es más probable llamar a un cliente del mismo operador, o de un operador que tiene una interconexión SIP con el operador destino. Es decir, a la hora de lanzar el INVITE, no  tenemos forma de saber los codecs que soportará el destino, y, por norma general, los carriers no hacen nunca transcoding en estos casos y acaban dando un flamante 488 raudo y veloz 😉

Así que, dada esa situación de no conocer el destino, dejamos a SDP hacer su trabajo, y por tanto, desde el lado «interno», perdemos todo el control. Si queremos garantizar «que se hable», no podemos garantizar «en que se va a hablar», básicamente porque no sabemos las capabilities del destino.

 

Estrategia: SDP Mangling / Resending de requests con OpenSIPS/Kamailio

Para este plan, usaremos estos proxy’s SIP de alto rendimiento para manipular las requests.

Así que los módulos que necesitamos serían principalmente son sipmsgops en el caso de OpenSIPS y sdops en el caso de Kamailio.

¿Qué sucede en entrada?

En los INVITE’s que inician diálogo desde el lado de operador jugamos con ventaja. Por qué sabemos perfectamente lo que soporta nuestra IP PBX y en el codec que preferimos hablar

x

Estrategia: Transcoding

esquema … describiendo la magia ….

xxx