Una de las productoras que crea programas de televisión en Australia, Fremantlemedia, ofrece una explicación sobre cómo han cambiado un sistema de comunicaciones Samsung por un sistema de comunicaciones opensource como es Asterisk.

Seguramente muchos conoceremos bastantes ejemplos de empresas que han cambiado su centralita tradicional por un Asterisk introduciendo a la empresa en la tecnología IP, pero lo interesante es que Australia es uno de los países donde el software abierto no está tan bien visto como el software cerrado y en la entrevista se comenta que poco a poco este tipo de soluciones va tomando cada vez más fuerza.

Podeis leer el artículo aquí (está en inglés):
http://www.computerworld.com.au/id1178556373

El pasado día 21 de Junio vió la luz una nueva actualización de la distribución Elastix (la versión 1.1) que cuenta con 130 paquetes actualizados además del esperado módulo “Agenda” que permitirá al usuario de Elastix acceder a una aplicación de Calendario y Directorio telefónico personal.

Adicionalmente está el módulo de directorio telefónico al que se le ha incorporado la funcionalidad de click-to-call.

Podeis descargarlo desde este enlace:
http://downloads.sourceforge.net/elastix/Elastix-1.1-Stable.iso

“Los clientes de las soluciones de Voz sobre IP (VoIP) de Avaya, Cisco y Nortel han sido alertados por unas vulnerabilidades que podrían conllevar la ejecución de código remoto, accesos no autorizados, denegación de servicio y recolección de información. Estos errores han sido encontrados por los Laboratorios VoIPshield y dados a conocer rápidamente a los tres fabricantes con el fin de que tuvieran tiempo suficiente para desarrollar los parches necesarios, según Rick Dalmazzi, presidente y CEO de VoIPshield, quien, no obstante, no ha querido facilitar más detalles dado que su compañía y los tres fabricantes afectados acordaron realizar un anuncio conjunto.”

“Eso sí, este responsable confirmaba que al menos dos de los tres nombres afectados tienen ya desarrollados los parches que solucionan estas vulnerabilidades y que el tercero de ellos (que no dicen cual es) lo tendrá en breve. Según Dalmazzi, se eligió a Avaya, Cisco y Nortel para hacer estas pruebas de vulnerabilidad porque representan la mayor parte de las ventas de centralitas IP en el mercado estadounidense. No obstante, anuncia que en las próximas pruebas se incluirá también a Microsoft, cuyos resultados estarán disponibles en unos cuatro meses, aproximadamente.”

Cuando alguien lee una noticia como esta, la mayoría piensa que pueden ser simples errores que se corrigen rápidamente y no tienen mayor repercusión, pero cuando vemos que una vulnerabilidad de este tipo que el usuario NO PUEDE solucionar por su cuenta (al ser código cerrado) y de hecho debe tener contratado un mantenimiento (en función del tamaño de la infraestructura) para tener “derecho” a actualizaciones, el problema se vuelve mucho más grave.

Dentro de 4 meses, se publicarán las vulnerabilidades del sistemas de comunicaciones de Microsoft. Las típicas centralitas basadas en Windows que, además de las posibles vulnerabilidades que se pueden llegar a encontrar (provocadas generalmente por errores en la programación, o falta de pruebas), se le añade otros que multiplican por 1000 los factores de riesgos, como son el contagio de un virus, troyanos, o simples gusanos que detecte el sistema de comunicaciones y se dedique a hacer llamadas sin parar a números 906 por las noches (por desgracia ya hay varias pruebas de virus de este tipo circulando por internet) lo que puede llegar a ser la ruina completa para una pequeña empresa.

Sin duda, malas noticias.

Cuando adelantamos las novedades que incorporaría Asterisk 1.6, comentamos que los desarrolladores se habían propuesto varios objetivos entre los que se encontraban:

- Un menor consumo de memoria

- Capacidad para funcionar en entornos realmente grandes

Cualquiera que haya seguido el desarrollo de las versiones betas que hay actualmente y que compruebe el consumo de memoria de Asterisk 1.2, Asterisk 1.4 y las betas de Asterisk 1.6, podría descubrir que Asterisk 1.2 únicamente cargaba en memoria los módulos que utiliza mientras que Asterisk 1.4 los carga todos aunque solo habilita aquellos que utiliza (una prueba de ello podeis tenerla si provocais un crash en algún módulo y con el servicio Asterisk activado, reescribis el módulo en el directorio /usr/lib/asterisk/modules, vereis como de inmediato, el sistema completo explota sin haber cargado a mano el nuevo módulo). Asterisk 1.6 vuelve a sus orígenes en cuanto a la carga de módulos y únicamente consume memoria por los módulos que realmente se utilizan (algo que era evidentemente necesario).

