A continuación os dejo las transparencias, que espero sirvan a alguien para aclarar el concepto de ICE en si, y cómo lo hicimos funcionar correctamente con OpenSIPS y MediaProxy.

Njoy!

Configurar el proxy para solucionar los problemas de NAT suele ser de las primeras cosas que se pretende o se hace al configurarlo, pero en muchas ocasiones se olvida el primer paso: entender el NAT. En su día escribí un post con una breve introducción al NAT, pero lo que os recomiendo es que os leáis varias veces éste post de Iñaki Baz Castillo explicando como afecta el NAT al protocolo SIP así así como los distintos tipos de soluciones.

En este post vamos a ver como “arreglar” el NAT con OpenSIPS 1.6 y MediaProxy. El módulo mediaproxy de OpenSIPS nos servirá en combinación con el propio MediaProxy para arreglar el SDP y hacer que el RTP pase por MediaProxy, mientras que para arreglar la parte de señalización utilizaremos el módulo nat_traversal.

El módulo nat_traversal

Este módulos nos servirá para arreglar la cabecera Contact de los mensajes SIP nateados y mantener el NAT abierto haciendo keepalive del lado servidor. El módulo nat_traversal tiene una particularidad que le diferencia de otros módulos similares: fue diseñado para tratar entornos multi-proxy, como por ejemplo el caso en que el proxy que mantiene el keepalive no sea el que gestiona los REGISTER (el registrar). No vamos a entrar en detalle en este post, pero conviene tenerlo en cuenta…

El módulo mediaproxy

Este módulo gestiona la comunicación con el servidor MediaProxy, de manera que el módulo modificara el SDP para que el audio pase por MediaProxy, que actuara de media relay. Como comente en un post anterior MediaProxy soporta ICE, por lo que podremos arreglar el NAT en prácticamente todos los casos (salvo los malditos ALGs).

Antes de empezar

Antes de comenzar la descripción de la configuración necesaria es importante comentar que en este post vamos a utilizar el método fácil. El módulo mediaproxy tiene 2 formas de funcionar:

1. Funciones use_media_proxy y end_media_session: han de ser llamadas por el usuario, por lo tanto este ha de saber exactamente cuando quiere que MediaProxy comience o acabe su funcionamiento. Grosso modo tendremos que encargarnos del primer INVITE, los in-dialog-requests y el BYE. Lo veremos en otro post
2. Función engage_media_proxy: utiliza el módulo dialog para llamar a las funciones del punto 1 internamente. El usuario solo tiene que llamar a la función engage_media_proxy en el primer INVITE y olvidarse, el resto se realizara internamente. El hecho de que sea tan fácil también trae algunas limitaciones, que veremos mas adelante.

Arreglando la señalización

Primero vamos a configurar el módulo nat_traversal, con el que podremos arreglar el NAT en la señalización.

loadmodule "nat_traversal.so"
...
modparam("nat_traversal", "keepalive_interval", 60)
modparam("nat_traversal", "keepalive_method", "OPTIONS")
modparam("nat_traversal", "keepalive_extra_headers", "X-Keepalive: yes\r\n")
modparam("nat_traversal", "keepalive_state_file", "/var/run/opensips/keepalive_state")

Con los parámetros indicados haremos que el módulo nat_traversal mande un mensaje SIP OPTIONS cada 60 segundos para mantener el NAT abierto. Ademas, añadiremos la cabecera X-Keepalive, simplemente para identificar estos paquetes mejor.

Para hacer que el módulo comience a enviar los OPTIONS será necesario que llamemos a la función nat_keepalive(). La particularidad de esta función es que no provoca que el mecanismo comience de inmediato, sino que será activado en caso de recibir/generar una respuesta positiva a un REGISTER o SUBSCRIBE y cuando un dialogo comience con un INVITE.

...
if ((method=="REGISTER" || method=="SUBSCRIBE" ||
(method=="INVITE" && !has_totag())) && client_nat_test("3"))
{
nat_keepalive();
}
...
Ademas del keepalive, también tendremos que modificar los mensajes SIP para que la cabecera Contact contenga la IP y puerto reales desde los que vino el paquete en lugar de lo que el terminal del usuario haya puesto. También añadiremos el parámetro rport a la cabecera Via, de manera que OpenSIPS anyadira la IP y el puerto desde los que recibió el paquete a la primera cabecera Via aunque el terminal no indicara soporte para rport. Para ello incluiremos lo siguiente en nuestro request route:

