Blog de Jerocu

La FreeBSD Foundation ha anunciado que dispone de un presupuesto de 80.000 dólares para financiar proyectos relacionados con los subsistemas principales o arquitectura de FreeBSD.

Las propuestas deben incluir:

• Descripción detallada de la propuesta, cómo beneficiará al proyecto FreeBSD y porqué es necesario ese nuevo desarrollo.
• Un calendario y costes del nuevo desarrollo.
• Una o más personas que actuarán como revisores técnicos del trabajo desarrollado

¿Alguien se anima?

Debido a problemas legales por registro de marca, OpenSER se ha visto obligado a cambiar el nombre del proyecto y el nuevo nombre elegido es Kamailio.

Kamailio es una palabara hawaina que significa “hablar, conversar”… y aunque más que una palabra parezca un “palabro”, uno se va acostumbrando a medida que la va leyendo y usando.

Este paso sigue la estela de otros proyectos que por lo mismos motivos han tenido que cambiar el nombre con todas las complicaciones que eso conlleva, especialmente ahora que en el caso de OpenSER había conseguido una notoriedad importante en algunos sectores y ahora habrá que usar a pié de página eso de “Kamailio, former OpenSER project”

Después de varios días con muchísimo trabajo y sin tiempo para escribir nada, he tenido un ratito y he actualizado el Wordpress a la versión 2.5.1 … espero que todo siga funcionando bien

En la lista VOIPSEC han enviado un mail muy divertido con un enlace a la web de Toysrus en la que venden un “juguete” para poder hacer escuchas telefónicas… ¿es realmente eso un juguete?

El mail termina con una frase muy buena: “Son, how did you know we were shipping you to Siberia?”

Y más novedades en el futuro OpenSER 1.4 … esta vez le toca al módulo de autenticación. Esta nueva funcionalidad es un mecanismo de protección contra el uso fraudulento de la autenticación en SIP ya que no permite re-utilizar credenciales con el mismo nonce aunque no haya expirado el tiempo de vida de ese nonce.

El mail de Bogdan en el que anuncia la nueva funcionalidad es una excelente explicación por lo que creo que no vale la pena alargarse mucho aquí.

Dan Pascu de AG Projects y desarrollador de MediaProxy entre otras aplicaciones relacionadas con OpenSER/SER, ha anunciado la próxima disponibilidad de la versión 2.0 de esta aplicación.

Esta nueva versión incorpora, entre otras novedades un nuevo diseño basado en el sistema de control de conexiones del kernel de Linux, un nuevo interfaz basado en el uso del módulo “dialog” con lo que al recibir el primer INVITE todos los siguientes mensajes pertenecientes a esa sesión y que contengan SDP serán reescritos de forma automática; de igual forma, al terminar el diálogo, el propio MediaProxy se encarga de finalizar la sesión, sin necesidad de llamar a la función end_media_session() desde el script.

Otras nuevas funcionalidades son la comunicación encriptada entre el dispatcher y los relays en el caso de usar múltiples relays para balanceo de carga, soporte de T.38, cambiar de forma dinámica la ip/puerto del llamante al llegar un re-INVITE o UPDATE durante un diálogo y algunas cosas más.

Personalmente no he usado nunca MediaProxy en producción (siempre he trabajado con rtpproxy) pero quitando los posibles problemas de escalabilidad (evitables usando múltiples mediaproxies distribuidos) parece que funciona bastante bien por los comentarios de la gente que sí lo usa.

Siguiendo con las nuevas funcionalidades que se están añadiendo a lo que será la versión 1.4 de OpenSER, comento hoy una que se llama “dialog profiling”.

Esta opción permite clasificar, ordenar y obtener información de ciertos tipos de diálogos, usando cualquiera de las propiedades de ese diálogo (llamante, destino, tipo de llamadas, etc). Los diálogos pueden añadirse de forma dinámica en diferentes tablas de perfiles, teniendo cada perfil un significado diferente.