Ahora parece que se están centrando en mejorar la integración de Asterisk en sistemas clusterizados (varios sistemas que virtualmente se comportan como uno solo multiplicando sus capacidades de procesador, memoria, espacio, y un largo etcétera.)

Concretamente, uno de los primeros objetivos en este sentido es el de propagar la información de los usuarios (libres, ocupados, hablando, no disponible, etc.) entre los distintos servidores que forman el cluster.

Para ello, el equipo de desarrolladores de Asterisk están utilizando un framework especial para programar en este tipo de infraestructuras llamada OpenAIS y así han creado un nuevo módulo llamado res_ais que permite controlar el estado de una extensión situada en otro Asterisk perteneciente a uno de los nodos del cluster.

El siguiente paso será propagar esta información a través de Asterisk conectados entre sí por el protocolo DUNDi.

Más información: http://lists.digium.com/pipermail/asterisk-commits/2008-June/023400.html

En el blog de Bytecoders leo que Brandon Kruse, desarrollador de Digium, acaba de publicar una versión de Asterisk basada en Asterisk 1.4.17 para el entorno libre OpenMoko y ser ejecutado en dispositivos móviles que funcionen con esta plataforma.

OpenMoko es un sistema operativo basado en Linux y especialmente dedicado a móviles, pdas y demás dispositivos empotrados.

Aquí podeis ver la página oficial de OpenMoko

Por supuesto, tener un Asterisk en el móvil no es que sea muy práctico, aunque es cierto que vuelve a demostrar la flexibilidad tanto de Asterisk como de cualquier aplicación Linux en cuanto a compatibilidad con los sistemas hardware y sus diferentes arquitecturas.

Aquí teneis la página del proyecto Asterisk para OpenMoko.

Esta semana, siguiendo los hilos de la lista Asterisk-Dev, me he encontrado con un anuncio que marqué para analizar cuando tuviera más tiempo. El anuncio lo daba Matthew Fredrickson de Digium, ya que es uno de los desarrolladores que se ocupa de mantener al día el paquete Zaptel y el LibPRI.

Concretamente, el anuncio iba sobre el nuevo paquete LibPri (1.6.0) así lo anunciaban aunque finalmente ha pasado a ser el LibPri 1.4.4 y que incluye dos añadidos bastante interesantes que explicaré ahora.

- Soporte de tarjetas RDSI Bri:
Algo que iba siendo hora, ya que en la actualidad, el soporte de RDSI Bri está en mano de mISDN y aunque es un driver que suele funcionar bien, el hecho de incorporar el soporte BRI al Zaptel es algo que mejora la “centralización” en la corrección de bugs, algo que actualmente no se hace.
Si hay algún bug en mISDN, los encargados de arreglarlo son los desarrolladores de mISDN, no los del paquete Zaptel, aunque si el error está en el archivo ‘chan_misdn’ entonces sí.
De momento, creo que solo permiten modo Punto-multi-punto.

- Soporte de TBCT/2BCT en QSig:
Esto es algo muy interesante, que muchas personas lo han pedido y hasta ahora únicamente funcionaba en pocos sistemas.
Cuando conectamos Asterisk a una PBX con extensiones, y estas extensiones se llaman entre sí, la llamada no tiene porqué llegar a Asterisk, pero si la llamada, después de una transferencia comienza y acaba en la PBX, Asterisk pasa a ocupar dos canales (uno para el origen y otro para el destino).
Con el soporte TBCT, Asterisk reconoce que el origen y el destino vienen de la misma PBX y puentea los canales liberando ambos canales ocupados, permitiendo que el tráfico no llegue a Asterisk.
Llevan preparando esta feature desde la Astricon del 2005.

Podeis descargar esta versión aquí:
http://downloads.digium.com/pub/libpri

El protocolo SIP (que significa Protocolo de Iniciación de Sesiones) nació en 1996 cuando Mark Handley y Eve Schooler presentaron el primer borrador ante la IETF de lo que sería un protocolo de comunicaciones IP que solucionaría gran parte de los inconvenientes de protocolos anteriores.

