Elio Rojano trabaja actualmente en una de las empresas pioneras de Asterisk en España dando soporte y llevando a cabo proyectos de VoIP desde hace más de 4 años.
Mi colega Sergio Serrano me ha comentado hoy que acaba de publicar el último parche para el one-button-pickup para el Thomson ST2030 en Asterisk.
Los terminales Thomsons disponen de serie de 10 teclas de función que sirven tanto para recibir llamadas simultaneas y mantenerlas a la espera como para monitorizar otras extensiones mediante la función BLF (Blink Light Function). Estas teclas se enciende cuando una extensión está hablando o parpadeando cuando están sonando.
Cuando una extensión remota recibe una llamada, la tecla de función parpadea y gracias al último parche de Sergio, pulsando esa tecla se puede capturar la llamada que está sonando en esa extensión.
Puede que la noticia no sea nueva para muchos seguidores de las noticias sobre Asterisk y VoIP, pero ando poniéndome al día y hay noticias por las que hay que pasar.
En el Astricon que acaba de terminar Digium ha anunciado un nuevo proyecto de colaboración con una empresa que todos conocemos bastante bien: Skype.
Este proyecto consiste en un nuevo canal compatible con Skype para conectar esta red a Asterisk de forma similar a la que ya hace Asterisk con servicios como GoogleTalk, y de hecho las reacciones no han tardado en llegar.
Skype es un mal protocolo a nivel de red (aprovecha el ancho de banda del cliente para transportar audio a terceros) pero muy bueno para traspasar firewalls (lo cual puede hacer que en empresas el administrador de red lo vuelvan loco), podría abrirse un debate sobre las ventajas y desventajas de utilizar este sistema partiendo de la máxima que es un protocolo cerrado y propietario de una empresa, y esta dependencia nunca es buena.
El funcionamiento es similar al del canal chan_gtalk únicamente cambiaría el ‘gtalk’ por ’skype’ por lo que para hacer una llamada únicamente habría que enviarla así:
exten=>1001,1,Dial(Skype/1001.dominio)
La verdad, a mi no me termina de convencer, aunque entiendo el motivo por el que lo han hecho (hay muchos productos bastante chapuceros de conexión de Asterisk con Skype, por lo que es notable que hay interés en algo así) - comento lo de chapucero, porque el hecho de que un “chan_skype” requiera de un sistema con Windows para utilizar la API de Skype, es una chapuza -.
No obstante, y manteniendo la objetividad de un producto que no conozco por el momento, me gustaría conocer alguna opinión al respecto… y obtener alguna respuesta a estas preguntas:
- ¿Piensas que este producto tendrá el éxito esperado?
- ¿Cuánto serías capaz de pagar por utilizar un canal como este?
- ¿Crees que SIP podría llegar a convertirse en un protocolo de Comunicaciones unificiadas potente y abierto antes que otras empresas invadan este terreno?
Cualquiera que vea el ranking de usuarios de Asterisk puede darse cuenta que tras EEUU y España, los países con más usuarios de Asterisk pertenecen a un conjunto de países donde existe una señalización de primarios llamada MFC/R2 y que, a pesar de ser muy conocida en estos países, en EEUU y en Europa no lo es tanto por lo que, en teoría los desarrolladores existentes en los países implicados se encuentran a menudo solos, ante una señalización especial y no contemplada desde un principio por el desarrollo original de Asterisk.
El creador del SpanDSP (Steve Underwood) es incluso más conocido por desarrollar un canal que ofreciera el soporte necesario para permitir la compatibilidad con esta señalización. Steve se encontró inmerso en muchos proyectos y no tenía capacidad para continuar con este soporte por lo que lo terminó dejando de lado y eso hizo que muchos usuarios y empresas se encontrasen con grandes dificultades para soportar esta señalización.
Hace algún tiempo, buscando información sobre señalización MFC/R2 para primarios en Angola (como ex-colonia de Portugal, mucha tecnología proviene de Portugal y esta a su vez de Brasil) me encontré con un blog de un mejicano llamado Moises Silva (moythreads.com) que además de ser usuario y desarrollador de Asterisk, es el principal desarrollador del proyecto chan_unicall que dota de soporte para la señalización MFC/R2 continuando el trabajo que comenzó en su día Steve Underwood, y más tarde reescribiendo un stack de R2 nuevo e integrándolo en chan_zap, asi no es necesario usar chan_unicall ni unicall, libmfcr2, spandsp y demás librerias.
Ahora leo en el blog de Digium un breve homenaje a Moises a modo de agradecimiento por su tiempo y esfuerzo y sobre todo, por ofrecerlo con libre para la comunidad de Asterisk, algo que es digno de admiración y de agradecimiento por parte de todos.
A propósito, comentar que Moises Silva estará en la Astricon 2008 para dar una charla sobre el soporte de MFC/R2 en Asterisk.
Como Telefónica me ha dejado sin conexión en el servidor, no he podido compartir la noticia que publicó Bytecoders y es que Jay Phillips, principal desarrollador del proyecto Adhearsion framework para facilitar la programación en Asterisk con el lenguaje Ruby además de hacerse aún más conocido si cabe por sus cartas abiertas dirigidas a Mark Spencer, ofrecerá un webminar sobre la programación de aplicaciones nativas VoIP a través de Asterisk en Ruby.
- 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.
En las empresas pequeñas no suele ser lo habitual tener un IVR, aunque en empresas medianas o grandes es recomendable e incluso muy necesario disponer de un sistema que permita al llamante seleccionar el departamento, la persona o incluso acceder a información personal a través de lo que se llama “IVR” aunque comúnmente también se denomina “menú”. IVR (Interactive Voice Response) en español (Respuesta de voz interactiva).
Asterisk, al disponer de una programación del dialplan totalmente personalizable gracias a la infinidad de métodos disponibles para gestionar una llamada, dispone de un potencial asombroso para crear menús tan sencillo o complicados como uno quiera.
A medida que la empresa va creciendo o dispone de más servicios de cara al cliente, va aumentando el tamaño del menú de entrada de su sistema, así por ejemplo todos conocemos los IVR de las operadoras de telecomunicaciones que interactúan con la voz (ni siquiera es necesario pulsar un dígito) y nos llevan a diferentes menús según la opción elegida.
Cuando programamos en el ‘extensions.conf’ un IVR por lo general suele ser sencillo, ya que más de tres submenús empieza a parecer bastante tedioso hacer modificaciones y si tenemos que añadir una opción al segundo submenú con otro menú incluida las locuciones correspondientes, puede llegar a convertirse en todo un desafío.
A medida que el menú en el dialplan se va complicando, uno empieza a ver con buenos ojos algo que escuchó sobre el VoiceXML que permitía programar menús IVR de una forma bastante más sencilla y segura.
El VoiceXML no únicamente sirve para gestionar menús, también sirve para conectar a un TextToSpeech y a un ASR de manera que pueda hablar y escuchar a la persona que está al otro lado de la línea y poder realizar acciones y comandos en base a lo que diga o haga, pero esto es otro tema del que ya hablaré en otro momento.
Si además de permitirnos menús más serios, disponemos de un Asterisk con soporte de Videollamada 3G conectado a una línea RDSI (Básica o Primaria), entonces los resultados son altamente espectaculares.
En la lista de desarrolladores de Asterisk, Russell Bryant acaba de enviar la noticia de que acaba de crearse la rama de Asterisk 1.6.0 en el servidor de Subversion, por lo que no se admitirán más novedades de momento hasta que se terminen de solucionar algunos bugs que se han encontrado (12130 y 11972) tras lo cual empezarán las versiones candidatas a ser estables RC (release candidates).
Por lo que tenemos una versión pre-release-candidate (vaya nombre) que será revisada una y otra vez solucionando tantos bugs como se pueda y se encuentren para que la primera versión estable de Asterisk 1.6 sea realmente estable y no haya que esperar a versiones posteriores para empezar a implementarlas en sistemas en producción.
Cuantos más bugs se encuentren más estable será, así que animo desde aquí a todos los que puedan que la prueben y envíen log bugs a http://bugs.digium.com para colaborar en la estabilidad de esta nueva versión.
Leyendo la lista de Asterisk-Dev he visto una referencia a una librería que puede ser muy interesante para aquellos que quieran realizar aplicaciones en C que interactúen con el Manager de Asterisk.
La librería en cuestión se llama libami, y aunque la conexión con el AMI sea tan sencillo como conectarse a un puerto TCP, la utilización de este tipo de librerías puede facilitar bastante su programación y la gestión de eventos.
Podeis descargarlo desde su web: http://www.intuitivecreations.com/contributions/AMS/shots.php
PortSIP es una empresa que ha desarrollado unas librerías para que cualquier programador de Visual Studio (Visual Basic, Visual C++), Delphi C# o incluso JavaScript/HTML, pueda programarse su propio softphone de una manera mucho más sencilla y cómoda.
Estas librerías soportan:
Códecs G.711a, G.711u, iLBC, G.723, G.729 y GSM 6.10.
Videoconferencia con H.263 y H.264.
DTMF2833 y SIP INFO
Las SDK de PortSIP son comerciales, aunque podemos descargar una versión limitada para hacer nuestras pruebas. Esta limitación consiste en que únicamente permiten 3 minutos de audio/video y que el software no podrá ser distribuido, vendido, etc…
Mi colega Sergio Serrano me ha comentado hoy que acaba de publicar el último parche para el one-button-pickup para el Thomson ST2030 en Asterisk.
Hace algún tiempo, buscando información sobre señalización MFC/R2 para primarios en Angola (como ex-colonia de Portugal, mucha tecnología proviene de Portugal y esta a su vez de Brasil) me encontré con un blog de un mejicano llamado Moises Silva (