if (client_nat_test("3")) {
force_rport();
fix_contact();
}

Es posible que las respuestas también vengan nateadas, porque el terminal al que llamamos esta detrás de NAT así que tenemos que tratarlas en un onreply route:

if (client_nat_test("1")) {
fix_contact();
}

Ya solo nos queda una cosa para terminar con la señalización: fijar el AVP necesario para que OpenSIPS guarde la dirección IP y puerto desde la que se ha registrado el usuario en la tabla location de su base de datos:

modparam("registrar", "received_avp", "$avp(s:received_uri)")
...
$avp(s:received_uri) = $source_uri;

La pseudovariable $source_uri es exportada por el módulo nat_traversal y contiene la IP, puerto y transporte desde los que se recibió el paquete.

Arreglando el RTP

Una vez tenemos la señalización arreglada necesitamos hacer que el RTP pase por nuestro servidor MediaProxy. Para ello modificaremos el SDP de manera que la IP y puerto desde los que se supuestamente se enviara el RTP sean realmente el servidor de MediaProxy.

Como hemos comentado anteriormente vamos a utilizar el método fácil, por lo que solo tendremos que llamar a la función engage_media_proxy() para el primer invite:

if (is_method("INVITE") && !has_totag()) {
engage_media_proxy();
}

Limitaciones

Todo no puede ser perfecto, por lo que el método que aquí hemos utilizado puede no ser el mejor para todos los casos. En concreto estas son las limitaciones que el sistema utilizado conlleva:

• Se utilizara siempre MediaProxy: dado que la función engage_media_proxy() utiliza el módulo dialog para funcionar es necesario llamarla al comienzo del dialogo, así que llamarla al recibir un 200 OK nateado seria demasiado tarde.
• Manejo de múltiples diálogos: tanto OpenSIPS como MediaProxy sufren al recibir múltiples respuestas con SDP a un INVITE (dos 183 por ejemplo), por lo que los resultados son inesperados.

Dado que la mayoría de usuarios están detrás de NAT y que gracias a la arquitectura escalable de MediaProxy podemos ampliar los recursos a medida que los vayamos necesitando, tendremos que valorar la facilidad en la configuración frente a la flexibilidad en la gestión de NAT.

Happy NAT traversing!

Introducción

Interactive Connection Establishment (ICE) define un protocolo de actuación gracias al cual dos dispositivos SIP son capaces de mantener una sesión multimedia salvando todas las dificultades que el NAT pueda poner de por medio. Aún se encuentra en estado de draft (la última es la revisión 19), pero está en la cola para obtener un número de RFC.

ICE permite que los dispositivos involucrados en la sesión SIP prueben distintos medios o rutas para comunicarse entre sí y acuerden uno común. Gracias a ICE es posible que dos terminales que se encuentran en la misma LAN envíen el tráfico RTP de manera local, en lugar de utilizar un relay como MediaProxy o RTPProxy, sin realizar ninguna configuración exótica en el servidor. La inteligencia está en los terminales.

¿Cómo funciona?

ICE es un proceso bastante complejo que consta de 9 pasos que intentaré simplificar aquí. Para obtener una información más completa os recomiendo leeros el draft, que aunque es bastante denso describe el mecanismo completo.

Paso 1: Obtención de candidatos

En éste primer paso el llamante obtiene todos los candidados que pueda para posteriormente añadirlos al SDP. Lo habitual es que disponga de dos tipos de candidatos:

• Host candidates: candidatos que representan tarjetas de red del sistema, incluyendo enlaces VPN etc.
• Server reflexive candidates: candidatos obtenidos al realizar consultas a un servidor STUN. Lo habitual es obtener un único candidato de éste tipo con tu propia dirección IP pública.

Paso 2: Aplicar prioridades

Tras obtener la lista de candidatos se aplican prioridades, de manera que unos candidatos se prefieran frente a otros. Por ejemplo, la especificación indica que un candidato host ha de ser más prioritario que uno de tipo relayed, es decir, se prefiere mandar el audio por la LAN que a través de un servidor externo que encamina nuestro audio, lo cual tiene bastante sentido.

Al finalizar este paso se construye el SDP que será enviado. Veamos un ejemplo:

v=0
o=- 3476345811 3476345811 IN IP4 192.168.99.53
s=sipsimple 0.12.0
c=IN IP4 192.168.99.53
t=0 0
m=audio 60770 RTP/AVP 103 102 9 0 8 117 3 101
a=rtcp:60771 IN IP4 62.131.6.55
a=rtpmap:103 speex/16000
a=rtpmap:102 speex/8000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:117 iLBC/8000
a=fmtp:117 mode=20
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ice-ufrag:3e0cc9fc
a=ice-pwd:19d32c8c
a=candidate:Sc0a86335 1 UDP 1862270975 62.131.6.55 60770 typ srflx raddr 192.168.99.53 rport 48649
a=candidate:Hc0a86335 1 UDP 1694498815 192.168.99.53 48649 typ host
a=candidate:Ha45450a 1 UDP 1694498815 10.69.69.10 48649 typ host
a=candidate:Sc0a86335 2 UDP 1862270974 62.131.6.55 60771 typ srflx raddr 192.168.99.53 rport 48868
a=candidate:Hc0a86335 2 UDP 1694498814 192.168.99.53 48868 typ host
a=candidate:Ha45450a 2 UDP 1694498814 10.69.69.10 48868 typ host
a=sendrecv

Paso 3: Iniciación

En este paso simplemente se envía el INVITE al usuario correspondiente con el SDP creado en el paso 2. SIP atravesará el NAT mediante los mecanismos tradicionales (rport, etc.) por lo que no hay que hacer tratamiento de NAT para el SDP.

Paso 4: Obtención de candidatos (llamado)

Al recibir el INVITE con la oferta en el SDP, el llamado comienza a obtener sus propios candidatos de la misma manera que lo hizo el llamante. Una vez más, lo habitual es obtener candidatos host y server reflexive. Una vez se obtienen los candidatos, se aplican prioridades y se construye el SDP que será enviado.

Paso 5: Información

El llamado responde al INVITE con una respuesta (provisional o definitiva) y en su SDP habrá incluido sus candidatos.

NOTA: Aunque puede tener sentido enviar la respuesta en una respuesta provisional (18X) SIP no especifica como actuar ante la recepción de múltiples respuestas 18X con SDP, por lo que si encima añadimos ICE al asunto lo mas probable es que no podamos establecer la comunicación. En todas las pruebas que he hecho (y han sido muchas) la negociación ICE no lleva más de 2 segundos, por lo que hacerla tras el 200 OK no es un problema IMHO.

Paso 6: Verificación

Cada agente (llamado y llamante) involucrado en la comunación empareja sus candidatos con los candidatos remotos para formar parejas de candidatos. Éstas parejas serán evaluadas por orden de prioridad descendente por el agente controlador. Por simplificar, diremos que el agente controlador siempre el el llamante (esto puede variar, pero en casos bastante peculiares, que creo que añadirían demasiada confusión al tema).

En éste momento ambos agentes comienzan a realizar pruebas de conectividad cada 20ms. Éstas pruebas se llevan a cabo mediante paquetes especiales STUN que contienen binding requests. El agente remoto contestará con la IP y el puerto desde los que ha recibido dicha binding request y así el agente que ha enviado la petición sabrá que el test ha sido satisfactorio y marcará el candidato como válido.

Si uno de los agentes involucrados en la sesión se encuentra tras un NAT simétrico, esto será detectado al ver la diferencia entre el server reflexive candidate publicado y el origen del binding request que mandará. Entonces se crea un nuevo candidato de tipo peer reflexive, que contiene la IP y puerto donde estará el RTP (los test de conectividad de hacen enviando paquetes STUN a los puertos donde posteriormente habrá RTP). Gracias a esto es posible que un usuario tras NAT simétrico y otro tras un NAT no simétrico hablen entre si con audio de router a router. Increíble, ¿no?

Paso 7: Coordinación

Tras la negociación ambos agentes involucrados en ella han de terminar con un par de candidatos válidos por cada componente. Lo habitual es tener dos componentes por cada stream en el SDP: un componente para el RTP y otro para el RTCP.

El agente controlador (habitualmente el que realiza la llamada) elegirá un candidato. A éste proceso se le llama nominación. Para validar éste candidato se envía otra binding request (STUN) pero en esta ocasión se incluye un flag. Ambos agentes utilizarán el par de candidatos que ha pasado las pruebas de conectividad y que además esté nominado.

