Asterisk 1.8.5 Released! ¿Adiós a los bloqueos de canales SIP?

Han tardado, pero la espera ha merecido la pena.

Por fín está disponible la versión de Asterisk 1.8.5 donde han corregido algunos bugs importantes como el bloqueo de canales cuando se realizan transferencias atendidas mediante SIP, y en determinadas configuraciones de conexiones mediante TCP/TLS.

Porqué encontramos bugs en versiones estables

 

Asterisk es uno de los proyectos software orientados a comunicaciones más grandes que existen actualmente, por este motivo, es uno de los proyectos en los que la comunidad tiene más importancia de la que normalmente suele tener en estos proyectos dirigidos por empresas en los que se “inyecta” dinero para pagar a desarrolladores con objeto de continuar el desarrollo y solucionar los distintos fallos que se van encontrando continuamente. Cualquiera que haya estudiado programación, recordará que un programador puede, mediante un diseño estructurado, y una buena planificación, técnica y pruebas, evitar la aparición de bugs, pero jamás se puede garantizar la “no existencia” de estos, por lo que una vez entregado el proyecto, es común que los usuarios continúen aportando su “granito de arena” ofreciendo el famoso “feedback” consistente en comentarios acerca del buen o mal funcionamiento de las características de una aplicación software.

Asterisk, como gran proyecto formado por cientos de archivos, módulos, librerías y un largo etcétera, necesita continuamente el “feedback” de sus usuarios con el objeto de identificar tan pronto como sea posible cualquier comportamiento anómalo, no contemplado y perjudicial para la mayoría de los usuarios, por lo que se pone a disposición de todo el mundo, diferentes versiones -inicialmente inestables- de forma que los usuarios puedan probar dicha versión antes de que se convierta en una versión considerada como estable, pero ¿porqué si existen métodos de detección de errores antes de publicar una versión estable, encontramos bugs en estas últimas?

 

Existe unas versiones conocidas como “team“: http://svn.digium.com/svn/asterisk/team/ en las que los desarrolladores ponen a disposición de los usuarios versiones de Asterisk con nuevas características que estos han solicitado o que el desarrollador quiere implementar en Asterisk. De esta forma, lo que se busca es que los usuarios interesados en estas características, descarguen, prueben y verifiquen junto con el desarrollador que el funcionamiento de las nuevas características son correctas y lo más estable posible (considerando que los usuarios interesados son minoría).

Una vez verificado el funcionamiento de la nueva característica, los cambios que la conforman, son aplicados a una versión “inestable” llamada “Trunk“: http://svn.digium.com/svn/asterisk/trunk/. Esta versión es considerada la “versión de la comunidad” ya que si alguien quiere aportar su grano de arena en la evolución de Asterisk, esta es la versión que puede utilizar para la caza de bugs de forma que cualquier usuario que pruebe la versión Trunk y descubra un bug, debería informar sobre él (y sobre todo, cómo ha conseguido reproducirlo) en la webhttps://issues.asterisk.org/. De esta forma, y tras solucionar los bugs de la versión “trunk”, la versión “estable” (branch) ya no incluirá los bugs más fáciles de reproducir.

Ahora bien, a modo de autocrítica, comentar que el 90% de los usuarios de Asterisk jamás han instalado la versión Trunk, el 99% de los usuarios jamás han informado de un bug en la web https://issues.asterisk.org/ pero eso sí, cuando han encontrado un bug, la gran mayoría preguntan en foros, listas y webs para buscar una solución rápidamente ya que la detección ocurre cuando han realizado una instalación a un cliente y este empieza a enfadarse, lo que nos lleva a varias conclusiones:

1.- La mayoría de los usuarios de Asterisk únicamente les interesa el producto (ad hoc) y no tienen interés en colaborar instalando versiones “inestables” y reportando los bugs que se detectan. Es decir: lo mismo les daría utilizar Asterisk, un sistema propietario, comercial o incluso una solución franquiciada tipo centralita-de-toda-la-vida, mientras eso agrade al cliente y sea rentable económicamente.

2.- Una gran cantidad de supuestos profesionales, no prueban las necesidades del cliente ANTES, y por lo tanto se encuentran con los bugs cuando están en medio de la implementación (lo que se conoce coloquialmente como ‘en casa del cliente’). Esto puede ser tanto porque no se conocen bien las necesidades del cliente hasta el último momento (lo que implica una mala gestión) o bien porque el cliente cambia sus necesidades en el último momento (lo que implica un fallo en la parte de consultoría).

