Categoría: Noticias

  • Cómo instalar una tarjeta RDSI BRI con DAHDI

    Un poco de Historia …

    Billion RDSI

    Las líneas RDSI Básicas siempre han sido una gran alternativa a las líneas analógicas por muchos motivos: flexibilidad, calidad de audio, ausencia de ruidos, ausencia de problemas de eco, y un largo etcétera que forman una de las mejores alternativas calidad-precio para aquellas empresas que quieren tener varias líneas con el mismo número.

     

    No obstante, el hecho que en EEUU y en algunos países de sudamérica las RDSI Básicas (también conocidas como BRI) no sea un tipo de línea muy extendido ha hecho que muchos fabricantes no lo hayan tomado en serio a la hora de desarrollar sus soluciones hardware, es por esto por lo que los primeros fabricantes que ofrecieron tarjetas RDSI Básicas compatibles con Asterisk a bajo coste fueron justamente los alemanes Junghanns y Beronet, un país donde las líneas BRI son tan habituales como las analógicas en cualquier otro país.

     

    Estos fabricantes no sólo crearon el hardware necesario si no también desarrollaron los drivers necesarios para utilizar dichas tarjetas con Asterisk. Así Junghanns creó su famoso paquete BriStuff y Beronet se centró en otro sistema llamado mISDN.

    Cuando Digium lanzó su conocida tarjeta B410P, se tuvo que decantar por utilizar el sistema de Junghanns o el de Beronet y finalmente se decidió por mISDN, un controlador RDSI BRI basado en estándares abiertos y compatible no únicamente con Asterisk si no con otras aplicaciones.

    Sangoma también creó su tarjeta A500 para RDSI BRI y en lugar de utilizar las opciones disponibles, continuaron utilizando su propio paquete de drivers basados en la idea de que sirviera no solo para voz, si no también para datos: wanpipe.

    Junghanns dejó de ofrecer actualizaciones de su BriStuff tan habitualmente como lo venía haciendo y se echaba en falta drivers para utilizar sus tarjetas con las últimas versiones de Asterisk. Beronet por contra utiliza mISDN que actualmente no tiene apenas actualizaciones y tras las últimas versiones de Kernel de Linux (los kernels superiores al 2.6.18) ha perdido la compatibilidad y no funciona como se espera.

    En este momento de incertidumbre, varios desarrolladores Digium, Xorcom, y algunos más empezaron a desarrollar los nuevos drivers para tarjetas BRI bajo DAHDI basándose en el driver de Junghanns (qozap y zaphfc) para crear el nuevo driver para la B410P bajo el nombre wcb410x dentro del paquete DAHDI.

    Pero ocurre que este añadido, suponía darle soporte de BRI también al Asterisk 1.4 cuando esta versión había sido «congelada» y únicamente se puede modificar para solucionar bugs y no para añadir nuevas características, así que el soporte BRI de DAHDI sólo está disponible para Asterisk 1.6.

    Entonces ahora mismo nos encontramos con un kernel >2.6.18, Qozap con una versión para Asterisk 1.2 o Asterisk 1.4 compatible sólo para tarjetas Junghanns, mISDN que no funciona corréctamente y el soporte BRI en DAHDI sólo para Asterisk 1.6. ¿Qué hacemos si queremos instalar una tarjeta RDSI BRI en 1.4?

    Ahí es donde buscamos las soluciones y hay dos posibilidades:

    – Actualizar a Asterisk 1.6.0.
    Con lo que ya tendríamos soporte BRI con DAHDI y las tarjetas BRI serían dispositivos del mismo tipo que cualquier tarjeta analógica.

    – Actualizar a Asterisk-ES-RSP 1.4.
    Con lo que tendremos una versión de Asterisk 1.4 modificado con el soporte para tarjetas y señalización BRI.

    Esta es sin duda la elección a tener en cuenta ya que el resto de opciones son bastante más complicadas (como por ejemplo desactualizar el kernel para que mISDN siga funcionando, o utilizar una versión antigua de Asterisk para utilizar BriStuff).

    La pega de estas soluciones es que el soporte de BRI en DAHDI, tanto en 1.6 como en 1.4 es que cada fabricante utiliza un identificador para cada versión de su tarjeta, y DAHDI aún no las tiene todas, de manera que, aunque DAHDI sea compatible con Junghanns y Beronet, puede que haya una versión de la tarjeta que aún no haya sido incluida como soportada.

     

    Dando soporte a una tarjeta BRI no reconocida por DAHDI…

    Para ello, si disponemos de una tarjeta con chipset HFC y DAHDI no la reconoce podemos añadirle nosotros mismos el soporte de manera temporal editando el código fuente del driver y haciendo una simple modificación:
    (Odicha tiene una explicación bastante más técnica en su página)

    En el directorio del código fuente de DAHDI:

    root@localhost:/usr/src/dahdi-linux-2.x.x.x/# cd drivers/dahdi/wcb4xx
    root@localhost:/usr/src/dahdi-linux-2.x.x.x/drivers/dahdi/wcb4xx/# ls -la
    total 132
    drwxr-xr-x  3 root root  4096 2009-08-25 12:40 .
    drwxr-xr-x 15 root root  4096 2009-08-25 12:40 ..
    -rw-r--r--  1 root root 83581 2009-08-25 12:40 base.c
    -rw-r--r--  1 root root   116 2009-08-25 12:40 Kbuild
    -rw-r--r--  1 root root   181 2009-08-25 12:40 Makefile
    -rw-r--r--  1 root root 20494 2009-08-25 12:40 wcb4xxp.h

    Con el comando de Linux ‘lspci -vb‘ buscamos nuestra tarjeta:

    02:0b.0 ISDN controller: Digium, Inc. Unknown device b410 (rev 01)
         Subsystem: Digium, Inc. Unknown device b410
         Flags: medium devsel, IRQ 10
         I/O ports at e400
         Memory at fbffb000 (32-bit, non-prefetchable) [disabled]
         Capabilities: [40] Power Management version 2

    Nos fijamos en la posición que ocupa esta tarjeta (02:0b.0) y volvemos a ejecutar el comando con otros parámetros ‘lspci -vn’:

    02:0b.0 0204: d161:b410 (rev 01)
         Subsystem: d161:b412
         Flags: medium devsel, IRQ 10
         I/O ports at e400 [size=8]
         Memory at fbffb000 (32-bit, non-prefetchable) [disabled] [size=4K]
         Capabilities: [40] Power Management version 2

    Apuntamos el texto marcado en ‘azul’ y el ‘verde’ nos fijamos en el archivo base.c y casi por el final del archivo nos encontraremos con unas líneas como estas:

    static struct pci_device_id b4xx_ids[] __devinitdata =
    {
    { 0x1397, 0x16b8, 0x1397, 0xb552, 0, 0, (unsigned long)&hfc8s },
    { 0x1397, 0x08b4, 0x1397, 0xb520, 0, 0, (unsigned long)&hfc4s },
    { 0x1397, 0x08b4, 0x1397, 0xb556, 0, 0, (unsigned long)&hfc2s },

    Cada línea representa el identificador que buscará el driver para reconocerlo como una tarjeta compatible de manera que creamos una nueva línea con la misma forma que las anteriores y colocamos los valores que nos han salido en el ‘lspci’ en las posiciones correctas.

    static struct pci_device_id b4xx_ids[] __devinitdata =
    {
    { 0xd161, 0xb410, 0xd161, 0xb412, 0, 0, (unsigned long)&wcb4xxp },
    { 0x1397, 0x16b8, 0x1397, 0xb552, 0, 0, (unsigned long)&hfc8s },
    { 0x1397, 0x08b4, 0x1397, 0xb520, 0, 0, (unsigned long)&hfc4s },
    { 0x1397, 0x08b4, 0x1397, 0xb556, 0, 0, (unsigned long)&hfc2s },

    El último campo (el de color violeta) corresponde al tipo de tarjeta que vamos a configurar:

    – Las Digium: ‘wcb4xxp
    – Las Junghanns 2 puertos: ‘hfc2s‘, Junghanns 4 puertos: ‘hfc4s‘, Junghanns 8 puertos: ‘hfc8s
    – Las Beronet 2 puertos: ‘hfc2s_BN‘,  Beronet 4 puertos: ‘hfc4s_BN‘, Beronet 8 puertos: ‘hfc8s_BN
    – Las Openvox 2 puertos: ‘hfc2s_OV‘, 4 puertos: ‘hfc4s_OV‘, 8 puertos ‘hfc8s_OV
    – etc.

    De esta manera, ya sea la versión de la tarjeta que queramos añadir (siempre que el fabricante esté soportado) podemos modificar el driver para darle soporte.

    Para terminar, tan solo debemos compilar DAHDI y probar a cargar el módulo:

    /etc/init.d/dahdi restart

    Y al ejecutar el comando ‘dmesg’ debemos ver que la tarjeta ha sido encontrada corréctamente:

    [122429.745539] wcb4xxp 0000:09:01.0: Identified Wildcard B410P (controller rev 1)
    [122429.745539] wcb4xxp 0000:09:01.0: VPM 0/1 init: chip ver 33
    [122429.759405] wcb4xxp 0000:09:01.0: VPM 1/1 init: chip ver 33
    [122429.771406] wcb4xxp 0000:09:01.0: Hardware echo cancellation enabled.
    [122429.771406] wcb4xxp 0000:09:01.0: Port 1: TE mode
    [122429.771406] wcb4xxp 0000:09:01.0: Port 2: TE mode
    [122429.771406] wcb4xxp 0000:09:01.0: Port 3: TE mode
    [122429.771406] wcb4xxp 0000:09:01.0: Port 4: TE mode

    Mi idea no es dar un curso sobre programación ni sobre DAHDI, tan solo mostrar cómo saltar un pequeño obstáculo que puede complicar la existencia a más de uno.

    Configurando DAHDI para utilizar la tarjeta con Asterisk …

    Una vez que veamos en el ‘dmesg’ que la tarjeta ha sido reconocida corréctamente, necesitamos configurarla, para ello vamos a editar el archivo ‘/etc/dahdi/system.conf’ y añadir las siguientes líneas para una tarjeta de 4 puertos:

    span=1,1,0,ccs,ami
    span=2,2,0,ccs,ami
    span=3,3,0,ccs,ami
    span=4,4,0,ccs,ami
    
    bchan=1,2
    hardhdlc=3
    
    bchan=4,5
    hardhdlc=6
    
    bchan=7,8
    hardhdlc=9
    
    bchan=10,11
    hardhdlc=12
    
    loadzone = es
    defaultzone = es

    Si tuviesemos una tarjeta con 2 puertos, sería más simple:

    span=1,1,0,ccs,ami
    span=2,2,0,ccs,ami
    bchan=1,2
    hardhdlc=3
    
    bchan=4,5
    hardhdlc=6
    loadzone = es
    defaultzone = es

    Para una OctoBRI pues puedes usar el sentido común para averiguar cómo sería el system.conf. ;P

    El archivo /etc/asterisk/chan_dahdi.conf  es prácticamente igual que cualquier zapata pero con algunas diferencias:

    Para crear un grupo con nuestros canales ya configurados tan solo debemos añadir algo como esto:

    group=1
    switchtype=euroisdn
    signalling=bri_cpe  ;; bri_cpe si son punto-a-punto ó bri_cpe_ptmp si son punto-multi-punto.
    context=default
    callgroup=1
    pickupgroup=1
    channel => 1,2,4,5,7,8,10,11

    Fácil ¿verdad? 🙂

    Reiniciamos de nuevo DAHDI y Asterisk y deberíamos tener ya la tarjeta perféctamente configurada y funcionando. 😀

    Puedes probarlo entrando en la consola de Asterisk y escribiendo…

    asterisk*CLI> dahdi show status
    Description                 Alarms IRQ
    B4XXP (PCI) Card 0 Span 1   OK     0
    B4XXP (PCI) Card 0 Span 2   OK     0
    B4XXP (PCI) Card 0 Span 3   RED    0
    B4XXP (PCI) Card 0 Span 4   RED    0

    Si teneis algún problema, no dudeis en dejar un comentario.

  • 11.001 llamadas simultaneas con un único Asterisk

    La noticia ha resonado por toda la blogosfera y no es para menos, tras el concurso que promovió Digium para ver quién era la primera persona capaz de realizar más de 10.000 llamadas (5.000 conversaciones) con un único servidor Asterisk, parecía que todo estaba perdido hasta que hace un par de días leo por el twitter que Olle Johansson ha conseguido 11.001 canales simultaneos con un único Asterisk, algo realmente impresionante.

    La primera pregunta que a uno le viene a la cabeza es -«Cómo??» y tras recopilar un poco de información y traducir otro poco, tenemos algo más claro (aconsejo leerlo todo, el final es muy bonito):

    «Hola usuarios de Asterisk de todo el mundo!

    Recientemente, he estado trabajando en unas cuantas instalaciones de Asterisk bastante grandes. Unos 300 servidores corriendo Asterisk y Kamailio (OpenSER). Reemplazando grandes sistemas Nortel por unas pocas máquinas pequeñas y otras soluciones interesantes. Las pruebas han sido una gran parte de estos proyectos. ¿Cuánto podemos apretar a una única máquina con Asterisk?

    Hasta ahora, hemos sido capaz de conseguir 2.000 canales con G.711 en un QuadCore y con tarjetas de red Intel Pro/1000 en servidores IBM. En este momento, el sistema de balanceo de interrupciones (IRQ) se rinde y se va a la cama, y todo el tráfico es dirigido a un único núcleo por lo que el sistema también abandona. Hemos estado haciendo estas pruebas en varios sistemas, con varias tarjetas de red y hemos estado trabajando muy duro para mejorar el rendimiento. Nuevos drivers, nuevas tarjetas, nuevas herramientas. Pero todo parecía indicar que el problema estaba en la conexión entre la CPU (que es la que gestiona el tráfico de voz RTP) y Asterisk. Esto fue finalmente confirmado por algunos equipos de programadores diferentes.

    Imagina mi sorpresa este Lunes cuando yo instalé un típico y antiguo Asterisk 1.4 en un servidor HP, un DL380 G6, y enviando tráfico a varios viejos servidores IBM. 3 servidores reenviando llamadas entre ellos y conseguimos sobrepasar 10.000 canales sin problemas. Llamadas SIP a SIP, el puente P2P RTP, básicamente corriendo como un «media proxy». En este punto, nuestro switch gigabit fue el que se rindió, y por supuesto, las tarjetas de red. Empujar 850Mbits fue más que suficiente. Las CPUs (nosotros tuvimos 16 de ellas con hyperthreading) no estaban muy estresadas. Asterisk estaba ocupando algunas de ellas bastante bien, pero las demás estaban aburridas sin saber qué hacer.

    Así que, ayúdame. Necesito responderle a John Todds algunas preguntas mientras el me invita a un vino realmente caro en la próxima Astricon. ¿Qué fue lo que ocurrió? ¿Fueron las tarjetas de red Broadcom? ¿Fue la placa base Intel 5530? ¿o una combinación? también pudo haber sido el switch barato Netgear…

    Espero tener más acceso a estas máquinas, tres de ellas para hacer test con el último código. En esta versión tenemos nuevas tablas hash, todos los añadidos y cositas chulas que los desarrolladores de Digium han reescrito dentro de Asterisk. La versión Trunk probablemente será mucho mejor que la 1.4 ya que está mas orientada a grandes cargas y un mayor número de canales simultaneos.

    Está en nuestra mano construir nuevas generaciones de Asterisk, más allá de la versión 1.0. A la vez, los chicos del hardware no han estado durmiendo. Ellos son los encargados de hacer hardware barato que haga que nuestro software brille. Necesitamos probar otras cosas y ver cómo se portan el resto de sistemas Asterisk además de estas pruebas de llamadas. Manager, eventos, música en espera, agi, … Nuevos retos interesantes.

    Así que, toma uno de esos servidores de HP y monta un proveedor para un pueblo. Mientras estés en ello, compra otro de repuesto… el hardware puede fallar ( 😉 ).

    Pero eso sí, no digas que Asterisk no escala bien. Estos tiempos ya pasaron.

    /Olle

    (traducción del original en VentureVoIP)

  • Por qué decimos GUI cuando queremos decir Front-end

    En ocasiones, dos palabras cuyo significado se parecen, a menudo es utilizado por distintas personas como si fueran sinónimos, lo que puede llevar a dos posibles interpretaciones: Que habla de algo que no es, o que no tiene ni idea. Esto es lo que a veces pienso cuando leo algunas noticias y artículos, publicidad variada y abundante por no tildarla de SPAM-consentido.

    En este artículo voy a referirme principalmente a dos conceptos que se parecen, pero no son lo mismo y la diferencia puede llegar a ser realmente abrumadora e incluso, viéndolo desde un punto de vista objetivo, casi insultante.

    GUI son unas siglas que vienen a significar Graphical User Interface (o en español: Interfaz gráfica para el usuario).
    FRONT-END es un término inglés que viene a señalar un «frontal» para utilizar una aplicación final «fín«.

    Estos dos conceptos son muy parecidos, y de hecho, cualquiera sin experiencia pensaría que es lo mismo (siempre y cuando haya utilizado alguna vez ambos términos) pero nada más lejos de la realidad y para mostrarlo pondré un ejemplo bastante curioso y didáctico para el que no lo conozca:

    Cuando una persona instala Debian por primera vez, una de las primeras cosas que aprende, es que los paquetes donde se encuentran las aplicaciones, utilidades, librerías y todo, viene en archivos con extensión .deb la forma de instalar dichos paquetes (archivos paquetizadores) se hace SIEMPRE mediante una aplicación llamada dpkg. (des-packager) y mediante esta herramienta con una serie de parámetros, descomprimirá el paquete .deb y colocará cada archivo en el directorio donde debe estar.

    Con un simple vistazo a la herramienta dpkg podemos ver estos parámetros (he puesto la letra muy pequeña para que ocupe lo mínimo posible).

    dpkg-help
    Click para ampliar

    Se podría decir que trabajar con esta aplicación puede llegar a ser algo tedioso cuando para instalar un paquete, antes debemos instalar otros, y para instalar estos otros, antes hay que instalar otros… un usuario novato puede llegar a perder la paciencia.

    Para ello, se inventó una aplicación front-end llamada dselect. Esta aplicación tenía como objetivo facilitar el uso de la herramienta dpkg a los usuarios de manera que se simplificara su utilización y no tuvieran que estar peleándose con los distintos parámetros, a la vez que se automatizaba la búsqueda e instalación de dependencias (de manera que solo había que indicar qué paquete querías instalar y él instalaba sólo y automáticamente todos los paquetes que eran necesarios tener instalado previamente). El front-end en el fondo hace uso de la aplicación final: dpkg y sólo utiliza unos pocos parámetros.

    El comando dselect para muchos se convirtió en una bendición, para otros… en un doble suplicio. Como se solía decir, a veces era más difícil aprender a utilizar el front-end que la propia aplicación ‘end’.

    dselect-help
    Click para ampliar

    La herramienta dselect fue rechazada por gran parte de los usuarios de Debian por ser un front-end al que le faltaba una característica esencial: la aplicación Front-end debe ser INTUITIVA (Del lat. mediev. intuitĭo). Así que, como este front-end no terminó de satisfacer a los usuarios de Debian, se creó una herramienta nueva: apt-get que, no únicamente era mucho más sencilla de utilizar, si no que realmente eran tan útil, fácil y rápida de aprender que hoy día es la herramienta por excelencia que todo usuario de Debian conoce a la perfección.

    apt-get-help
    Click para ampliar

    Por ahora tenemos que dpkg es la herramienta principal y apt-get un front-end del dpkg que facilita la instalación de paquetes.
    Como aún así, el apt-get puede llegar a ser difícil de utilizar para alguien nuevo, se crearon otras herramientas: aptitude y una GUI llamada synaptic.
    Si uno se fija en las opciones de synaptic, puede ver que están TODAS y cada una de las opciones de la herramienta apt-get (NO una simplificación de los parámetros del apt-get).

    synaptic
    Click para ampliar

    Bien, después de este rollo, ¿que intento sacar en claro?

    – Una GUI es una transformación de una aplicación a un entorno gráfico.
    – Un Front-End es una simplificación para facilitar el uso de una aplicación. Un requisito de los Front-End es que deben ser INTUITIVOS.

    Ahora una reflexión:

    – Cuando un cliente dice que quiere una GUI, realmente quiere un Front-End?, un Front-End no tiene porqué ser gráfico, simplemente debe ser más sencillo, intuitivo para no tener que esforzarse en aprender todos los parámetros de la aplicación final.
    – Un Front-end no suele incluir todas las ventajas que la aplicación final por lo tanto, su uso generalmente está limitado.

    ¿Eso significa que si alguien utiliza un Front-End no puede hacer lo mismo que alguien que utilice una aplicación final?
    – No, si alguien utiliza una aplicación final de forma tan simple que hasta lo podría hacer con un Front-end.
    – Si, si alguien utiliza la aplicación final para hacer cosas complejas y más profesionales y no simplemente a nivel ‘usuario’.

    ¿Qué pasa si alguien no sabe manejar una herramienta Front-end?
    – No pasa nada, solo que si esa persona no sabe manejar una herramienta intuitiva, imaginate algo más complicado.

    ¿Qué pasa si alguien quiere hacer cosas complejas con un Front-end?
    – Pues, evidentemente hay cosas que el front-end no podrá hacer y tendrá que utilizar la aplicación final.

    Así que, chicos, chicas, espero que hayais entendido la diferencia entre GUI y FRONT-END a partir de ahora hablemos con propiedad conociendo la diferencia. 😀

  • Poniéndome al día…

    malaga-playa-3Después de tomarme unos días de descanso cerca de la familia y algunos días en la playa para que se disuelva el estrés en la salada y las cálidas aguas de Málaga (llegando incluso hasta los 30ºC) es la hora de volver a la rutina sufriendo un poco de depresión post-vacacional pero eso sí, un poco más relajado. 🙂

    Algunas cosas han ocurrido este verano, y es que como Sinologic es un blog sobre VoIP, se aprecia enormemente aquellos que habeis leído esta web estos días de bajo tráfico en los que tanto las noticias de la televisión como las de internet brillan por su ausencia.

    No obstante, en el mundo de la VoIP ocurre de forma diferente, cuanto más tiempo libre hay, más noticias se suceden mientras que cuando más ocupados están los protagonistas, menos información y novedades.

    He intentado desaparecer y desconectar de Internet tanto como he podido, aunque las «nuevas tecnologías» cada vez más «llevaderas» impiden que la desconexión sea total (qué le vamos a hacer) así que a la vuelta de vacaciones me encuentro con algunas novedades que había dejado en el tintero y algunas sorpresas bastante interesantes que iré comentando estos días a lo largo de esta semana y que seguro que os interesará a muchos.

    De momento, comentar que sigo estando al pie del cañón, pese a que este «curso» ha sido bastante duro por varios motivos, tanto personales como de otra índole y que espero que lo que falte por solucionarse, se solucione rápido, fácil y bien y que, aunque haya bajado el número de artículos, espero ponerme al día porque realmente este año en el que las empresas han «limitado» sus lanzamientos para recortar costes, estoy convencido de que será muy productivo a medida que vayamos saliendo del bache.

    Para todos aquellos que no habeis podido descansar este verano, desearos lo mejor y mucho ánimo y recordar que siempre hay tiempo para tomarse unos días de relax en un balneario, en el campo, en la playa o donde más os guste que seguro que os lo mereceis. 🙂

  • Cuando la VoIP convierte algo a «última tecnología»

    Todos los que leeis Sinologic sabeis que la VoIP es quizá el hecho más importante en cuanto a las comunicaciones, el poder enviar y recibir voz a  través de una red de datos IP es algo realmente fascinante y conocer sus entresijos es mucho más interesante que el hecho de «montar un Asterisk para sustituir a la centralita de la empresa» ;D

    La VoIP es la técnica de digitalizar una señal analógica y procesarla permitiendo nuevos servicios que de haber sido realizado en una señal analógica serían groseramente caro. Ejemplo de esto es la cancelación de eco, eliminar eco en una señal analógica es mucho, pero mucho más caro, complicado y lento que a través de una señal digital, es por esto por lo que un cancelador de eco «tradicional» puede costar entre los 3.000 y 4.000€ por canal frente a los 200€ ó 300€ para 30 canales (como los canceladores de eco en tarjetas de primarios).

    Asimismo, el hecho de almacenar una conversación requería de cintas magnéticas (que previamente debían ser «digitalizadas») y ahora, gracias a las últimas novedades en sistemas de VoIP, cualquiera, desde su terminal, softphone o PBX puede solicitar la grabación de una llamada con una calidad que supera la que el oído humano es capaz de percibir, incluso en estéreo si la conversación se transmitió de esta forma.

    Lo último que he empezado a ver sobre VoIP es la conversión de aplicaciones, productos y dispositivos que normalmente utilizamos y añadirle funcionalidades de VoIP, como un programa de facturación con soporte de VoIP para que puedas llamar a la empresa desarrolladora gratis a través de «su» programa para poder consultar dudas, o bien ratones que hacen las veces de teléfono IP (que realmente es una tarjeta de sonido que se conecta con el softphone que más nos guste).

    Lo que me faltaba por ver era un estetoscópio (el aparato que utilizan los médicos para escuchar los ruidos de nuestro cuerpo) con soporte de digitalización, cancelación de eco, grabación y envío por bluetooth de lo que es capaz de escuchar el médico.
    Visto en Engadget, este aparato (ideal para regalar a algún amigo o familiar médico) está fabricado por 3M y por la foto, no parece muy complicado de manejar.

    20aug09_3mstethz

    🙂

  • Dónde está el futuro de la VoIP residencial?

    sip-movilLa telefonía fija está de camino a la extinción. Según un periódico nacional, sólo en el mes de Julio se han dado de baja casi 70.000 líneas y el número va en aumento mes a mes ¿hasta cuando?

    Cada vez son más las personas que utilizan el móvil para hacer todo tipo de llamadas (a fijos o a móviles) y más desde el abaratamiento progresivo que léntamente traen las nuevas compañías de móviles, operadores virtuales, etc y esta tendencia a hacer llamadas desde el móvil acarreará una costumbre donde el teléfono fijo pasará a ser algo del pasado y que únicamente veremos en puestos de trabajo y en pocos sitios más.

    Está claro que en las casas, en pocos años veremos cómo el móvil pasa a ser el teléfono oficial donde cualquiera podrá llamar, no a una casa, si no diréctamente a un miembro de esta y no importa si está en ella o no, siempre podremos hablar con ella.

    En cuanto a la VoIP, pese a la presión de las operadoras que se dedican a eliminar las aplicaciones «innovadoras» de VoIP de los terminales móviles, cada día el futuro está más cerca de ofrecer alternativas y nuevos medios para utilizar esta técnica para hacer y recibir llamadas.

    Nuevos servicios como Google Voice lo demuestran: el hecho de unificar varios números de teléfono en uno sólo de manera que seas localizable estés donde hace evidente que uno de los números más frecuentes será el de nuestro teléfono móvil.

    El crecimiento de softphones para móviles también es un parámetro importante, y es que, aunque muchos proveedores no permitan el uso VoIP en sus «maravillosas y rápidas» redes 3G, sí que es posible utilizar la red wireless para hacer o recibir llamadas, por lo que cuando estemos en casa, en el trabajo, etc., en lugar de llamar a través del proveedor GSM, podremos hacerlo a través del proveedor IP permitiéndonos ahorrar y aprovechar los servicios que este nos ofrece.

    Dentro de muy poco será imposible no encontrar un teléfonos móvil que además de ser GSM, también soporte Wifi y disponga de un softphone SIP con el que poder hacer y recibir llamadas a través de nuestro proveedor IP.

    La pregunta entonces sería ¿estará entonces el usuario preparado para este cambio?

  • 35 grandes aplicaciones para Asterisk

    Matt Riddell, creador de VentureVoIP acaba de hacer una recopilación muy interesante de quizá las 35 aplicaciones opensource más conocidas para Asterisk.

    Entre estas aplicaciones existen algunas tan fundamentales y conocidas como el Flash Operator Panel, Ast2Billing, IAXModem y el CDRStats .

    Por otro lado, y aunque la lista es bastante grande, echo en falta algunas otras aplicaciones como OpenFire, y tantas, tantas otras así como algunas cuya compatibilidad con Asterisk debería de considerarse dudosas como VMulti o SIPSak por no ser precisamente aplicaciones que funcionan con Asterisk si no totalmente independientes.

    La lista completa la podeis ver en su web:
    http://www.venturevoip.com/news.php?rssid=2184 

    ¿Y tú? ¿Qué otras aplicaciones imprescindibles conoces que no están en esta lista?

  • Dimite el CEO de Nortel

    Parece ser que Mike Zafirovski, el presidente y CEO de la empresa Nortel, acaba de dimitir dejando a la empresa más muerta que viva.

    La empresa canadiense Nortel, conocida en todo el mundo, tras argumentar que estaba en bancarrota hace unos meses, y tras conocer que vendía su división de productos y tecnología wireless a la empresa Ericsson, poco más se puede decir.

    Por un comentario más bien del tipo «rumor» me entero que probablemente Avaya compre Nortel, ya que los gobiernos de EEUU y Canadá han dado por válida esta compra que podría poner un punto y final definitivamente a esta conocida marca.

    El incremento de la VoIP, de los estándares abiertos como SIP en lugar de protocolos cerrados como UNISTIM o SCCP -skinny-, así como la rápida evolución de nuevos sistemas opensource, están haciendo mella en las empresas que defienden «los modelos tradicionales» y un concepto «propietario y controlador» de la VoIP.

  • Primeras imágenes de Elastix 2.0

    Fernando M. Villares me envía una nota sobre la nueva versión de Elastix 2.0 que esperamos salga pronto:

    «Ha pasado algún tiempo ya desde el lanzamiento de Elastix 1.0. Desde entonces, muchas nuevas ideas fueron apareciendo en el camino y se fueron agendando para una próxima versión. Sin embargo, nuevos retos aparecieron en el camino, desarrollamos y liberamos el módulo de Callcenter, el módulo Developers, entre otros interesantes addons que nos han dado muchas satisfacciones. Nuestra comunidad creció y nuestras descargas se acercan el medio millón. La espera por Elastix 2.0 se nos hizo interminable.

    Pero esa espera está llegando a su fin y el momento de incluir esas nuevas ideas ha llegado. Hemos iniciado ya el desarrollo de una nueva versión de Elastix en la que hemos tratado de incluir muchas ideas y sugerencias de nuestra comunidad que habían quedado encoladas. Para los impacientes, un adelanto de las más importantes características que han sido agendadas para Elastix 2.0:

    • Asterisk 1.6
    • Lanzamiento de Elastix Operator Panel
    • Conferencias ricas en características
    • Reportes avanzados
    • Mejoras módulo de call center
    • Mayor integración entre los componentes


    Asterisk 1.6

    Este es un paso obligado. Entre otras cosas, nuestros esfuerzos están encaminados a sacar el máximo provecho posible de las mejoras de desempeño introducidas en la versión 1.6 de Asterisk.

    Elastix Operator Panel

    Seguiremos conservando la versión actual FOP. Pero hemos decidido iniciar el desarrollo de una alternativa, en vista de que la versión 2 de FOP será de código cerrado y por lo tanto no es compatible con nuestro esquema de licenciamiento GPL.
    Nuestro interés es que en el futuro cercano esta alternativa esté disponible incluso para que otras distros, basadas en Elastix o no, la utilicen como parte de sus paquetes.
    Elastix Operador Panel estará basado en AJAX en lugar de Flash y entre sus objetivos se destaca mejorar el desempeño del actual FOP. Sin mencionar que al no utilizar Flash estaremos dando un mejor soporte a los estándares abiertos.

    Una nueva experiencia en Conferencias

    Desde el lanzamiento de Elastix 1.0 hemos visto cómo las soluciones de conferencias han evolucionado. Un claro ejemplo de esto es Webexr. Elastix no se puede quedar atrás y sin duda irá en la dirección de las necesidades del exigente mercado de las tecnologías de la comunicación.
    El desarrollo de esta solución de conferencias se dividirá en 2 fases. La primera fase, que integrará telefonía, chat, compartición de archivos y presentación de documentos; se incluirá en Elastix 2.0. La segunda fase incluirá funcionalidad adicional paulatinamente, luego del lanzamiento de Elastix 2.0.
    Creemos que la inclusión de esta característica sin duda hará que Elasix continúe liderando el mercado de las distros de Comunicaciones Unificadas a nivel mundial.

    Reportes avanzados

    Una de las ventajas de Elastix ha sido su reportación. Sin embargo, disponemos ahora de un framework de desarrollo más potente, que en la actualidad nos permitirá potenciar los reportes aún más.
    Nuestro interés, además de adicionar algunos nuevos reportes útiles, es mejorar la interacción con el usuarios, logrando reportes más fáciles de usar y vistosos. El nuevo framework de Elastix, basado en PHP incluye ahora, entre otras adiciones, librerías de manejo de AJAX que permitirán acceder a un nuevo nivel de interacción.

    Mejoras al módulo de call center

    Elastix ha sido pionero en liberar su solución de call center. Mientras otras soluciones han preferido cerrar o comercializar esta característica, Elastix la ofrece como un módulo de libre descarga, licenciado bajo GPL.
    El lanzamiento de este módulo le dio a Elastix una interesante visibilidad en el mundo de las grandes instalaciones.
    Entre las mejoras que incluiremos se encuentran mejoras al proceso de instalación y actualización, además de mejoras en el desempeño. Mejor integración entre los componentes Elastix 2.0 integrará de mejor manera todos los componentes comunicacionales como PBX, IM, Fax, Email, Agenda, entre otros.
    En este aspecto, uno de los componentes donde se pondrá mayor esfuerzo es en la integración del componente de Agenda con el resto de componentes, permitiendo así un mejor flujo de información dentro de las empresas que usan Elastix y con eso una mejora en la eficiencia de dichas organizaciones.
    Por supuesto, estas no son todas las características que estarán disponibles en Elastix 2.0, pero si están entre las más importantes. Esperamos que la versión 2.0 de Elastix tenga una contribución mayor por parte de la comunidad para poder soportar muchas más de las características recomendadas por la comunidad.

    Gracias a Rafael bonifaz, Edgar landivar, Bruno Macias y Fernando Villares, me han enviado capturas de pantallas de algunas de las novedades que traerá la nueva versión de este sistema.

  • Nuevo módulo de Asterisk: chan_rtmp

    Hace unos días, leí que un desarrollador francés de Asterisk (Philippe Sultan) había empezado a desarrollar un módulo bastante «interesante», llamado: chan_rtmp que hace a Asterisk compatible con el protocolo RTMP.

    El protocolo RTMP (para el que no lo conozca) es un protocolo propiedad de Adobe que sirve como principal medio de transporte para audio, video y datos entre componentes Flash.

    videoconferenceEl pasado 21 de Enero, Adobe firmó una aceptación de uso en proyectos abiertos a la vez que hizo pública la especificación del protocolo RTMP permitiendo la creación de un OpenRTMP que permita a otros desarrolladores utilizar esta tecnología para crear sus propios sistemas de comunicaciones basados en RTMP y componentes Flash.

    El módulo de Philippe, permitiría a Asterisk gestionar llamadas realizadas mediante este protocolo y permitiría a Asterisk unificar dos «mundos» separados entre sí por una barrera inicialmente infranqueables, por lo que podríamos utilizar un componente Flash en una página web que captura audio y vídeo y conectarlo a Asterisk para poder hacer llamadas por SIP de una forma nativa y sin tener que utilizar complejos sistemas de conversión de vídeo y audio mediante Red5 para poder compatibilizar ambos tipos de fuentes.

    Si os parece interesante este nuevo desarrollo, el creador (al que avisa que le funcinan las pruebas) está buscando a más personas que le funcione para poder mejorarlo así que, si alguno está interesado en probarlo, puede descargarlo del svn de Asterisk:

    svn co http://svn.digium.com/svn/asterisk/team/phsultan/rtmp-support/

    y para cualquier sugerencia, puede enviarla a:

    https://issues.asterisk.org/view.php?id=15484

    Si este proyecto sigue adelante, muy pronto podríamos tener video-softphones flash en nuestras webs y conectados a Asterisk. además de poder llevar a cabo la multi-videoconferencia de una vez:D