Creo que pocas veces ha habido tanta materia gris junta relacionada con SIP en una misma sala
… estas son las fotos de la reunión de Karlsruhe sobre la unificación de los proyectos SER y Kamailio en sip-router.org.
Creo que pocas veces ha habido tanta materia gris junta relacionada con SIP en una misma sala
… estas son las fotos de la reunión de Karlsruhe sobre la unificación de los proyectos SER y Kamailio en sip-router.org.
Ya de vuelta en la oficina después de una semana un poco loca… primero en la reunión para el proyecto sip-router.org y después en Madrid en el VoIP2day.
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.
En la nueva versión de DAHDI, aún en fase release candidate, se ha añadido soporte para la tarjeta B410p (la ÚNICA tarjeta RDSI del catalogo de Digium).
Desde Digium animan a los usuarios a probar estos nuevos drivers con el fin de estabilizarlos lo antes posible y teniendo en cuenta los últimos dolores de cabeza que he tenido a cuenta de Kernels > 2.6.24 y mISDN espero que estos drivers funcionen…
Para probar estos drivers es necesario tener una versión superior a la 1.4.4 de libPRI y 1.6.0 de Asterisk. Podéis descargar en nuevo DAHDI aquí:
En en el fichero system.conf tenéis un ejemplo de la configuración necesaria.
NOTA: Todavía no están disponibles los tarballs para dahdi_linux y dahdi_tools de manera separada, así que es necesario bajarse el dahdi_complete u obtener las versiones a través del SVN.
Vía VentureVoIP
Esta tarde, después de unas cuantas horas de viaje (dos aviones y un tren) por fín he llegado a Karlsruhe para la reunión de mañana acerca del nuevo proyecto sip-router.org en el que se pretende integrar SER y OpenSER/Kamailio.
He estado cenando con Daniel, Ramona y Henning y la verdad es que hemos hablado muy poco (o nada) de SIP y temas relacionados… hay que desconectar de vez en cuando!!
La reunión será en las oficinas de 1und1 (gracias Henning), uno de los mayores ISP alemanes que tiene la nada despreciable cifra de 1.8 millones de usuarios VoIP en una plataforma basada en OpenSER… a ver quién dice ahora que las soluciones libres no escalan…
Mañana más…
Del bloc El quadern gris:
Davant de la tenacitat infatigable de les màquines, és impossible de no
fer-se càrrec de fins a quin punt l’home ha vingut a menys. De vegades
us vénen ganes d’anar-lo a apagar amb una galleda.
YASS o Yet Another SIP Softphone fue el titulo que finalmente elegí para mi Proyecto Fin de Carrera. El título es bastante descriptivo: YASS es un softphone SIP, pero como ya hay varios y muy buenos circulando por ahí, decidí hacer algo un poco diferente
Además de ser un softphone y ser Libre (GPLv2), YASS es un framework para el desarrollo de aplicaciones que incluyan funcionalidades relacionadas con la telefonía. Al examinar el software actual disponible me dí cuenta de que no había un framework o herramienta que proporcionara una manera sencilla y de alto nivel de integrar la telefonía en nuestras aplicaciones.
El PFC fue la excusa para llevar a cabo este desarrollo, en el que opté por utilizar Python y Qt, además de las librerías PJSIP, de las que hablaré más en detalle en otro post más extenso.
No tenía pensado escribir esto hoy, ya que el código no esta todavía disponible (faltan unos detalles xD), pero me han dado la oportunidad de presentar YASS en las jornadas SLUN08 y al llegar me han comentado que hay live streaming de las ponencias, por lo que podéis seguir la presentación aquí: [www.sc.ehu.es]
Es la primera vez que contribuyo de esta manera al Software Libre, por lo que tengo miedo y ánimo a partes iguales
En breve publicaré el código fuente y espero que la encontréis de utilidad
Ahora que ya se ha hecho público, puedo hablar de ello
. A raíz de varias conversaciones de esas sin mucha importancia que se tienen en un bar mientras se toma algo, se empezó a gestar la posibilidad de unificar los proyectos de SER y Kamailio en un único proyecto, obteniendo lo mejor de cada casa.
Y aquí lo tenemos… después de muchas conversaciones entre los dos grupos y de consultas a diferentes personas involucradas de una forma u otra, se ha llegado a un acuerdo y se van a unificar los dos proyectos en uno nuevo llamado sip-router.org, tal y como ha anunciado Daniel en un mail enviado a las listas de los diferentes proyectos.
Personalmente creo que es una muy buena noticia ya que SER dispone de algunas funcionalidades únicas y más robustas que los otros proxy SIP libres (el módulo TM está más avanzado, mejor soporte de TCP/TLS, soporte de SCTP, mejor gestión de memoria, Andrei sigue ahí
) mientras que Kamailio disponde de bastantes más módulos y funcionalidades que SER por lo que uniendo las dos cosas debería quedar un proyecto realmente interesante, fiable, funcional y potente.
Para avanzar lo más rápido posible con la integración, habrá una reunión el próximo día 10 de Noviembre en Karlsruhe, en la sede de 1und1… y allí nos encontraremos varios conocidos
El proceso de integración acordado entre las dos partes está bastante cerrado y explicado en esta sección de la web de sip-router.
Este tema seguro que dará más que hablar… con un poco más de tiempo intentaré explicar como ha ido la cosa “behind the scenes” durante estos meses de conversaciones y negociaciones porque ha sido bastante interesante, teniendo en cuenta que el punto de partida era integrar un fork del proyecto original con ese mismo proyecto original, con muchas de las mismas personas que había en el momento del fork… y casi siempre la parte más complicada de estas cosas son las relaciones personales.
Parece que SER y Kamailio (OpenSER) van a aunar sus fuerzas para lanzar un nuevo proyecto: SIP Router.
La idea es poder unir a todos los desarrolladores y evitar así que se desarrollen cosas 2 veces, o que se malgaste esfuerzo en implementar cosas ya implementadas.
Tenéis toda la información en el Blog de Daniel Constanine Mierla y en la propia web de SIP-Router.
Personalmente creo que esta iniciativa es todo un acierto, ya que se había creado demasiada división al separarse OpenSER en Kamailio y OpenSIPS. Esperemos que con esta unión se fortalezca aún más el proyecto!
ACTUALIZACIÓN: Me comenta Manwe que según la web del proyecto, ha habido cambios en la licencia: todo nuevo código que se añada al core o al módulo tm, va a ser licenciado bajo BSD, y las nuevas aportaciones a los módulos tendrán la opción de elegir entre BSD y GPL.
La gente de AG Projects ha publicado la versión 1.0.5 del servidor OpenXCAP y de la librería XCAP en Python. Se han solucionado unos cuantos errores y mejorado el reporting de errores.
Es posible que en breve haya alguna nueva versión con compatibilidad mejorada por todas las pruebas que hicieron en el SIPIt23.
OpenSIPS ha publicado un pequeño informe acerca de las pruebas de interoperabilidad que realizaron durante el SIPIt23. Parece que en lo referente a SIP sobre UDP “de toda la vida” no ha habido ningún problema importante (tenía que ser divertido ver las pruebas del parallel forking con tres niveles de proxies o las detecciones de loops).
Dónde si parece que ha habido algún problemilla es en SIP sobre TCP y SIPS, cosas que seguro se irán solucionando en las próximas semanas.
Comentan que un tema actual en las pruebas ha sido el soporte de SCTP, pero que éste no es bueno en Linux… ¿por qué no usarán el de FreeBSD?
Algo positivo es que parece que los implementadores están soportando mejor todo lo referente a resoluciones NAPTR/SRV de DNS haciendo una resolución por cada request que se envía.
Os recomiendo echar un vistazo a las fotos… y conozco a bastante más gente de la que pensaba!!
El próximo SIPIt será en Akihabara, Tokyo, del 18 al 22 de Mayo… ese no se me escapa!!!
Klaus Darilion, uno de los desarrolladores de Kamailio y consultor de VoIP ha publicado un análisis sencillo pero bien explicado y muy fácil de leer y entender acerca de un ataque a dispositivos SIP que se llevó a cabo durante las últimas semanas en varios países de Europa (que yo sepa al menos en España, Alemania, Suiza y Noruega).
El objetivo del ataque era encontrar gateways o equipos con interconexión a PSTN que no estuviesen protegidos y aceptasen llamadas desde cualquier origen para enviarles tráfico a destinos bastante caros. Un efecto colateral de este incidente ha sido uno de los mayores ataques de SPIT que han habido ya que muchos teléfonos IP o ATA conectados directamente a Internet (por ejemplo, los Fritzbox de AVM de lo que hay millones en Alemania) empezaron a sonar a cualquier hora del día o de la noche… y seguro que molesta mucho más que el Spam
En el artículo se hacen algunas recomendaciones básicas para asegurar los equipos de VoIP, pero no dejan de ser cosas básicas de sentido común que todo aquel que trastee con estos equipos debería tener en cuenta desde el primer momento.
Este ataque ha sido uno de los incidentes de seguridad relacionados con la VoIP que más repercusión ha tenido en medios, listas y foros, lo que no es de extrañar visto el ámbito de actuación.
Hace unos meses ya hice un comentario acerca del modelo de desarrollo y release engineering de Asterisk. A pesar del nuevo modelo de gestión de versiones que implantaron, parece que aún quedan cosas por pulir.
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.
Hace unos minutos se ha publicado la versión 1.4.2 de Kamailio. Esta versión es totalmente compatible tanto en el script de configuración como en la base de datos con la versión 1.4.1.
En esta versión se han solucionado algunos bugs, se han incluido varios “backports” provenientes de OpenSIPS (se nota que los dos proyectos aún son muy parecidos a nivel de código ya que siguen compartiendo commits) y se ha mejorado la documentación.
Voice System ha liberado una herramienta para provisionar la parte operativa de OpenSIPS… esto quiere decir que puedes configurar algunos módulos, provisionar contenido en la base de datos para otros módulos, acceso a la monitorización, etc, pero no para crear usuarios o configurar el proxy… hay que seguir rascando el código a mano en el script de configuración.
Este panel de control da acceso a la siguientes funcionalidades:
Esta herramienta está desarrollada en php y se compone de un pequeño core y una serie de módulos que son los que realmente ofrecen las distintas funcionalidades.
Yo conozco esta herramienta y la he usado desde hace un par de años, pero sólo para algunas partes concretas así que no la conozco completa y la verdad es que va bastante bien para hacer algunas consultas en las bases de datos, dar acceso a un servicio de soporte para que puedan ver (pero no tocar, puedes configurar permisos
), por ejemplo, las tablas de routing, grupos, etc.
Algo interesante es que esta herramienta se ha liberado como un proyecto independiente hospedado en Sourceforge… a ver si más gente se anima a añadir nuevos módulos y funcionalidades.
A pesar de la cancelación del Simo, Avanzada7 se ha decidido a seguir adelante con el programa que tenía establecido y ha montado un evento, llamado VoIP2DAY, en las mismas fechas en las que estaba previsto el Simo.
El lugar del evento será el Centro de Convenciones Norte de Ifema del 12 al 14 de Noviembre.
Se mantiene el formato de exposición y conferencias. El día 12 será dedicado a los Call Centers, el segundo día a las comunicaciones avanzadas y el tercer día es el día de la comunidad.
Durante el tercer día habrán diferentes charlas por parte de gente de todos conocidos como Elio, Saúl, Alberto, Iñaki, Sergio y un servidor, además de contar con la participación estelar de Kevin Flemming y Olle Johanson.
Por lo que a mi me toca, el título de la charla será “Asterisk, proxies SIP, servidores de aplicaciones… ¿A qué se puede jugar?” y trataré de explicar qué se puede llegar a hacer combinando los diferentes componentes del título como aplicaciones y servicios complejos que unifiquen redes de telefónía, bases de datos, aplicaciones web, etc.
Nos vemos en Madrid!!.
P.D. Tengo ganas de ver a Olle y hablar con él sobre un mail bomba que envió ayer a la lista de desarrollo de Asterisk… no entiendo como Digium sigue en sus trece con no apoyar el desarrollo del chan_sip. En breve pondré un post sobre este tema.
Ya se ha publicado el report inicial de los resultados del SIPIt23. Algunos datos interesantes son que hubieron 97 participantes de 37 compañías diferentes, entre ellos OpenSIPS y Asterisk. Se probaron alrededor de 50 implementaciones SIP diferentes.
El 62% de los UA probados enviaban RTCP y tenían en cuenta el RTCP recibido. Esta es la primera vez que tantos UA tienen en cuenta este parámetro.
Parece que ya no podré meterme tanto con Víctor ya que se ha conseguido que tres implentaciones de ICE sean (casi) interoperables
Los roles representados en este evento se han dividido de la siguiente manera (una implementación puede ejercer más de un rol):
Implementaciones usando los diferentes transportes para los mensajes SIP:
Es curioso como el soporte de TCP está creciendo muy rapidamente… creo que el futuro de SIP pasa por migrar de UDP a TCP y los fabricantes se han concienciado de ello.
El 30% de las implementaciones soportaban SIP sobre IPv6 (¿dónde se puede encontrar de una vez algún UA con soporte IPv6?) y el 19% soportaba SIP sobre IPSec.
Otra cosa que me ha parecido muy curiosa es el lío que hay para saber qué parámetro usa cada implementación para mostrar el número llamante:
Como se puede ver, es un completo galimatías y cuando te mueves en un entorno multifabricante de UAs gestionar todo esto es realmente complicado :-/ … tendrían que ponerse de acuerdo para decidir qué valores usar… no debería ser tan difícil, ¿no?.
Parece que también se hicieron bastantes pruebas referentes a presencia, XCAP, etc, y que son partes que van ganando participantes.
Uno de los equipos participantes en este SIPIt me había invitado a ir y hacer las pruebas con ellos pero no me fue posible acudir
… la verdad es que los SIPIt es de los eventos que más me llaman y espero poder participar en el próximo… y contar la experiencia, claro ![]()
Como dice el refrán, a rey muerto rey puesto así que aunque nos quedemos sin SIMO no nos quedaremos sin feria de la VoIP este año.
VoIP2Day será la el encuentro que supla este año al SIMO en lo que a VoIP se refiere. Todo ha sido muy rápido pero finalmente Avanzada7 tiene todo listo para que el evento tenga lugar en el Centro de Convenciones Norte, en el Ifema de Madrid.
El evento tendrá una duración de 3 días (12 - 14 de noviembre) con diferentes temáticas:
El formato es similar al del SIMO del año pasado, que en mi opinión fue un éxito, por lo que espero que este año sea aún mejor.
Por si no fuera poco, el día de la comunidad contaremos con la presencia de Kevin P. Fleming, director del desarrollo de Asterisk y Olle E. Johansson, conocido gurú de la VoIP y pincipal mantenedor de chan_sip.
Tenéis toda la información así como las charlas y los horarios en la web de Avanzada7.
Nos vemos en VoIP2Day!!
Esta semana se está celebrando el SIPit 23 en Lannion, Francia… si seguís un poco los commits en los repositorios de diferentes proyectos relacionados con SIP podreis ver que esta semana hay muchos commits relacionados de una forma o de otra con este evento, que permite hacer pruebas de interoperabilidad entre los diferentes fabricantes y/o desarrolladores implicados en “hablar” SIP.
Seguro que las próximas dos semanas se verán más cosas… ya tengo ganas de leer el report del resultado final de las pruebas de implementaciones!… ¿cuantas implementaciones de ICE compatibles habrán esta vez?… se aceptan apuestas!! ![]()
Hoy, Henning Westerholt ha incluido en la versión de desarrollo de Kamailio una nueva funcionalidad que hace que toda la escritura de logs del servidor proxy no sea bloqueante.
Una acción bloqueante es aquella que detiene un proceso hasta que no finalice… esto implica, por ejemplo en el caso de los logs, que si el syslogd (o el servidor de logs que se utilice) deja de responder, todos los procesos de Kamailio pueden quedarse a la espera de poder escribir los logs, con el resultado final de que tenemos un servidor completamente bloqueado y que no es capaz de procesar nada porque todos los procesos están bloqueados.
Para implementar es funcionalidad, en lugar de usar la librería estándar de syslog(), ha usado unas librerías llamadas syslog-async del servidor dnsmasq. Estas librerías permiten que las líneas de log sean almacenadas en un buffer en memoria, liberando el proceso de escritura de Kamailio de forma inmediata. En caso de que ocurra algún problema con el servidor de logs, las líneas de log se mantienen en ese buffer de memoria y si el buffer se llena, se eliminan.
Este año las librerías están de enhorabuena. Como todos sabréis este año NO se va a celebrar el SIMO, por lo que la gente no va a poder llevarse a casa un saco de bolis de propaganda, así que tendrán que ir a comprarlos.
Txorradas aparte, ayer me quedé bastante sorprendido con la noticia que se esparció como la pólvora por Internet. Hace algunos años que se venía diciendo que “el SIMO ya no es lo que era” y demás, pero eso es una cosa, y cancelarlo otra.
No he asistido a muchas ediciones pero he estado en ambos bandos, como visitante y expositor. Creo que al menos en el sector de la VoIP la cosa no estaba tan mal.
La VoIP es algo de lo que se ha empezado a hablar en la calle no hace tanto, y al menos bajo mi punto de vista, la presencia en el SIMO en lo que a VoIP respecta el año pasado en comparación con los anteriores no tiene ni color.
Lo que se organizó el año pasado en el SIMO fue simplemente increíble. No hablo de asuntos comerciales ni cosas de esas, eso que cada uno lo medite por su cuenta, al menos a nivel personal fue una experiencia inolvidable.
Esperemos que de alguna manera se pueda organizar un evento relacionado con la VoIP y que mole tanto como ese Día de la Comunidad del SIMO 2007.
¿VoIPCon-ES anyone?
Esta semana se ha incorporado una nueva funcionalidad en la versión de desarrollo de OpenSIPS que permite inyectar media (audio) en una llamada, antes de que ésta se establezca. El proxy añade un branch que va al media server. Este media server debe responder con un 183 y empezar a enviar el audio, con lo que el llamante podrá escucharlo.
De esta forma, es posible montar un servicio de ringback tones sin necesidad usar un servidor de aplicaciones. Más información en este mail de anuncio enviado por Bogdan.
Una de las personas de Google Labs ha desarrollado una nueva funcionalidad muy curiosa para Gmail. Esta nueva funcionalidad, llamada Mail Googles, es para evitar que envíes mails que luego te puedas arrepentir. Ponen como ejemplo evitar enviar un mail a tu ex novia diciéndole que te gustaría volver con ella
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.
Dissabte vaig anar a Girona, a la Fundació Mona, un petit santuari de primats. Ma germana n'es socia, i jo tenia ganes de veure el tinglado que tenien montat. Feien jornada de portes obertes per a socis i padrins, per ensenyar tot el que fan i deixen de fer.
A la fotografia surt un ximpance passejant-se per les instalacions.
Realment fan una feina molt dura rehabilitant els micos, i lluitant amb l'administració. El més interesant de tot son les històries personals de cada mico, el que han hagut de passar, i el pitjor de tot és que la culpa la tenim els humans :-(.
Como el año pasado, me han invitado a dar una charla en el stand de Avanzada7 en el Simo y como no tengo muy claro el tema, hago igual que Alberto Sagredo… preguntar y ver que cosas pueden interesar así que… se aceptan propuestas!! ![]()
Hace unos días, probando la parte de señalización SIP del equipo FritzBox 7170, ví que enviaba el REGISTER sin Contact y a continuación, después de recibir el 200OK por parte del proxy, enviaba otro REGISTER pero ahora si, con Contact. Pensé que sería un bug del equipo pero antes de hablar con el fabricante fuí a “la fuente”, también conocida como RFC3261
y mira por dónde, está perfectamente contemplado enviar un REGISTER sin Contact.
La finalidad de enviar un REGISTER sin Contact es que el proxy responda en el 200OK con todos los “bindings” que tiene registrados pero sin hacer ninguna modificación sobre esos “bindings” y AORs que están registrados, tal y como se explica en la sección 10.2.3 del RFC3261:
A success response to any REGISTER request contains the complete list of existing bindings, regardless of whether the request contained a Contact header field. If no Contact header field is present in a REGISTER request, the list of bindings is left unchanged.
A partir de aquí surge una duda… ¿que pasa si envías un REGISTER sin Contact y no hay ningún binding en el registrar?. Mirando de nuevo en el RFC3261, la cosa no me quedaba nada clara porque en la sección 10.3, paso 8 dice que:
The registrar returns a 200 (OK) response. The response MUST contain Contact header field values enumerating all current bindings. Each Contact value MUST feature an “expires” parameter indicating its expiration interval chosen by the registrar. The response SHOULD include a Date header field.
Y me sonaba que el BNF para un 200OK de un REGISTER decía que el Contact no podía estar vacío:
Contact = ( “Contact” / “m” ) HCOLON
( STAR / (contact-param *(COMMA contact-param)))
contact-param = (name-addr / addr-spec) *( SEMI contact-params)
Así que, resumiendo, la cuestión era que enviando un REGISTER sin Contact para un AOR que no tiene ningún binding el proxy tiene que responder con un 200OK al que tiene que añadir un Contact vacío pero a la vez el BNF dice que no puede estar vacío… raro, raro.
Como no me cuadraba nada, pregunté primero Víctor, nuestro emigrado en Berlín, y tampoco lo quedó claro así que preguntamos en la lista sip-es y nuestro RFC3261 máster, también conocido como Iñaki, coincidió con nosotros (además de Miguel Ángel y creo que alguien más) en que la definición del paso 8 en la sección 10.3 no era correcta.
El paso siguiente fue enviar la consulta a sip-implementors (gracias Víctor por ese mal tan perfecto) y los masters del universo aceptaron el bug, aunque con alguna discusión, y debería quedar corregida para la próxima versión del RFC de SIP… si llega a existir alguna vez
Como curiosidad, comentar que OpenSER cuando recibe un REGISTER sin Contact y no hay ningún binding, responde con un 200OK sin Contact, lo que es el comportamiento lógico según todo el mundo.
AG Projects ha publicado en menos de una semana, la tercera revisión de su herramienta CDRTool. Esta nueva versión, 6.6.10, corrige algunos errores relacionados con la funcionalidad de prepago y mejora la documentación.
Fa temps que sentia parlar de jocs de taula alemanys, però fins fa poc no m'he atrevit a fer el pas i comprar-me el Carcassonne. Desde llavors m'han anat regalant alguna expansió i m'he atrevit a comprar-me'n algun joc més. I ara ja tinc una petita llista a BoardGameGeek :-D.
Si voleu més informació us podeu passar pels foros de BSK.
Ya decía Russell Bryant en Twitter que los releases de Asterisk 1.6.0, 1.4.22 y DAHDI 2.0.0 estaban cerca. Son sin duda unos releases muy esperados, sobre todo Asterisk 1.6.0 y DAHDI 2.0.0.
Asterisk 1.4.22
Incluye muchos bugs solucionados, además de soportar DAHDI. En esta release se soportan tanto Zaptel como DAHDI. Podéis consultar las implicaciones que tiene este cambio aquí.
Toda lista de cambios esta disponible aquí, y podéis descargar esta versión donde siempre.
Asterisk 1.6.0
Sin duda la release más esperada. Trae muchos cambios y nuevas funcinalidades, así que es importante consultar los ficheros CHANGES y UPGRADE.
Otra de las novedades que trae Asterisk 1.6.0 además de no soportar Zaptel en favor de DAHDI: el nuevo modelo de desarrollo. En Asterisk 1.4, se mantenía un único branch para toda la versión 1.4, por lo que no se añadían nuevas funcionalidades. Esto no hacía posible la inclusión de nuevas funcionalidades hasta las major releases, por lo que tardaban demasiado en ver la luz.
Con el nuevo modelo de desarrollo se creará un branch por cada release. Actualmente ya están creados los branches para Asterisk 1.6.0 y Asterisk 1.6.1. Al contrario que en Asterisk 1.4, en Asterisk 1.6 sí que se añadirán nuevas funcionalidades en Asterisk 1.6.1, Asterisk 1.6.2 y sucesivas versiones. Se espera que el tema de el CallerID en las transferencias este solucionado en Asterisk 1.6.1, y que Asterisk 1.6.2 incluya soporte para IPv6.
Según comentaropn Russell Bryant y Kevin P. Flemming en el AstriCon, se dará soporte a las 3 minor releases anteriores, de manera que tras la salida de Asterisk 1.6.1 solo se dará soporte para las 3 últimas versiones de Asterisk 1.6.0.X. Esperemos que esto sea algo positivo…
DAHDI 2.0.0
DAHDI es el reemplazo de Zaptel ya que la marca Zaptel es propiedad de otra empresa dedicada a la venta de tarjetas minutos de telefonía.
DAHDI viene dividido en 2 paquetes, aunque es posible desacargar uno que agrupa ambos: dhadi-linux y dahdi-tools.
dahdi-linux contiene los módulos del kernel para el manejo de las tarjetas de telefonía, y dahdi-tools las herramientas que susituyen a ztcfg, zttool, etc.
Esta separaciónhace posible que si se detecta un bug en una aplicación no sea necesario hacer una release que incluya los módulos del kernel y vice versa.
Pues por fín tenemos estas nuevas versiones disponibles, aunque obviamente no recomiendo que os pongáis a actualizar a Asterisk 1.6.0 y DAHDI hoy
Un día después de publicar la versión 6.6.8, la compañía AG Projects a publicado la versión 6.6.9 de la aplicación CDRTool.
Esta aplicación usada junto a OpenSIPS/Kamailio ofrece servicios de mediación, accounting, facturación postpago y captura de señalización a través de un interfaz web de gestión.
En los 10 días que llevamos de “vacaciones” hemos aprendido algunas cosas que no aparecen en las guías turísticas y que merece la pena reseñar:
Para todo lo demás: MasterCard ![]()
Ara ja fa temps que no fico cap lletra de canço, potser perquè ultimament no escolto música nova. Aquesta doncs la fico perquè fa ben poc que m'he acabat de llegir el manga de 20th Century Boys, i realment és molt recomanable. A veure quan podre veure la pelicula. Jo sóc una 20th century girl!
Friends say it's fine, friends say it's good
Ev'rybody says it's just like rock'n'roll
I move like a cat, talk like a rat
Sting like a bee, babe I wanna be your man
Well it's plain to see you were meant for me, yeah
I'm your boy, your 20th century toy
Friends say it's fine, my friends say it's good
Ev'rybody says it's just like rock'n'roll
Fly like a plane, love like a car
Hold lots of hands, babe I wanna be your man - oh
Well it's plain to see you were meant for me, yeah
I'm your toy, your 20th century boy
20th century toy, I wanna be your boy
20th century toy, I wanna be your boy
20th century toy, I wanna be your boy
20th century toy, I wanna be your boy
Friends say it's fine, friends say it's good
Ev'rybody says it's just like rock'n'roll
Move like a cat, talk like a rat
Sting like a bee, babe I wanna be your man
Well it's plain to see you were meant for me, yeah
I'm your toy, your 20th century boy
20th century toy, I wanna be your boy
20th century toy, I wanna be your boy
20th century toy, I wanna be your toy
20th century boy, I wanna be your toy
El día 25 se publicó la versión 1.4.1 de Kamailio (ex OpenSER). En esta versión se han solucionado algunos problemas que existían en la versión anterior y se ha mantenido la compatibilidad tanto del script como de la estructura de la base de datos.
PC-BSD ha publicado su nueva versión 7.0. Esta versión está ya basada en la última versión estable de FreeBSD 7, incorpora el escritorio KDE 4.1.1, se ha aumentado el número de paquetes disponibles, más idiomas y nuevos métodos de instalación que incluyen DVD, USB e instalación por red/Internet.
Buceando por Internet, el otro día caí en esta interesante web: [www.voip0day.com] . Allí comentaban que hacía más de 30 días que habían notificado a Digium una vulnerabilidad en IAX que podía dejar Asterisk inutilizado mediante un ataque de denegación de servicio.
Hoy, Manwe y yo nos hemos puesto a probarlo, para comprobar si Asterisk se quedaba efectivamente fuera de combate. Las pruebas las hemos realizado sobre un Asterisk 1.4.21.1 (la versión que teníamos en los portátiles, cuando volvamos de las vacaciones probaremos más a fondo) pero los autores afirman que el exploit funciona con todas las versiones de Asterisk.
El funcionamiento es relativamente sencillo: el script comienza a mandar paquetes incorrectos a Asterisk y éste es incapaz de seguir procesando peticiones IAX, al quedarse completamente inutilizado. Al cesar el ataque Asterisk no se recupera, por lo que es necesario reiniciar el servicio.
El exploit lo podéis descargar aquí y para lanzarlo basta con ejecutar lo siguiente:
saghul@topux:~/apps/voip$ perl iaxControlNewAuthmethods.pl -h 10.10.10.3
siendo 10.10.0.3 la dirección IP de la víctima. Al lanzar el ataque veremos cómo se van enviando los paquetes:
Y en el servidor Asterisk, podemos visualizar todos los mensajes de error que hacen que Asterisk quede inutilizado.
Cuidado con tener el puerto 4569 abierto; os vigilo ![]()
Hace un par de días que me enteré de la exustencia de este curioso y a la vez interesante proyecto. TCAPI (Telehpony Configuration API) consiste en el desarrollo de un framework sobre el que desarrollar una interfaz de administración para cualquier softswitch, como Asterisk, FreeSWITCH, YATE, etc.
La idea es abstraer completamente el GUI de el software que haya por debajo, facilitando así el desarrollo de interfaces gráficas.
De momento el proyecto acaba de comenzar y ya hay algo de código disponible. Habrá que ver como evoluciona y si comienzan a surgir nuevas GUIs para Asterisk y demás basadas en este framework.
Podéis echar un vistazo al proyecto aquí.
¡Último día de AstriCon y posiblemente el mejor! Las charlas de hoy han sido de lo más interesantes y ha sido una lástima que no pudiéramos asistir a muchas más.
Hemos empezado mal ya que no hemos podido asistir a la primera charla de la mañana por problemas logísticos en el hotel donde estamos alojados. No pasa nada, el día iba a dar mucho de sí…
SIP From the Trenches: The Good, The Bad, And The Ugly - Kristian Kielhofner
Charla interesante donde se han expuesto las bondades de SIP y su potencia así como los problemas de implementación en el mundo real: implementaciones parciales, NAT…etc. Se ha hecho una comparativa con IAX2 y se ha discutido sobre la conveniencia de usar un protocolo u otro según las circunstancias.
Todo ello amenizado con el gran Olle que ha hecho de maestro de ceremonias durante todo el día animando las charlas y los pasillos con su peculiar personalidad
Una charla en la que no se ha descubierto América pero aún así ha merecido la pena cada segundo. Para que os hagáis una idea el ponente podría haber sido perfectamente nuestro amigo Iñaki Baz. Creemos que no hubiera disentido en nada de lo dicho
Para la tercera hora del día Manwe y yo nos hemos separado. Como Manwe es más Señor ha decidido ir a una charla de faisanes. Yo he ido a
Run-Time Dependability Monitoring System for Asterisk - Balakrishnan Dasarathy
He de confesar que no he hecho demasiado caso en esta charla ya que el tema no ha conseguido captar mi atención por completo, y he estado leyendo el correo más que otra cosa
La charla trataba sobre el desarrollo de un software inteligente que fuera capaz de detectar comportamientos erróneos de Asterisk en tiempo de ejecución, todo ello mediante máquinas de estados finitos y un software en Java. Tendré que leerme de nuevo las dispositivas cuando las publiquen…
La de Manwe ha sido
Selling the Flexibility of Asterisk: Anything You Can Do, I Can Do Better (and Cheaper)- Bryan Johns
En esta charla se hablaba sobre las dificultades de vender un software que no es un producto per se en el mismo mercado de Cisco, Avaya… etc. y demás historias comerciales que no son tan “hacker”
NAT and Firewall Traversal with STUN/TURN/ICE - Simon Perreault
Esta charla ha sido la batalla definitiva contra el NAT. Se han discutido diferentes soluciones para el maldito NAT en los clientes SIP. STUN, TURN e ICE han sido los grandes protagonistas de esta charla. IPv6 también ha salido a colación unas cuantas veces.
¿Para cuándo vamos a tener por fin una Internet con IPv6? ¡¡¡La necesitamos!!!
High Performance Asterisk - Frank Waller
Esta ha sido una de las mejores charlas de las que hemos visto en el AstriCon. Los chicos de Vicidial nos han mostrado sus experiencias con servidores Asterisk de alta carga y los problemas que se suelen encontrar. Un montón de tips and tricks para optimizar los recursos del servidor Asterisk.
Como nota curiosa, la gente de Vicidial siguen usando Asterisk 1.2 y ahora empiezan a plantearse el uso de Asterisk 1.4 en fase beta debido a que no les parecía suficientemente estable. :-O
The Asterisk Update - The Present, The Future - Kevin Fleming & Russell Bryant
Para terminar el AstriCon un repaso a lo que nos espera en Asterisk 1.6 y las nuevas funcionalidades que están por llegar en los meses venideros.
Lo que está por venir promete: Nuevas funcionalidades, nuevo modelo de desarrollo, la inclusión de chan_skype… esperemos que sea un desarrollo más estable y menos regresivo que el que hemos visto demasiadas veces en la rama de asterisk 1.4.
Tras la exposición, ha habido un largo turno de preguntas en el que todos hemos tenido la ocasión de dilucidar alguna incógnita. Una de las incógnitas del día era el precio de la licencia de chan_skype, pero por el momento, sigue siendo top secret
Pués sí, por temas de trabajo estoy estos días en Berlín… y Víctor y Jiri han tenido la amabilidad de adoptarme mientras esté aquí
Reuniones, visitas y algo de sightseeing durante el fin de semana… y mañana hay “sailing” con toda la gente de IPTelorg/Tekelec, IPTego y ex-Fokus varios!!
De momento vuelvo con noticias interesantes de AVM/Fritz que comentaré cuando me den permiso ![]()
En la charla que Stefan Öbeg ha dado esta mañana en AstriCon, ha sido anunciado un nuevo channel driver para Asterisk que permitirá la conexión con Skype. De momento es solo una beta que se esta presentando aquí en AstriCony que estará disponible para pruebas y desarrollo.
(Imagen extraída de aquí)
Los interesados podéis inscribiros aquí para recibir la beta y comenzar a probarla: [www.astricon.net]
En esta primera beta será posible realizar llamadas entre usuarios, además de transferencias y acceso a las diferentes características de la PBX, como el voicemail y usar el servicio SkypeOut para acceso a PSTN como si de un proveedor de vozip se tratase.
Al parecer aún no hay un precio establecido para su uso pero por lo que nos han comentado, será por canal concurrente muy parecido a como es el uso de las licencias de G729.
Aunque no me gusta nada la oscuridad que rodea a Skype, veo como algo positivo este acuerdo entre Skype y Digium, ya que ofrece la posibilidad a los usuarios de juntar ambos entes, y obtener lo mejor de cada uno. Como nota negativa es importante destacar que no será Open Source….
Tenéis la nota de prensa aquí.
Hoy ha sido un día largo pero interesante. Durante toda la mañana ha habido diversas charlas en al menos 3 salas diferentes de forma simultánea, por lo que hemos tenido que elegir.
Finalmente hemos asistido a las siguientes:
Benchmark test results of Asterisk as a B2BUA - Jim Dalton
En esta charla se han comentado los resultados obtenidos al emplear Asterisk como SBC (Session Border Controller) usando distintas configuraciones de hardware. Se han comparado escenarios con y sin transcoding, mirando el consumo de CPU, jitter buffers… etc.
El tema de la charla parecía interesante pero la verdad es que ha sido bastante mala, ya que algunas de las comparativas no eran justas dado el desconocimiento del ponente en algunas materias a la hora de realizar los tests.
Sinceramente creo que la charla y el ponente no estaban a la altura. Se han mostrado los resultados de unos tests arbitrarios y no se han mostrado o sacado conclusiones de ningún tipo. Las pruebas supuestamente realizadas no tenían criterio y eran de las que todos podemos hacer en un rato en nuestra casa.
Why cluster? - Leif Madsen
En esta charla se han comentado diversas posibilidades y escenarios en los cuales es necesario montar un cluster de servidores Asterisk. Esto no siempre se realiza de la misma manera, por lo que se han ido exponiendo las diversas opciones, así como las herramientas recomendadas para montar el cluster, como DUNDi, func_odbc, app_stack, etc.
La charla ha estado muy bien, ya que iba muy orientada a la práctica, y los consejos que Leif ha dado han sido muy interesantes, sobre todo en el aspeto de aplicaciones de Asterisk 1.6 backporteadas a Asterisk 1.4.
Multi-server conferencing - Matt Florell
En esta charla se han comentado escenarios en los que era necesaria una solución de conferencias de gran escala (un MeetMe de 300 usuarios, por ejemplo). Al no ser posible realizar esta funcionalidad con un único servidor Asterisk, se ha comentado la forma de repartir la carga entre varios servidores, y utilizar la aplicación Vicidial, como solución de callcenter.
De esta charla me esperaba algo guapo, en plan con app_conference distribuido o así, pero el tío ha venido a “hablar de su libro” y no ha hecho más que comentar que si Vicidial mola y bla bla bla. Al menos, cuando ha dicho que IAX mola, Olle le ha cortado diciendo: “bueno, y así termina esta charla”
How to make money with Asterisk - Steve Sokol
Realmente no queríamos asistir a esta charla, pero la han cambiado a última hora. Nosotros queríamos ir a Selling Asterisk based systems in a legacy world. Al ser de última hora, ha sido una farsa de 4 diapositivas, y cuando digo 4 digo 3+1, en la que Steve ha comentado lo que va a molar AsteriskNOW y lo fácil que va a ser y bla bla bla. Personalmente me sentía un poco extraño con mi camiseta de Debian en una sala llena de tíos con camisa a los que trataban de convencer de que CentOS es lo máximo y que yum mola, pero bueno, ya noSelling Asterisk based systems in a legacy world me la cuelan!
Automated load testing for SIP applications - Serge Kruppa
Esta ha sido una charla con bastante contenido práctico sobre SIPp. En ella se han detallado diversos casos de aplicación, y como SIPp puede ayudar a detectar errores y cuellos de botella, además de servir para dimensionar las instalaciones de Asterisk y/o OpenSER.
Al ser bastante práctica, la charla ha sido muy amena e instructiva, y Serge nos ha dado bastantes datos acerca del uso de SIPp, a través de un caso práctico que consistía en un problema que tuvo en una instalación real.
Tras las charlas…
Una vez terminadas las charlas hemos estado un rato “descansando” en el CodeZone ya que a las 19:00 comenzaba la fiesta del AstriCon! Estos americanos sí que se lo montan bien: una fiesta con bebida, salchichas, y máquinas recreativas por las que no había que pagar
Ha sido un día bastante intenso, pero muy instructivo y gratificante, así que nos vamos a dormir con los deberes hechos y el cerebro destrozado.
:wq
La empresa Transnexus ha hecho un estudio de escalabilidad con el uso de OpenSER y RTPProxy. Este estudio pretendía mostrar la relación entre la capacidad de CPU y el número de llamadas simultáneas que se podían gestionar con una calidad aceptable.
Las pruebas se hicieron usando un Dell Precision 490 con dos CPU dual core (de los que 3 estaban desactivados) a 2.33Ghz y 4Gb de RAM y SIPp como UAC/UAS para generar las llamadas. El resultado final fue que este escenario podía gestionar hasta 750 llamadas.
Repasando el informe final, me gustaría resaltar varias cosas:
- RTPProxy sólo puede usar un core de una CPU por lo que es recomendable ejecutar varias instancias de RTPProxy de forma simultánea (una por cada core de CPU)
- Una estimación interesante es que un servidor con dos CPU dual core a 3.0Ghz ofrece, de forma efectiva, 12Ghz de capacidad de procesamiento (2 CPUs * 2 cores * 3 GHz por CPU). Este servidor, usando OpenSER 1.3 y RTPProxy 1.0 sería capaz de gestionar hasta 2850 llamadas simultáneas utilizando un 95% de CPU.
- En las gráficas de paquetes RTP perdidos, round trip delay y jitter, se observa que el aumento de estos valores no es lineal sino que pasan de valores normales a valores completamente anormales en un incremento muy corto de llamadas simultáneas.
- En en informe se ha incluido la configuración de OpenSER y SIPp utilizados.
Como siempre pasa con estas cosas, en cuanto se anunció la disponibilidad del estudio han saludo algunas de las partes implicadas diciendo que el estudio era incompleto, que las pruebas están mal, que el escenario no es el correcto, que no se ha optimizado nada, etc, etc… la verdad es que es una pena que alguien dedique su tiempo a hacer unas pruebas como estas, que publique sus resultados para que luego haya gente que no haga nada más que poner problemas…
El primer día de AstriCon toca a su fín. Nos encontramos en el CodeZone ya con los ojos medio cerrados y los teclados echando humo.
Ha sido un día realmente interesante. Hemos estado de 09:00 a 16:00 en el Asterisk Developer 101 aprendiendo a desarrollar Asterisk de mano de los mejores: Kevin P. Fleming, Russell Bryant y compañía.
Posteriormente se ha abierto la sección a los expositores, donde hemos podido ver nuevos productos, además de robar numerosos bolis y conseguir una licencia de g729 y otra de HPEC gratis
Mañana más y mejor
PD: Todas la fotos en Flickr.
Aprovechando las “vacaciones” he decidido completar un poco más el script de instalación de Asterisk que hice hace algún tiempo.
He incluido algunas mejoras que varios lectores me han comentado:
Espero que os guste, y al igual que la otra vez, cualquier sugerencia será bienvenida!!
Podéis descargar el script en la sección de proyectos o aquí.
La empresa SecureLogiX, autores del libro Hacking Exposed: VoIP, ha publicado una serie de herramientas que permiten detectar y explotar diferentes vulnerabilidades relacionadas con la VoIP. Según indican, la herramienta más interesante es una llamada Call Monitor que ofrece un interfaz gráfico para las aplicaciones que permites cortar una llamada, insertar RTP y mezclar RTP en una llamada establecida… ¿os imaginais si funciona realmente? :-/
Aún no las he probado, pero espero hacerlo en los próximos días y explicar aquí que me han parecido.
Estas herramientas pueden bajarse aquí (es necesario registrarse para obtenerlas).
Mientras estabamos en Huntsville, hemos tenido la ocasión de conocer a Zoa, jefe de desarrollo de Zoiper, con el que hemos podido intercambiar impresiones, además de probar la nueva versión del software.
La nueva versión, que saldrá a la luz en forma de beta a finales de este mes, ha sido reescrita en gran parte cambiando ese apestoso Delphi por C del bueno!
Los principales objetivos de esta nueva versión son mejorar la usabilidad y la interfaz de usuario. Esta ha sido realizada con wxWidgets, y con un ojo puesto en el iPhone, que es lo que esta molando últimamente.
Como hasta ahora, se podrá disponer de una versión gratuita, o adquirir