Recordemos que todo éste proceso ha sido realizado por los agentes utilizando paquetes STUN entre si, sin ninguna interacción por parte del servidor.

Paso 8: Comunicación

Ahora que ambos agentes saben cómo comunicarse, ya pueden enpezar ha hablar, y tenemos garantizado que habrá audio bidireccional, ya que las pruebas de conectividad se realizan en ambas direcciones.

Paso 9: Confirmación

Aunque toda la negociación ha tenido lugar entre los agentes es posible (y habitual) que haya otros agentes en el medio de la señalización, como por ejemplo proxys. Para que los proxys o las middle-boxes entre el llamado y el llamante estén al tanto de lo sucedido, se enviará un re-INVITE o un UPDATE con el resultado de la negociación en el caso de que el candidato seleccionado no sea el candidato por defecto (las líneas c y m del SDP).

¡Qué way!, esto funciona, ¿no?

Pues, para variar, no. Lo habitual para el tratamiento de NAT consiste en que el proxy modifica el SDP si detecta NAT e indica como origen del RTP y RTCP un servidor que hará las veces de media relay.

Al modificar el SDP, no habrá ningún candidato que corresponda a la IP y puerto de las líneas c y m del SDP, por lo que al recibir un INVITE así el otro extremo nos responderá con ésto en su SDP: a=ice-missmatch. Mal tema. ¡Hay que solucionarlo!

“Arreglando” la negociación ICE con OpenSIPS y MediaProxy

Para solucionar éste problema ha sido necesario modificar OpenSIPS y MediaProxy (los componentes con los que trabajo actualmente, pero lo mismo puede hacerse para Kamailio/SIP-Router y RTPProxy).

Resumiendo un poco (tenéis una explicación más completa aquí) lo que sucederá es que OpenSIPS añadirá un nuevo candidato de tipo relayed cuando modifique el SDP, de manera que corresponda con la IP y puerto de las líneas c y m. MediaProxy es ahora capaz de “dejar pasar” las pruebas de conectividad STUN, por lo que al modificar el INVITE inicial y su correspondiente respuesta habremos “engañado” a los agente insertando un nuevo candidato.

Mediante un parámetro es posible controlar la prioridad del candidato que OpenSIPS insertará, afectando así al resultado de la negociación.

Ahora sí, ¡funciona! puedo hablar con audio P2P en mi LAN aunque fuerce el uso de MediaProxy, porque al detectar una negociación ICE satisfactoria MediaProxy se “quita de en medio”. También he probado ha hablar con audio de router a router entre un NAT simétrico y otro de tipo port restricted. How f*c*i*g cool is that?

¡Quiero probarlo!

No tan rápido vaquero. Nos falta hablar de el tema más importante: los clientes SIP. Sólo conozco tres (en esencia uno) que implemente ICE correctamente. Y cuando digo correctamente es que me he leído el draft, el código y he probado que funciona Los clientes SIP con soporte ICE (draft versión 19) son PJSIP, SIPSIMPLE client (su core es PJSIP) y Blink (su core es SIPSIMPLE).

Si alguien descubre o está desarrollando un cliente SIP que cumpla la especificación ICE (draft 19) me encantaría probar la interoperabilidad con él.

Actualmente no hay ninguna versión (release) de OpenSIPS que incluya el parche para “solucionar” el problema de ICE, así que podéis parchear manualmente como se menciona aquí o podéis utilizar el servicio gratuito SIP2SIP, que ya dispone de todo lo necesario (parches para OpenSIPS y última versión de MediaProxy).

Conclusiones

Tras estar un mes con éste tema por fin he podido comprobar que funciona. No obstante, es triste ver que hay muy pocas implementaciones de ICE y que solo una funcione. Es cuanto menos sorprendente que softphones de pago de supuesto prestigio digan que soportan ICE y en el SDP se vea claramente no de la manera correcta.

Hay que agradecer a Benny Prijono y el equipo de PJSIP el buen trabajo que han realizado al respecto acudiendo en enumerosas ocasiones al SIPit para mejorar su SIP stack.

¡Joder que largo me ha quedado esto! Para más información podéis leer el draft y echarle un ojo a ésta presentación.

Happy ICE skating!