3.- Otro motivo puede ser la imposibilidad de hacer pruebas, bien porque el usuario de Asterisk no disponga en sus instalaciones de los recursos necesarios para estas pruebas (un simulador de líneas), tiempo suficiente o los conocimientos necesarios para simular la instalación en local ANTES de comenzar la implementación en el usuario final.

4.- Por último (y quizá este sea el  motivo más común) es que se peca de exceso de confianza, considerando que una versión “estable” ya ha sido probada por suficiente gente y por lo tanto, se puede ahorrar el hecho de revisar si todo funciona como debería ya que -“¿porqué va a fallar algo que ha estado funcionando perfectamente en todas las versiones anteriores?”- Una mezcla entre confianza ciega,despreocupación y cierto grado de vagueza que provoca que en el último momento, cuando el “cliente final” haga de betatester involuntario de la versión estable que le han instalado y configurado, descubra con una gran sorpresa que aquello que le dijeron que funcionaba, no lo hace como esperaba. Está claro que si esta es la razón del porqué existen bugs en las versiones “estables”, no es culpa de los desarrolladores, si no de varios motivos, empezando por aquellos usuarios que no han probado la versión Trunk lo suficiente, continuando por el usuario que instala el Asterisk y que no ha verificado que todo funcionaba correctamente y por último del cliente final por haber seleccionado a una empresa que no es todo lo responsable que debería.

Por estos motivos, y como siempre se suele decir: más vale prevenir que curar, se podrían dar varios consejos para evitar situaciones embarazosas a la vez que se colabora en la estabilidad del proyecto Asterisk:

• - Intentar obtener todos los datos posibles sobre las necesidades del cliente, configuraciones completas, terminales, funcionamiento estandar del sistema y elaborar una lista completa de “pruebas” de calidad que la solución deberá pasar antes de iniciar la implementación sin “obviar” ninguna características por muy probada que esté y muy común que esta sea. (por ejemplo: no es la primera vez que aparece una versión de Asterisk donde no funciona el Pickup y se detecta demasiado tarde por no haber hecho una simple prueba de 10 segundos).


• - Intentar formarse tanto técnica como comercialmente para conocer lo que se ofrece, conocer las limitaciones y las ventajas frente al resto de sistemas para evitar ofertar lo que no se sabe hacer y hacer el ridículo cuando el cliente vea cómo preguntan en las listas acerca de algo que en la página web de la empresa se dice que se domina perfectamente.


• - Intentar simular tan exactamente como sea posible toda la instalación de forma escalada (no hace falta desplegar 500 terminales SIP) pero sí probar todas las características de cada modelo de terminal y verificar la versión de firmware que cumple con todas las características que promete el fabricante.


• - Cuando se detecte un error en Asterisk, lo primero que hay que hacer es preguntar en las listas de usuarios (asterisk-users y Asterisk-ES) por si es un fallo de configuración  o bien es un verdadero “bug” de Asterisk, en cuyo caso debemos informar de este en https://issues.asterisk.org/, por lo que deberíamos analizar los pasos que hemos realizado y que nos ha producido ese error, de forma que los desarrolladores puedan reproducirlo y descubrir dónde está el error. En caso de que sea realmente un bug, serás recompensado como colaborador bug-hunter de la próxima versión estable. Por este motivo siempre es recomendable cazar los bugs en la versión “trunk”… para evitar que lleguen a la versión “estable”.

Así que la próxima vez que veas a alguien quejarse de que la versión estable tiene algún bug, párate a pensar por un momento la cantidad de personas que han descargado la versión anterior Trunk, y no lo han detectado, seguramente te de una idea de la cantidad de personas que, aun utilizando Asterisk, aprovechándose del trabajo de cientos de desarrolladores que dedican horas de forma totalmente desinteresada a este proyecto, realmente contribuyen a su desarrollo.

En una conversación en un grupo de usuarios de linux hubo una frase que me llamó la atención:

-”En el mundo del software libre, hay dos tipos de empresas: las que contribuyen de una forma u otra en el desarrollo del software libre, y las que únicamente les interesa la gratuidad del producto intentando conseguir todo el jugo posible del esfuerzo de los demás, pero que cuando les toca a ellos desarrollar algo, lo hacen como software privativo para que nadie más pueda usarlo.“

Fuente: Sinologic.net

Release de AppKonference 1.6

En VentureVOIP nos comentan que ya esta lista la nueva release de la aplicación appkonference la cual según su autor trae los siguientes cambios:

* Deprecated input smoothing and output packing because packet size is fixed at 20 milliseconds so these functions are unnecessary.