Existen dos tipos de perfiles:

• Sin valor - un diálogo simplemente pertence a un perfil. No hay ninguna información adicional para describir el diálogo que pertenece a ese perfil.
• Con valor - un diálogo pertenece a un perfil que tiene un cierto valor (como en el perfil “llamante” en el que el valor es el Caller ID). La pertenencia del diálogo a ese perfil está estricamente relacionada al valor.

El disponer de estos perfiles permite hacer cosas como balanceo de carga (mediante el módulo dispatcher) con cálculo de probabilidades sin depender de la respuesta negativa del gateway. También permite establecer un límite al número de llamadas simultáneas enviadas por un usuario y cosas de este tipo.

El mail de anuncio de esta nueva funcionalidad enviado por Bogdan explica muy bien qué se puede hacer.

Después de innumerables discusiones desde hace años, al final el core de FreeBSD ha decidido cambiar el sistema de gestión de versiones pasando de CVS a SubVersion. Este traspaso se está haciendo estos días y aunque han salido varios problemas, la cosa sigue adelante.

Ahora habrá que esperar, de nuevo, esas innumerables discusiones sobre la gente que está contenta, los que están tristes, los que pasan de todo pero que sólo quieren meter cizaña, etc… esas cosas que pasan cuando hay un grupo importante de gente y todos quieren decir la suya

¿Está CVS pasando a la historia?. Muchísimos de los proyectos de desarrollo importantes han pasado de CVS a SVN en los últimos años (y otros a Perforce) y por el momento ninguno ha emprendido el camino de vuelta… incluso Apple hizo el cambio de CVS a SVN así que ahora ya sabeis que usan para gestionar las versiones del software que desarrollan

Se ha añadido en la versión de desarrollo de OpenSER una nueva funcionalidad que permite crear un nuevo tipo de ruta llamado “local_route”. Esta ruta se ejecutará cuando se genere internamente una nueva petición (request) en la que OpenSER se convierte en un UAC.

Hasta ahora, las requests generadas internamente por OpenSER eran totalmente transparentes y no se podía hacer absolutamente nada con ellas. Con este nuevo tipo de ruta se pueden hacer manipulaciones de forma dinámica como checks, añadir cabeceras, generar logs, accounting, etc.

Por el momento tiene algunas limitaciones importantes como que no se pueden modificar los parámetros $ru y $du (Request URI y Destination URI) de la request, no se pueden usar onreply o failure routes y no se puede hacer accounting de esas transacciones usando flags.

Esta nueva funcionalidad ha creado cierto revuelo entre los desarrolladores de OpenSER ya que se ha añadido justo antes de que comenzase el “freeze” de la rama HEAD (futura versión 1.4) y algunos consideran que es una modificación demasiado importante para hacerla justo antes del freeze… veremos como termina.

En los últimos días hubo una discusión interesante (lanzada por Iñaki, además) en las listas de OpenSER y sip-implementors a acerca de cómo tratar las respuestas 6xx ya que según la RFC3261 cuando un proxy recibe un 6xx, éste debe dar por terminada la transacción y no permitir crear ningún otro branch ya que se considera que es una respuesta de finalización completa… y sin ninguna opción de continuidad

Debido a que algunos UA (softphones, teléfonos IP, gateways, etc) hacen un mal uso de esta respuesta, hay casos en los que no es posible usar servicios como serial forking, crear un nuevo branch hacia un media server, etc, al recibir un 6xx cuando realmente se debería recibir un 4xx.

Después de las discusiones comentadas, Bogdan Iancu ha decidido implementar una nueva opción en el módulo TM de OpenSER que permite modificar el comportamiento del proxy al recibir un 6xx, aunque esto signifique saltarse el comportamiento estándar definido en la RFC3261. Con esta nueva opción, se puede hacer que el proxy trate un 6xx internamente como si fuese cualquier otra respuesta negativa (4xx, 5xx) permitiendo generar nuevos branches para serial forking, locuciones, etc.