En la pasada edición de DebConf 13 celebrado el pasado 11-18 de Agosto en Suiza, se dio lugar una conferencia sobre WebRTC bajo un entorno Debian que podéis ver íntegra en el enlace inferior y que, como podéis ver en la imagen utilizaron para ello la librería JsSIP.
Después de llevar tantos años detrás de un proyecto como Asterisk, conociendo sus características, estando al día en cuanto a novedades, su evolución, cambios, problemas, propuestas y mejoras, casi podría decir que me había acostumbrado a la velocidad de crecimiento de Asterisk en cuanto a características, y cuando crees que ya lo has visto todo sobre Asterisk y que nada puede hacerte cambiar de opinión, que uno empieza a «creer» que Asterisk empieza a ser un proyecto aburrido donde solo le queda mejorar en aquellos puntos donde flaquea, aparecen una serie de personas con aires renovados y mucha ilusión y vuelven a sorprendernos proponiéndonos cosas que jamás habríamos pensado que pudiera «caber» dentro de un proyecto como Asterisk.
Cierto es, que tras la unificación de Asterisk-SCF con Asterisk, las posibilidades empezaron a multiplicarse tanto que, personalmente, me empezó a entrar miedo sobre la cantidad de cosas que veía que iban a cambiar en un corto plazo de tiempo. Tanto me asusté que empecé a seguir detenidamente la lista de desarrolladores, leyendo cuidadosamente los distintos temas, observando como Matt Jordan poco a poco, y con un «brillo» hasta ahora desconocido, iba iluminando a tantos desarrolladores para trabajar en una versión que pondría los cimientos de un cambio radical para Asterisk, algo que hará que aquellos usuarios que no estén al día de los cambios, se queden completamente desfasados y sin posibilidad de retomarlo.
Asterisk 12 está en esa etapa en la que el proyecto crece o se estanca, y quizá no sea una versión «estrella» desde el punto de vista de «características revolucionarias«, pero sí que es una versión que asentará unas bases para un crecimiento y una energía que permitirá un sinfín de características que no solo serán revolucionarias, si no que volverá a llamar la atención de todos aquellas personas que siguen el proyecto y que estaban un poco «aburridos».
Asterisk 12 se va a convertir, con muchísimo esfuerzo (todo hay que decirlo) en una versión mucho más orientada a desarrolladores, entre otras cosas por las novedades que trae, no solo de cara a los usuarios, si no también por los cambios que hace al código existente, que cualquiera que desarrolle sobre Asterisk sabrá que, aunque es muy sencillo hacer aplicaciones que interactúen con Asterisk, a cierta profundidad, la cosa se complica bastante y no precisamente por algo intrínseco al mundo de las comunicaciones o algo particular del propio Asterisk, si no por la forma en la que los desarrolladores hicieron las cosas en su momento y que llega la hora de rehacer por completo para seguir creciendo.
Hay decenas de emails en la lista de desarrolladores de Asterisk donde se explica de forma larga y tendida los cambios internos sobre el código existente, no obstante estoy convencido que, si bien el lector puede considerar un poco tedioso que empecemos a hablar (por poner un ejemplo) sobre funciones internas de el código de bridgeado de canales, vamos a pasar directamente a las características más notables de esta versión y si alguien tiene alguna duda más acerca del código y sus novedades, puede seguir la documentación que se está creando para explicar todo lo que se está haciendo. Esta documentación se encuentra en el Doxygen de Asterisk y en su propio Wiki. Mucha documentación, mucha transparencia, mucha participación.
Vamos a ver con todo el detenimiento que nos permite un artículo, ver las principales características de Asterisk 12:
Siempre he defendido el hecho de que VoIP es mucho más que Voice Over IP, es todo el conjunto de sistemas que engloba el hecho de poder comunicarnos a través de una red IP: Voz, Vídeo, Chat, etc. y por este motivo, hay ciertas aplicaciones que, aunque no son específicamente software libre, merecen nuestra atención y nuestro seguimiento debido a la importancia que tienen para la sociedad.
Una de estas aplicaciones es WhatsApp, que si bien es una de las aplicaciones más conocidas por permitir enviar mensajes cortos (aún con sus fallos de seguridad), se ha convertido en el sustituto de los SMS típicos de los Telcos (otro buen ejemplo de que la avaricia rompe el saco).
Una de las novedades de la última versión que sale hoy en todo el mundo, es la aparición del soporte «PTT« – Push To Talk – Pulse para Hablar, también conocido como «Sistema Walki-Talkie» que nos permite enviar audio mediante redes IP pulsando un botón para que otra persona (o grupos de personas) nos puedan oir, pero no de forma simultanea como si fuera un Meetme. Por supuesto, que ya existían algunos «mods» no oficiales de WhatsApp y otras aplicaciones como Viber que permitían este tipo de características, incluso hay software para móviles que ya lo hacían, no obstante, el hecho de que lo incluya un software tan conocido como WhatsApp, seguramente sirva para que este sistema se popularice más aún.
El siguiente paso será permitir audio simultaneo por ambas partes y finalmente ofrecer llamadas a la red telefónica, pero eso es teorizar demasiado. 😛
De la misma forma que Theora es una alternativa al H.264 que no parece tener el apoyo que debería, desde la primera vez que oímos la calidad que ofrece, vimos cuando ocupaba la muestra y cuanto era la compresión que ofrece, vimos que el códec OPUS había sido creado para quedarse. (más información sobre OPUS)
OPUS es, además, el códec referencia para WebRTC, por lo que a nivel software parece ser que ya ha conseguido lo más difícil: un soporte «en exclusiva» en los nuevos productos VoIP incluso en los que están siendo desarrollados actualmente.
No obstante, además de WebRTC, el siguiente paso se presenta más difícil, ofrecer este códec en los nuevos productos software y hardware, ya vimos que Asterisk ya tiene soporte de OPUS, e incluso un ejemplo con el nuevo teléfono AudioCodes 420HD que trae soporte para el códec OPUS, pero más difícil todavía es que los productos conocidos y con trayectoria modifiquen su código para soportar este nuevo códec.
La empresa AG-Projects acaba de anunciar que su softphone Blink ya incluye soporte para el códec OPUS, algo que pone por delante este software frente a otros más conocidos y que lo convierte en uno de los primeros (junto con Jitsi) softphones de escritorio que aprovecha las ventajas de este códec de forma general.
Opus no solo ofrece audio de alta calidad (calidad mucho mejor que el códec HD G.722), si no que además ofrece cambio de calidad en función del ancho de banda disponible (como se puede ver en el ejemplo de audio que hemos incluido al comienzo del artículo), de forma que si no tenemos ancho de banda suficiente, en lugar de entrecortarse la comunicación, se reduce la calidad, por lo que si esa reducción es algo temporal o puntual, apenas notaremos el cambio.
Ahora falta que el resto de teléfonos IP y softphones incluyan soporte de este códec. Imagino que gracias al interés de sus usuarios, igual los fabricantes se animan a ofrecer este soporte, pero lo que parece claro es que OPUS no solo es una realidad, si no que parece que OPUS será el códec definitivo.
Cisco ha publicado en su último boletín de seguridad la existencia de múltiples vulnerabilidades y fallos de seguridad en su Cisco Unified Communications Manager que permiten a un atacante remoto tomar el control de los sistemas afectados.
Cisco Unified Communications Manager (Unified CM) contains multiple vulnerabilities that could be used together to allow an unauthenticated, remote attacker to gather user credentials, escalate privileges, and execute commands to gain full control of the vulnerable system. A successful attack could allow an unauthenticated attacker to access, create or modify information in Cisco Unified CM.
El pasado 6 de Junio, una empresa de seguridad francesa hizo público un informe sobre seguridad VoIP que incluía una demostración sobre varias maneras de atacar un sistema Cisco Unified Comunication Manager aprovechando vulnerabilidades no solucionadas.
Las versiones afectadas son desde la 7.1 hasta la 9.1, así como los distintos productos:
Más información sobre estas vulnerabilidades las podéis encontrar en Hispasec y en el mensaje oficial de Cisco.
Hoy día, cuando hablamos de teléfonos IP, prácticamente nos referimos a teléfonos de sobremesa, aquellos que necesitan un cable de red con POE o con fuente de alimentación, pero muy pocas veces hablamos de los teléfonos IP WiFi, y es que la telefonía DECT ha sabido aprovechar las carencias de los teléfonos IP con Wifi para plantarle cara utilizando una tecnología más rudimentaria (como es la tecnología DECT) pero que cumple con su objetivo: realizar llamadas con dispositivos móviles donde la batería no sea un problema y la cobertura sea barata.
Los teléfonos WiFi siempre suelen ser desaconsejados por varios motivos:
Así que, a igualdad de razones, y mientras aparecen teléfonos IP WiFI que ofrezcan mejores características a precios competitivos, siempre hemos recomendado telefonía DECT. No obstante, hay un sector que está creciendo y es de los softphones SIP para smartphones, por lo que, pese a que la batería siga siendo muy pequeña, es muy práctico tener en nuestro móvil nuestra cuenta SIP, por lo que para ello, hemos hecho una recopilación de los softphone SIP para smartphones más conocidos y recomendados, sin operador exclusivo asociado (libre para conectar con nuestro servidor SIP), posibilidad de usar códec G.729 pagando un pequeño coste añadido, o bien utilizar códec OPUS, videoconferencia aprovechando la cámara frontal, o incluso mensajería instantánea con alguno de los protocolos más importantes y compatibles. Todos ellos funcionan aprovechando la conexión WiFi del teléfono móvil o bien la cobertura 3G (si así lo indicamos) para lo cual necesitaremos de códecs que compriman mucho para evitar microcortes en la voz.
Vamos a ver cuales son los mejores 6 softphones SIP en Android…
El Software Libre nació en la universidad, con los primeros algoritmos, eran tan complicados y los lenguajes eran tan escasos que en toda una universidad, apenas 20 personas sabían lo básico para crear una aplicación (o lo que entonces se conocía como aplicación), fue entonces cuando pequeños trozos de código que hacían pequeñas pero imprescindibles acciones, se publicaban para que pudieran servir al resto de programadores y pudieran continuar desarrollando, enseñando y evolucionando para llegar a convertirse en lo que hoy día se llama programación, aplicaciones o como lo llaman hoy día… «apps«.
Esos pequeños trozos de código eran tan simples como efectivos, servían para ordenar listas de números, para realizar cálculos matemáticos, para buscar una pequeña cadena dentro de una cadena aún más grande… y ese código, tan básico como necesario era publicado en revistas universitarias, completamente libre, sin carga, sin royalties, sin cuotas ni licencias… el software nació libre.
Posteriormente, las primeras empresas de informática, para ofrecer «servicios de valor añadido» a sus clientes, empezaron a desarrollar aplicaciones y a venderlas mediante un sistema de «licenciamiento» que sustituía al entonces «cuota de mantenimiento mensual«, una forma como otra de ahorrar en costes permitiendo a las empresas pagar de una vez el coste de una aplicación y dotándole a ese software de un valor comercial, en lugar de un valor intelectual como venía haciéndose en el resto de universidades.
En el mundo de las comunicaciones sin embargo, ha ocurrido todo lo contrario: de una caja negra, en la que el cliente pagaba una cantidad de dinero por disponer de ese hardware especializado en gestionar llamadas, utilizando para ello lógica mediante hardware, puertas lógicas, contadores, amplificadores, transistores, y demás circuitería especializada creada en laboratorio y fábricas de alta tecnología, … hemos pasado a un sistema basado totalmente en el software, en un hardware genérico, un sistema capaz de ejecutar un programa cualquiera,… un sistema basado en software que transforma las llamadas en bits, en datos y gestione llamadas reales.
La VoIP es la confirmación que toda máquina de comunicaciones basada íntegramente en hardware, está destinada, en un tiempo próximo, a ser reemplazada por una máquina genérica y un software que emule, copie y mejore su comportamiento y rendimiento.
Vamos a intentar resolver uno de los problemas más típicos y que siempre suelen tener los usuarios de VoIP más nuevos. Es la falta de audio cuando consigue hacer una llamada. Esto es un problema recurrente, que no importa cuantas veces se conteste, siempre ocurren modificaciones que invalidan «en teoría» las posibles soluciones que se le ofrecen.
Hemos intentado retomar este tipo de preguntas y poder responderlas convenientemente para que queden definitivamente resueltas, aunque para ello haya que leer un poco y conocer, no solo el problema, si no los motivos por lo que ocurren y cómo solucionarlo.
Vamos a afrontar el problema de falta de audio desde dos puntos de vista muy diferentes:
– Dentro de la misma red (algo que puede ocurrir en algunos casos puntuales cuando la configuración es desastrosa)
– Dentro y fuera de la red (algo más común y más difícil de solucionar en algunos casos en los que todo se nos vuelve en nuestra contra)
Sea como fuere, la configuración es importante tenerla correcta, clara y lo más resumida posible, de poco nos sirve descomentar algunas opciones del sip.conf si no sabemos qué parámetros existen o no, por lo que recomiendo utilizar el siguienet comando para obtener un archivo sip.conf limpio, que nos sirva para descubrir qué parámetros tenemos activos y cual no:
cat /etc/asterisk/sip.conf |egrep -v «^;|^ |^\s+» |sed «/^$/d» |sed «s/\[/\n[/»
Aún así, vamos a analizar las distintas posibilidades de problemas de falta de audio viendo por qué se producen y cómo solucionarlo…
Será que tengo que variar mis fuentes de Twitter, pero lo que está claro es que aún siguiendo a personas de distinta índole y experiencia, al final mi timeline parece monotemático, todo el mundo hablando sobre un mismo tema: WebRTC. Es comprensible, ya que estos días se viene celebrado la WebRTC Conference 2013 en Atlanta (EEUU) y claro, aparecen novedades que llaman la atención y que, pese a lo que opine más de uno, tiene todas las papeletas de convertirse en un nuevo estándar en cuanto al mundo de la VoIP.
Cualquiera que busque información sobre WebRTC, puede pensar algo tan simple como:
«WebRTC permite que un navegador acceda al micrófono y a la webcam de nuestro ordenador para transmitir nuestro audio y nuestro vídeo a otro punto de la red«
Efectivamente, esa definición podría resumir lo que es WebRTC y podría quedarse ahí, llamar la atención de unos 5 webmasters aburridos en todo el mundo y ponerse a programar un softphone en la web para hacer una videoconferencia utilizando únicamente un navegador compatible.
No obstante, WebRTC es mucho más que eso, no solo permite realizar llamadas y videoconferencias, si no también cualquier tipo de comunicación en tiempo real, utilizando tan solo un navegador.
Nos permitiría compatir la pantalla, crear salas de conferencia para chatear, multi-videoconferencia, emisión broadcast, audio y videoconferencia, envío de archivos y otro tipo de datos, incluso SIP sobre WebSocket, lo que nos abriría el campo de posibilidades al mundo SIP.
WebRTC utiliza como códec básico OPUS, el que seguramente se converta en el códec VoIP más utilizado dentro de pocos años, y empresas como AudioCodecs acaba de anunciar en el WebRTC Conference 2013, que acaban de lanzar el primer teléfono IP que soporta Opus (AudioCodes 420HD), uno puede volver a pensar… -«¿para qué? ¿qué sistema soporta actualmente Opus?» Bueno… de momento ya hemos visto cómo Asterisk ya tiene soporte de Opus, pero lo importante es que marca un cambio de tendencia, una apuesta de los fabricantes por este códec que ha demostrado ser increiblemente bueno y práctico, a la vez que ofrece una solución para evitar la transcodificación desde Opus cuando hagamos uso de WebRTC en nuestros sistemas.
WebRTC es la nueva revolución de las comunicaciones, es la nueva forma que utilizaremos para comunicarnos, y lo más interesante es que las principales empresas de comunicaciones y servicios de Internet apuestan por WebRTC (Google, Microsoft, Apple, …), por lo que casi podemos garantizar su existencia y pronto empezaremos a ver cómo continúa la partida de ajedrez.
En mi humilde opinión, cuando alguien trabaja con servidores de comunicaciones, le interesa que todos los recursos se utilicen o estén orientados y disponibles para satisfacer las necesidades de la tarea dedicada que tiene que realizar. Por ese motivo, un servidor dedicado que ofrece servicio web, correo o incluso un Asterisk o un Kamailio, no es habitual instalar un entorno gráfico.
Debido a esto, siempre he sido un gran fan de las herramientas en modo texto, aquellas que, pese a «simular» un entorno gráfico, utilizan ventanas y colores pero siguen corriendo en un entorno de texto, haciendo uso de las teclas «especiales» como las teclas de función o cursores, para movernos entre las opciones. No sobrecargan el sistema, no ocupan apenas recursos y su funcionalidad es similar a las herramientas gráficas, pero mucho más efectivas desde el punto de vista «tiempo/recursos» además de la necesidad de pelearse con el ratón. Aplicaciones como Midnight Commander (la versión linux del Comandante Norton) para gestionar los archivos del sistema de ficheros, o incluso la típica herramienta «memtest86» para comprobar la memoria RAM son algunos ejemplos de herramientas que funcionan en modo semi-gráfico utilizando la librería «ncurses» y permitiendo ser muy prácticas pero sin perder atractivo.
Centrándonos en VoIP, seguro que todos conocéis una famosísima herramienta llamada Wireshark, una herramienta en modo gráfico que sirve para capturar tráfico de red y verla cómodamente en tu entorno gráfico para analizar las trazas de una comunicación. Similar a esto, pero sin necesidad de entorno gráfico (con lo que podemos ejecutarlas en el mismo sistema dedicado), hay otras herramientas imprescindibles: tshark (la versión ncurses de wireshark), ngrep (otro capturador y visualizador de paquete de datos muy utilizado en todo entorno de VoIP para analizar SIP), incluso seguro que conocéis tcpdump, (una de las primeras herramientas que captura, filtra y visualiza conexiones y trazas de datos), no obstante, acabamos de conocer una gran herramienta que os vamos a presentar y que seguro que formará parte de la lista de herramientas imprescindibles de sistemas VoIP.
Iván Alonso de Irontec nos presenta sngrep, una herramienta similar a ngrep (de hecho, está basada en ella) pero que utiliza ncurses para mostrar el flujo SIP en una consola modo texto, algo que sin duda nos hubiera venido bastante bien a muchos de nosotros desde hace tiempo.