En el draft propuesto hay cosas tan interesantes como:

• Hiding SIP complexity under the right, standards based API
• The SIP state machine moves to the business logic in UA and Web
  feature servers
• Added references for metadata standards to replace SDP
• Keep only UDP for media transport, RTP data about the media is moved to the application as well
• New reference for HIP specific NAT traversal utilities

La verdad es que Henry Sinnreich lleva ya un tiempo aportando dentro del IETF nuevas propuestas de este tipo para crear toda una serie de elementos/tecnologías que permitan integrar SIP de una forma sencilla en las aplicaciones Web.

P.D. Sí, de vuelta…

El propio autor del gráfico explica que va a preguntar en Slashdot lo que piensa la gente sobre esos patrones.

En el texto, también incluye un artículo (El síndrome del coronel Tapioca) escrito por el genial (y a veces pasado de vueltas) Arturo Pérez Reverte en el que refleja qué es ser un corresponsal de guerra o conflictos y las consecuencias que ello puede conllevar.

Como se ve al leer los dos artículos, parece que ha quedado muy lejos ese concepto de corresponsal de guerra que había hace años (¿os acordais de Pérez Reverte haciendo las crónicas agazapado detrás de una trinchera o similar sonando los tiros alrededor suyo?) con el que el riesgo, las penurias, el miedo (u acojone) era algo indivisible?. Como en muchas otras cosas, parece que ya no queda nada de eso…

En la misma nota de prensa se hace un llamamiento a operadores y fabricantes para aumentar el uso y despliegue de IPv6. Según indican, las asignaciones de IPv6 aumentaron un 30% durante 2009.

A pesar de este aumento, el tráfico (y utilidad) real de IPv6 aún es prácticamente insignificante fuera de los ámbitos de investigación, técnicos y freekies… por algo será que este blog tiene IPv6 . Por ejemplo, la tabla de rutas BGP de IPv6 tiene ahora mismo 2273 prefijos, lo que es una minucia comparado a los más de 303000 que hay en la tabla de IPv4 (si bien es cierto que la situación de la tabla IPv4 es de demasiados prefijos).

Si probamos cuantos servidores web de los que usamos diariamente tienen soporte para IPv6, quedaríamos tremendamente defraudados (ni Google a no ser que se use una url concreta), así que aún queda un largo camino por recorrer: los operadores e ISP con soporte IPv6 (aquí sí que hay camino recorrido) y que entreguen direccionamiento IPv6 a los clientes (ADSL, cable, etc), los fabricantes de equipos, los operadores de contenidos, desarrolladores de software, etc, etc, etc… demasiado camino que recorrer todavía para estar por debajo de un 10% de direccionamiento IPv4 no asignado.

Desde ahora mismo ya podeis acceder a este blog a través de IPv6… no se muy bien para que servirá ni cuanta gente tiene acceso IPv6 a Internet pero bueno, ya se sabe como somos los técnicos, ¿no?

Enjoy!.

A ver si estos días me voy poniendo al día con los posts…

Feliz años a todos!.

Sobre lo primero, después pondré un post específico. Respecto al VoIP2day, creo que estuvo muy bien, con muchos asistentes y mucha animación, sobre todo teniendo en cuenta lo rápido que tuvo que hacerse todo… la gente de Avanzada7 se lo han currado un montón y les ha salido muy bien.

Los dos primeros días fueron más comerciales, mientras que el tercer día fue totalmente técnico y frikie! . Como siempre, ver a la gente que normalmente sólo ves en estos eventos, escuchar charlas interesantes, hablar con unos y otros… divertido!.

La charla de Josep Antoni Torres (bytecoders) me pareció muy interesante y es increíble la de cosas relacionadas con vídeo que se pueden hacer con Asterisk… sobre todo echándole un poco de imaginación.

Al final del último día llegó la cena y después de la cena lo que le suele seguir… hasta altas horas

Gracias a Avanzada7 por montar el evento e invitarme, a los chicos del norte y del sur por sus recomendaciones sobre las licencias y en general a todos los que han participado de una forma u otra en esta historia… que espero se repita y sea el inicio de algo mucho más grande e importante.

La presentación que utilicé en mi charla se puede encontrar aquí, junto al resto de presentaciones del última día del VoIP2day.

Esta semana Olle Johanson, el responsable del chan_sip de Asterisk ha abierto la caja de Pandora en la lista de desarrollo de Asterisk al enviar un mail en el que entre otras cosas dice que la nueva política de releases no es buena y que Russell (el actual “release engineer”) no está preparado para ejercer esa función.

