Blog de Jerocu

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.

Voice System, empresa que agrupa a algunos de los desarrolladores principales de OpenSER ha convocado un curso de programación avanzada de OpenSER con el que intentará atraer a nuevos desarrolladores y aumentar el “development squad”, como dicen ellos.

La duración del curso es de 4 días, es gratuito y su objetivo principal es enseñar a programar módulos de OpenSER desde cero. El curso será un 60% teórico y un 40% práctico, incidiendo en temas como uso dinámico de memoria, interfaz MI, timers, bloqueos (locking), pseudo-variables, etc.

El curso será en Bucarest y empezará el día 11 de Agosto… ah, por cierto, es totalmente gratuíto!

Por temas de trabajo, estoy de nuevo en Mexico… hoy domingo relax y mañana lunes empieza de nuevo la guerra

Mexico D.F. es una ciudad curiosa… es enorme, 25 millones de habitantes, muchísima polución aunque ahora no está muy mal, tráfico de coches descontrolado (¿quién dice que en España se conduce mal? ), siempre mucha vida en la calle, una comida excelente y muy variada, si tienes cualquier problema lo último que debes hacer es acudir a la policía (frustrante, ¿no?)… pero lo mejor de todo es la gente, por lo menos, la gente que me ha tocado conocer, son realmente agradables, amables y atentos.