En este borrador se exponían conceptos nuevos y que posteriormente pasaría a utilizarse en todo el mundo como uno de los protocolos más utilizados en las aplicaciones de mensajería instantánea, aplicaciones CRM, ERP y por supuesto VoIP. Entre estos nuevos conceptos destaca alto tan básico como el “registro”, por el cual un usuario informaba a la red dónde podía recibir invitaciones de comunicaciones por parte de otros usuarios, lo que permitía que un usuario pudiera recibir un mensaje en su casa y si luego se trasladaba al trabajo y se “registraba”, el mensaje lo recibiera en el trabajo y no en su casa.

El protocolo SIP es un protocolo de señalización, es decir, SIP no transporta audio ni vídeo, por lo que sería incompleto decir que en una comunicación de VoIP en SIP solo interviene este protocolo que se transmite por el puerto 5060 TCP o UDP.

Entonces ¿como se puede enviar audio y vídeo por SIP?. Sencillamente, no se puede, SIP no está diseñado para esto, aunque sí que permite indicar el sistema y el puerto por el que se puede enviar un flujo de datos que encapsula la voz y el vídeo. Para este flujo de datos se utiliza otro protocolo: SDP (que significa “Session Description Protocol” en español “Protocolo de Descripción de Sesiones“) y envía los parámetros de inicialización de audio y vídeo transmitidos por streaming por varios puertos UDP altos (por encima del 1024)

La comunicación SIP se realiza entre lo que se denominan “Agentes de Usuario SIP” comúnmente conocido como “usuario SIP”, “Servidores de Registro” también conocido como “SIP Server” y “SIP Proxy” también conocido como “SIP Proxy”

- Usuarios SIP:
Un usuario SIP puede ser una aplicación de mensajería, un softphone, un teléfono IP, y en general cualquier dispositivo o software que sea compatible con SIP y que tenga la capacidad de “registrarse” con una cuenta SIP. Los usuarios SIP reciben una URI formada por “usuario”@”dominio” donde el campo dominio se corresponde con el Servidor SIP donde se encuentra registrado.

- Servidor SIP:
Un servidor SIP es una aplicación o dispositivo que permite crear y gestionar cuentas SIP y permitir que los Usuarios SIP se “registren” almacenando la dirección IP donde deben acceder para realizar la comunicación con este usuario.

- Proxy SIP:
Un Proxy SIP es una aplicación que permite que cualquier usuario SIP envíe un comando a otro usuario SIP.

Con estos tres conceptos claros, empieza la parte divertida, cuando dos usuarios SIP quieren hablar entre si, hace falta:
- Dos usuarios SIP (100@dominio y 200@dominio)
- Un servidor SIP donde se registrarán los dos usuarios
- Un proxy SIP para enviar los paquetes necesarios desde uno de los usuarios al otro para empezar a establecer una comunicación.

Una vez establecida la comunicación, el envío de los paquetes streaming de audio y vídeo se realiza únicamente y exclusivamente entre la aplicación registrada como 100@dominio y la aplicación registrada como 200@dominio, por lo que queda demostrado que SIP es un protocolo P2P tan mal visto por los medios de comunicación.
En este caso, el usuario 100@dominio también podría iniciar la comunicación introduciendo el usuario 200@direccionIP donde “direccionIP” sería la que tuviese ese usuario en ese instante. ¿pero qué ocurre cuando el usuario cambia de IP? ¿Perdemos la posibilidad de llamarle? Justamente para eso sirve el servidor SIP y el Proxy SIP.

Aprovechando estas definiciones interesantes, me gustaría aclarar algunas más relacionadas con la VoIP:

- B2BUA (Back 2 Back User Agent)
El B2BUA es una aplicación para controllar llamadas entre usuarios SIP y se diferencia de un Proxy SIP en que este únicamente gestiona el estado de una llamada cuando se realiza, mientras que el B2BUA mantiene el estado de las llamadas y las mantiene para conseguir información valiosa en determinados entornos como facturación, redireccionamiento de llamadas en caso de caída de un proveedor SIP, etc.
Asterisk es mucho más que un B2BUA ya que no únicamente controla todo esto, si no que incluso puede llegar a realizar acciones que ni un Proxy SIP ni un B2BUA pueden realizar como: grabaciones de llamadas, sistemas de buzón de voz, reproducción de locuciones, ofrecer menús IVR, reproducir música en espera, y un larguísimo etc.