* Added a compiler flag, CACHE_CONTROL_BLOCKS, for conference and member block reuse. To disable control block reuse edit the Makefile or clear it on the command line: make CACHE_CONTROL_BLOCKS=0.

* Changed the conference event privilege to user to reduce the number of events an application has to monitor to support a conference.

Si quieren probarlo lo pueden bajar de source forge: sourceforge.net/projects/appkonference

Lo que traerá Asterisk 1.8

Elio Rojano nos trae un artículo con algunas mejoras que traerá Asterisk 1.8, les recuerdo que esta planeada su salida para el segundo trimestre del 2010.

Estos días en los que la publicación de Asterisk 1.8 está tan cerca, hemos empezado a comentar algunas novedades con respecto a qué es Asterisk 1.8, y algunas de las características que se han hecho públicas en distintos medios de Internet.



Esta versión es quizá más esperada de lo que la mayoría de usuarios creen y aunque las distribuciones enlatadas están empezando a plantearse Asterisk 1.6, es un movimiento complicado ya que en cuanto aparezca Asterisk 1.8 va a traer tantas modificaciones que para el usuario final que no haya trabajado antes con Asterisk 1.6, le va a resultar especialmente complicado adaptarse a esta nueva versión.

No obstante, hemos hecho una recopilación de las principales novedades y las hemos reunido en este artículo para que cualquiera que esté interesado en adentrarse en esta nueva versión y que conozca bien las anteriores versiones, pueda darse cuenta de lo que va a tener que aprender si va a querer aprovechar al máximo las características de esta nueva versión.

Por supuesto, los cambios son principalmente internos a nivel de desarrollo, aunque me ha llamado la atención algunas de las novedades que Kevin P. Flemming anunció que está planteado incluir en Asterisk 1.8 que como mínimo son impresionantes…

Vamos a verlas…

• Soporte para el tan esperado “cifrado del audio” mediante SRTP será añadido finalmente al chan_sip.


• Soporte para PacketCable NCS 1.0 para redes Docsis/Eurodocsis en MGCP del que ya anunciamos el desarrollo.


• Añadidas nuevas opciones para el modulo chan_spy:
  
  
  
  • Añadida opción c() para permitir DTMF para seleccionar el próximo canal disponible a escuchar. Por defecto actualmente es ‘*’.
  
  
  • Añadida la opción x() para salir de la aplicación al pulsar una tecla.
  
  
  • Añadida la opción S para salir de la aplicación cuando no haya más canales a los que poder escuchar.
  
  
  • Añadida la opción E para escuchar un canal y salir de la aplicación cuando este canal finalice.
  
  
  
  


• La aplicación Meetme dispone de una función DENOISE() que elimina el ruido de fondo y obtiene sonido más límpio.


• Soporte para el nuevo interfaz CEL (Channel Event Logging), se introduce oficialmente aquí. CEL loguea todos los eventos tal y como lo hace el AMI, pero CEL está más orientado a lo que hace el CDR.


• Soporte de integración con calendarios. Nuevas aplicaciones permitirán obtener fechas y ejecutar acciones cuando ocurran eventos programados en el calendario.


• El nuevo motor RTP permitirá Multicast, ideal para cuando trabajamos con altavoces que escuchan este tipo de paquetes y queremos lanzar avisos.


• Para el app_queue, ahora se puede especificar la posición en la que un llamante ingresa en la cola y así poder dar prioridades a ciertas personas que entren en la cola.


• Soporte para actualizar dinámicamente la información de una llamada. Esto permitirá cambiar parámetros como el CallerID durante una llamada, ideal para cuando hacemos una transferencia o un desvío.


• Añadida una nueva característica llamada “call completion” o “informe de llamada” que permite a un usuario informar a otro que está disponible cuando deje de estar ocupado.


• Mejora del soporte de faxes que ya comentamos en este post.


• Soporte nativo para IPV6 (por fín!).

Además de todas las novedades de las últimas versiones de Asterisk 1.6 (que no son pocas).

Aunque quizá lo más interesante de esta nueva versión, es la forma en la que se desarrolla, el esperado LTS (Long Term Support) y que viene a ser que durante varios años se mantendrá y funcionará una única rama: Asterisk 1.8y las modificaciones y correcciones se harán siempre en la misma rama de forma que tanto los desarrolladores como los usuarios se centrarán en mejorar esta única versión, por lo que se espera que esta versión sea además de la más completa, la más estable de las actuales (incluso más estable que la 1.4) ya que durante el desarrollo de las últimas versiones de la 1.4, muchos desarrolladores empezaron modificar la nueva versión 1.6 y por esto, dejaron de lado a la rama más estable y se centraron en las nuevas características que hay actualmente