Acabo de saber por Daniel Constantine Mierla, que la revista InfoWorld acaba de publicar las aplicaciones más importantes decada campo y Kamailio aparece como una de las 10 mejores aplicaciones de Software Libre destinada a networking más importantes según esta revista.
Junto con Kamailio, otras aplicaciones conocidas también han sido premiadas en esta categoría: Cacti, IPCop, KeePass, Nagios, Openfiler, OpenNMS, Puppet y Untangle.
Me he llevado una gran sorpresa mientras leía este artículo de Meneame.net en el que los desarrolladores de la conocida aplicación ffmpeg (y las librerías libres para poder usar y convertir vídeos) han abierto una nueva página web para denunciar a aquellas empresas que utilizan su aplicación y sus librerías para realizar aplicaciones cerradas.
La página en cuestión la han llamado «la página de la vergüenza» (Hall of shame) y he entrado para ver si conocía a alguna y «sorpresa!», la última (por orden alfabético) es Zoiper.
Por supuesto, hay muchas otras (no tan conocidas por mí) pero el hecho de que Zoiper comenzara siendo una aplicación opensource y pasara a ser cerrada me seguía doliendo.
Seguro que se solucionará pronto… de momento, el principal desarrollador, zoa ya está en ello, ya que parece que ha sido un despiste más que algo malintencionado.
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.
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 2Nos 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‘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.
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.
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
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).
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’.
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.
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).
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. 😀
Hace varios meses Saúl Ibarra y Jon Bonilla propusieron una idea para un proyecto muy interesante:
Congelar una versión de Asterisk y aplicar los parches necesarios para conseguir una versión verdaderamente estable y lo más segura posible basándose en las características más comunes para un Asterisk que funcione como centralita de comunicaciones.
Quizá el debate en este sentido está servido, la versión de Asterisk que Saúl y Jon parchean está basado en Asterisk 1.4, actualmente la rama más peleada y conocida y por este motivo, esta versión pasó a llamarse Asterisk-ES-RSP (Rock Solid Patchset) y consiste en un Asterisk 1.4 con todo lo necesario que solucionan los bugs que se encuentren en las características más utilizadas como SIP, features, y DAHDI.
Nuestro compañero Odicha, una mente inquieta que empezó desarrollando algunos parches para completar el soporte de tarjetas RDSI Básicas (BRI) en Asterisk 1.4 y que hoy día es de los desarrolladores más activos de la comunidad Asterisk-ES participa también en este proyecto aportando su granito de arena para conseguir facilitar la vida a aquellos que trabajan con estas tarjetas BRI y desean utilizar DAHDI.
Otros como Javier Ximenez, desarrollando el soporte del cancelador de eco comercial SoftEco e integrándolo para simplificar el tiempo de instalación para los integradores.
Y muchas otras personas (como Silvia, Ramoncio, Ramses, y un largo etcétera) que, a través de sus pruebas, comentario y sobre todo tiempo, han venido colaborando para documentar, detectar y mejorar todo lo posible esta versión.
Cómo no, es mandatory decir que Asterisk-ES-RSP no es un fork ni tiene la intención de serlo, si no una versión de Asterisk a la que se le aplican las modificaciones para corregir los más pequeños errores que pueda tener sin añadir nuevas features que puedan provocar nuevos errores, Asterisk-ES-RSP no pertenece a ninguna empresa aunque muchas apoyan esta iniciativa, y está abierto a todo aquel que quiera participar mediante su lista de correos o su página web.
Después de 6 meses de continuo testeo, pruebas y conversión de parches es de recibo reconocer la buena labor que estas personas están desarrollando, no sólo para conseguir una versión optimizada y segura, si no además la brillante intención de ponerlo a disposición de todos aquellos que quieran probarlo y utilizarlo en entornos de producción.
Podría decir que actualmente Asterisk-ES-RSP es la versión de 1.4 más fiable que existe y la única que permite utilizar tarjetas RDSI Básicas basadas en el chipset HFC (Beronet, Digium, Junghanns, Billion, Openvox, etc) con DAHDI de una manera sencilla y sin líos de Kernel ni con el mISDN.
Si estás interesado en probarlo, tan solo debes seguir los siguientes pasos:
http://www.asterisk-es-rsp.org/doku.php/instalacion:instalacion_asterisk-es-rsp
Despué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. 🙂
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.
🙂
La 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?