- Media Gateway (MGW)
El Media Gateway es una aplicación o dispositivo que convierte la señalización SIP y el audio streaming, recibidos por SIP en el formato necesario para que sea transportado por otra “tecnología” como líneas analógicas, digitales, diferentes protocolos IP, etc.

- Softswitch
El Softswitch es una aplicación o dispositivo que realiza las labores de un Proxy SIP y un Media Gateway.
Ejemplo de softswitch es el conocido FreeSwitch al que además le han añadido algunas opciones más típicas de centralitas.

- PBX
Un PBX es una centralita basada en la red telefónica (analógica, digital o incluso móvil) que realiza las acciones que ya conocemos de toda centralita: gestionar transferencias, programar menús IVR, grabar conversaciones, etc.

- Media Server
Un Media Server es un dispositivo o aplicación que permite almacenar contenido multimedia (audio, vídeo, imágenes, etc…) y que puede enviarla mediante algún tipo de protocolo sin importarle a quien.
Es un reproductor de contenido multimedia que se conecta a cualquiera de los sistemas que he mencionado con anterioridad y ofrece este contenido a uno o varios usuarios.
Tras esta breve explicación, espero que estos conceptos hayan quedado más claros y evitar utilizar una aplicación para realizar tareas más propias de otras.

Bueno, pese a tenerlo instalado bastantes personas, ahora resulta que acaba de salir la versión 1.0 estable de Elastix.

Parece que de momento no lo han publicado en la página web, aunque en la lista de Asterisk-ES ya se han hecho eco.

Los cambios con respecto a la versión candidata anterior (RC2) son:

Version 1.0 Stable (Apr. 14 2008)
- Module Extension Batch changed to support more parameters of VoiceMail.
- Module GroupPermissions: Do not permit change the permissions of modules administratives to administrator group.
- In elastix.spec maintenaince, lines of create folder faxvisor comments, this folder is in source elastix.
- New language Catalan.
- Update module Hardware Detection, now zapata.conf is more complete.
- Add zapata.conf custom by elastix, in rpm freePBX.
- Maintenaice of rpm elastix
-a2billing, name format changed. And validation directory /var/lib/asterisk/sounds/en/ exists.
- Updating rhino packages to 2.2.5.3 version.

Podeis descargarlo desde aquí:
http://downloads.sourceforge.net/elastix/Elastix-1.0-Stable-10abr2008.iso

Primero fue Siemens, ahora le toca el turno a Ericsson.

Leo en Sipcat que Aastra acaba de adquirir la división de PBX de Ericsson por 102.7 millones de dólares.

Como ya advertí en el stand de Asterisk del SIMO, las empresas de telefonía tradicional están viendo cómo el modelo de negocio basado en hardware y software cerrado está llegando a su fín y prefieren vender antes de arruinarse intentando competir con un sistema muy difícil, el basado en estándares abiertos y software libre, a la vez que sus eternos competidores como Cisco, Avaya y Nortel continúan dedicando esfuerzos y dinero en el desarrollo de sistemas más económicos para competir contra el modelo de negocio basado en software libre.

Cisco ya compró Linksys para hacer frente a la demanda de sistemas de bajo coste, y las otras dos… pues seguro que harán algo similar o quedarán a la espera de ser comprada por otra empresa con ganas de continuar esta andadura.

Lo que queda claro, es que la telefonía tradicional está en peligro de extinción para todos aquellos que quieran seguir viéndola como una inversión de futuro.

Vía:  Sipcat

Tal y como predije hace algún tiempo, la empresa que defendía la telefonía tradicional y menospreciaba el auge que estaba teniendo la VoIP el pasado año: Siemens, acaba de anunciar el despido de los 6.800 empleados de su fábrica de centralitas Gigaset. Está claro que Siemens tiene más modelos, pero esta ha sido solo la primera. Siemens dejará de fabricar físicamente las centralitas y se reconvertirá en un proveedor de servicios IP. Toda una línea de negocio industrial desaparece en Siemens.

Hacía tiempo que ya sabía de este rumor y más aun cuando uno de sus técnicos me hablaba de que iba a asistir a un curso ofrecido por Siemens sobre VoIP meses después de que otro técnico hubiera ido a ese mismo curso y no sabía ni los protocolos básicos de la VoIP (y no me estoy refiriendo a Skype).

La verdad es que esta puede ser una de las noticias de la semana, ya que en todo el mundo hay técnicos Siemens especializados en centralitas tradicionales que van a notar una disminución bastante aguda de sus clientes.

Más información: http://www.euronews.net/