Olle habla de que el soporte de SIP TCP/TLS en las versiones 1.6 simplemente no funciona, como se pudo comprobar en el pasado SIPIt23 y que los cambios que hay que hacer para arreglar esa parte son tan extensos y profundos que SIP sobre TCP/TLS no estará listo hasta dentro de algunas versiones y que estos cambios van en contra de la política de releases implantada, igual que otras nuevas funcionalidades como soporte de IPv6, el nuevo sistema de bridging, nuevo framework de negociación de codecs o el tan discutido ultimamente Pinemango y el framework de seguridad.

La verdad es que este tipo de problemas son comunes a todos los proyectos de desarrollo (personalmente lo he vivido muchas veces como desarrollador de FreeBSD) y siempre son complicados de gestionar porque cada desarrollador, de una forma o de otra, piensa que lo suyo es más importante o es más necesario o tiene más valor y después de horas y horas desarrollando lo que quieres es ver todo ese código implementado en las versiones release… porque ¿cuantos usuarios hay que prueben las nuevas funcionalidades de versiones “release candidate” o trunk en sistemas de producción?. Y claro, luego cuando esos cambios se pasan a las versiones estables salen bugs y problemas… y es el pez que se muerde la cola.

Ser el “release engineer” de un proyecto importante es realmente complicado, hay que ser muy político y tener mucha mano izquierda para saber moverse entre tantos “tiburones”

Además, creo que en este caso hay cierta ¿frustación? por parte de Olle. A pesar de que (aún sin tener números reales) SIP debe ser el protocolo más usado en Asterisk y con mucha diferencia sobre IAX, pienso que Digium no ha apostado nunca por SIP, siempre lo ha dejado de lado y parece que no ha mostrado ningún interés por apoyarlo, soportarlo, mejorarlo e impulsarlo. La apuesta de Digium ha sido siempre IAX/IAX2 y hasta ahora no he entendido el porqué. SIP es un estándar, IAX/IAX2 no (aunque puede que lo sean en un tiempo ya que el draft anda en el IETF), SIP se ha convertido en el protocolo de facto para VoIP y cada vez más para vídeo sobre IP, aplicaciones, etc, y Digium sigue con su IAX. ¿Porqué?.

Olle ha invertido muchas horas en mejorar el soporte de SIP en Asterisk pero siempre de forma voluntaria o con proyectos específicos pagados. Por el camino se han quedado cosas tan interesantes como chan_sip2, chan_sip3 y algunas cosas más que darían un verdadero stack SIP a Asterisk. Estos proyectos se han tenido que abandonar por falta de tiempo y recursos por parte de Olle y Digium nunca ha decidido poner a algún programador o recursos para que se pueda dedicar a ellos así que si Olle no programa y Digium no pone recursos, el soporte de SIP se queda tal y como está, es decir, cogido con pinzas.

En la versión 1.4.22, el archivo chan_sip.c tiene 18678 líneas… hasta ahora, lo único que se ha hecho ha sido parchear este archivo, añadir todos los comentarios posibles y rezar para que si tocas codigo en las 500 primeras líneas no afecte a algo mucho más abajo.

Supongo que toda esta situación es lo que hace que Olle envíe un mail tan provocador (según sus propias palabras) a la lista de desarrollo de Asterisk para ver si hay algún tipo de reacción por parte de alguien, llegando incluso a hablar de forks, renombrar el proyecto, etc… y creo que algo habrá conseguido porque hasta el momento no se ha convertido en una “flame war”.

En un mail de ese thread leí que algunos desarrolladores estuvieron hablando sobre la posibilidad de integrar resiprocate como el stack SIP de Asterisk… lo que creo que no sería mala idea.

Digium sabrá lo que hace y porqué lo hace (¿alguien recuerda los comentarios que habían hace un tiempo en el chan_sip.c escritos por Mark Spencer?)… eso, aunque igual es una tontería, quizás podría dar una idea de lo que hay detrás… además de que queda muy bonito ser autor de una RFC, aunque sea de un estándar que no usa nadie y que lo tiene realmente complicado para llegar a usarse fuera de tu ámbito más cercano.

El sistema, por defecto, se activa automáticamente las noches del fin de semana ya que es cuando se suelen enviar estos tipos de mails y lo que hace es que tienes que contestar algunas operaciones matemáticas sencillas pero que hacen que el envío del mail se retrase y te de tiempo a pensar si realmente quieres enviarlo o no.