Saúl Ibarra acaba de publicar el material de una conferencia que dió la semana pasada sobre seguridad en una red VoIP muy interesante.
Lo podeis ver aquí:
http://www.saghul.net/
Saúl Ibarra acaba de publicar el material de una conferencia que dió la semana pasada sobre seguridad en una red VoIP muy interesante.
Lo podeis ver aquí:
http://www.saghul.net/
Como adelanté hace algún tiempo, el equipo de desarrolladores de IAXClient (la librería para programar aplicaciones y softphones) acaba de anunciar la nueva versión estable IAXClient 2.1.
Las características de esta nueva versión incluye:
– Código para videoconferencia basado en ‘libvidcap’ que soporta la detección de dispositivos de vídeo, webcams, etc.
– Soporte para el códec Speex (1.2 beta 3) y Theora (1.0 beta 2)
– Nueva aplicación ‘simpleclient‘ para implementar aplicaciones de ‘estrés’ automatizado.
– Frame de vídeo compatible en lugar de uno cerrado.
– Bugs corregidos.
En apenas dos semanas, se intentará lanzar una versión «Release Candidate» que seguirá la versión estable 2.1.0.
Enlace: http://iaxclient.sourceforge.net/
Vía: Blog do Sato
Hace algún tiempo me pregunté qué diferencias existían entre la versión comercial del códec G.729 que distribuye Digium y la versión «opensource» que se puede encontrar en algunas webs.
Mientras buscaba información, me topé con la casualidad de que algunas personas me hacían preguntas sobre esta diferencia, he incluso personas que utilizaban la versión opensource se encontraban con problemas de audio por lo que decidí ponerme a leer e investigar las diferencias.
En este artículo intentaré explicar de la forma más «didáctica» posible estas diferencias, así como el funcionamiento básico de ambos códecs.
El archivo codec_g729 para que Asterisk sea capaz de reproducir o escuchar el códec G.729 se basa en un algoritmo método matemático patentado y por lo tanto, la utilización de este algoritmo, no está exenta de pagar una «licencia de uso», tanto si es para uso comercial, como si es para educación, pruebas, etc… a ellos les da igual para qué lo vayas a utilizar, mientras pagues.
Ahora bien, los creadores de ese algoritmo método matemático, al que pertenecen bastantes empresas muy conocidas (SUN, Nokia, Skype, Intel, etc… http://www.sipro.com/licensees.php) por ser «creadoras» o «patrocinadores» de la creación del G729, tienen a su disposición un gran número de licencias anuales (para meterlo en su propio software, en sus móviles, etc…) y además, esta fundación en sí tiene «vendedores» de licencias para el códec entre las que se encuentran algunas como Global IP Sound, Soundpoint, y algunas otras que venden la licencia para utilizar el algoritmo de compresión únicamente.

Digium ha utilizado este algoritmo y lo ha introducido como módulo para poder utilizarlo en Asterisk (de ahí las licencias G.279 para Asterisk y el porqué de pagar la licencia, porque el uso de dicho códec cuesta dinero)
Ahora bien, Intel es uno de los «creadores» de este códec y como dispone de licencias para uso particular, ofrece dicha licencia para el algoritmo de compresión de audio completamente gratis para temas docentes, pruebas, etc… nunca nada comercial, pero eso es únicamente el algoritmo, nada del canal para utilizarlo en Asterisk.
Más adelante, aprovechando la licencia que Intel ofrece para docencia, pruebas, etc, alquien cogió el binario del algoritmo y se auto-fabricó un archivo codec_g729 compatible con Asterisk pero con la versión que Intel tiene puesta en su página, y otra persona lo llamó erróneamente opensource (http://www.readytechnology.co.uk/open/ipp-codecs-g729-g723.1/) aunque nadie sabe dónde se encuentra el código fuente que genera finalmente el archivo codec_g729 y aunque existiera, de opensource no tiene nada ya que el hecho de utilizar ese algoritmo ya implica haber pagado la licencia.
En esta última versión, el código que tiene Intel en su página es el mismo desde hace 10 años, cuando el códec «oficial» ha ido evolucionando poco a poco de forma más o menos transparente para su utilización aunque realizando algunas mejoras en cuanto a coste, carga, velocidad, etc.
Muchas personas me han preguntado sobre las diferencias entre estos códecs (saludos a todas ellas y siento el retraso en esta contestación), y aquí va:
El códec G729 contiene lo que sería un diccionario de sonidos. Estas pequeñas partes de sonidos se podría intepretar como micro-fonemas. Cuando le enviamos un trozo de voz al códec, este lo reemplaza con una referencia a una palabra de su diccionario y lo envía, también prepara los siguientes sonidos que cree que pueden precederle. Así es cómo el códec comprime la voz tan bien. Realmente esto no envía absolutamente nada de la voz original, envía trozos matemáticos que ha ido creando en tiempo real. Por este motivo, la voz se escucha perféctamente, mientras que la música (por ejemplo cuando hacemos un MusicOnHold) no. Así se comporta el códec G729 «plano«.
A medida que se va ampliando ese diccionario, la calidad de sonido aumenta, el tiempo para encontrar un sonido «matemático» similar disminuye lo que provoca una menor carga del procesador.
Estos añadidos se conocen como «anexos» y se definen como letras A, B, C,… y de ahí es de donde viene cada letra que acompaña nal nombre del códec. Por eso existe el códec G729A, G729B, …
El códec «libre» utiliza las primitivas Intel IPP, por lo que sigue siendo un códec G.729 y la principal diferencia es que utiliza un conjunto diferente de ecuaciones, por lo que la evolución del resto de anexos del códec inicial ya no es viable y de hecho provocan diferencias en la propia carga del procesador.
Como he comentado, el códec G729 tiene muchas variantes (G.729a,b,c,d,e,c+,f,g,h e incluso el g.279i) cada una con sus peculiariedades, aunque el más utilizado es el G.729a y el G.729b por ser el más sencillo y por lo tanto el más rápido de comprimir y descomprimir, el resto se utilizan en telefonía móvil y como base para otros códecs menos conocidos y mucho más caros incluidos en DSPs integrados en tarjetas de comunicaciones.
En Europa no debe pagarse ninguna licencia por el uso del códec ya que por ahora (y esperemos que siga siendo así) las patentes software no han sido aprobadas y por lo tanto el código sigue sin ser patentable, la pega es que la entidad encargada de este códec está en los EEUU y allí sí que hay patentes software, por lo que si alguien quiere conseguir una licencia, no tendrá más remedio que pagar por ella.
Por esto, en Europa es legal utilizar la versión «opensource» aunque como he dicho antes, las empresas que ofrecen servicios de VoIP y que utilizan la versión patentada del códec, las empresas fabricantes también lo utilizan, por lo que si utilizamos la versión «opensource» en nuestro Asterisk, además de no disponer de las «evoluciones» del códec, mayor velocidad a la hora de comprimir y descomprimir, etc… tal y como he comentado, debería funcionar de manera más o menos transparente y este «mas o menos» es lo que hace que en algunos casos se produzcan cortes en las llamadas cuando se utiliza este códec para comunicar ciertos terminales que sí disponen de la última versión.
Otra de las pegas que nos podemos encontrar con la versión Intel, es que suele dar algún que otro problema con kernels SMP: (Intel g729 crash redhat) e incluso cortes de audio en Asterisk que se van resolviendo, pero a medida que evoluciona el códec las diferencias aumentan y eso lo vuelve inconsistente.
Espero que con este artículo se hayan resuelto algunas cuestiones 🙂
Tal y como predije hace algún tiempo, la empresa que defendía la telefonía tradicional y menospreciaba el auge que estaba teniendo la VoIP el pasado año: Siemens, acaba de anunciar el despido de los 6.800 empleados de su fábrica de centralitas Gigaset. Está claro que Siemens tiene más modelos, pero esta ha sido solo la primera. Siemens dejará de fabricar físicamente las centralitas y se reconvertirá en un proveedor de servicios IP. Toda una línea de negocio industrial desaparece en Siemens.
Hacía tiempo que ya sabía de este rumor y más aun cuando uno de sus técnicos me hablaba de que iba a asistir a un curso ofrecido por Siemens sobre VoIP meses después de que otro técnico hubiera ido a ese mismo curso y no sabía ni los protocolos básicos de la VoIP (y no me estoy refiriendo a Skype).
La verdad es que esta puede ser una de las noticias de la semana, ya que en todo el mundo hay técnicos Siemens especializados en centralitas tradicionales que van a notar una disminución bastante aguda de sus clientes.
Más información: http://www.euronews.net/
La herramienta más conocida para recibir faxes y convertirlas a archivos gráficos para así poder transformarla en pdf, en ps, enviarla por email, etc, es el spandsp de Steve Underhood.
Otra alternativa que funciona a la perfección es la combinación Hylafax + IAXmodem con el que simulamos un fax conectado por IAX y con el que podemos gestionar los faxes con una gran fiabilidad.
La empresa PIKA acaba de publicar un software comercial que realiza lo mismo que el spandsp, pero con una instalación más sencilla y compatible con tarjetas Digium, Sangoma y por supuesto PIKA.
PIKA ofrece una cuenta de evaluación para aquellos que quieran testearla en un puerto y únicamente tienen que registrarse en su página web: http://www.pikatechnologies.com/fax
Las instrucciones para la instalación y la posterior prueba no puede ser más sencilla:
http://www.pikatechnologies.com/english/View.asp?x=819
El precio de cada licencia es de $25 por canal que vaya a recibir faxes.
Vía: TomKeating
Google hace tiempo compró una empresa especializada en VoIP y todos empezamos a divagar sobre cual sería la nueva estrategia de Google con GrandCentral.
Acaba de salir a la luz una nueva característica para los usuarios de Blogger a los que permiten recibir llamadas y mensajes de voz gracias a la tecnología de GrandCentral y luego poder escucharlas en su página.
Más información: http://help.blogger.com/bin/answer.py?answer=86337
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…
Más información: http://www.portsip.com/
La penúltima versión de Asterisk 1.6 se hizo pública anoche: Asterisk 1.6.0 Beta 3.
Los cambios con respecto a la beta2 son sobre todo arreglos a los bugs detectados así como algunas características nuevas como:
* Añadida la opción ‘n‘ a la aplicación SpeechBackground para ejecutarse incluso cuando el canal no haya sido contestado
* Creadas nuevas acciones para el manager (AMI) para mejorar la edición de archivos desde este interfaz:– Listar los contextos de un archivo
– Obtener las líneas de un contexto determinado
– Borrar un contexto
– Crear un nuevo archivo de configuración
– Borrar una línea por la posición con respecto a la línea de definición del contexto
– Insertar variables y contexto en una línea determinada
– Insertar contextos dentro de otros
– Añadida una condición de falso al GotoIfTime
– Añadidos nuevos eventos para visualizar las estadísticas del jitterbufferen IAX2.
Recordad, que en la GUI que es principalmente quien utiliza estas acciones mediante el AMI, a los contextos los llama categoría. 😛

Descargar: http://downloads.digium.com/pub/asterisk
Malcolm Davenport acaba de anunciar el nuevo firmware 1.1 para el appliance AA50 de Digium.

Entre las novedades de esta versión destacan:
* Por fín parámetros en otros idiomas (además de Inglés) en la GUI
* Códec G722
* Aprovisionamiento de Polycom desde la WAN
* Incluye el ABE basada en la versión de Asterisk 1.4
* Añadido soporte anti-bucles infinitos cuando se programan los desvíos
* Adjuntos del buzón de voz vía email en formato WAV.
* Muchas novedades, campos nuevos y mejoras en la estabilidad de la GUI
* y como siempre, los últimos bugs solucionados.
Copio y pego…
Se han encontrado múltiples vulnerabilidades en teléfonos VoIP Cisco Unified IP Phone que podrían ser aprovechadas por un atacante remoto para causar una denegación de servicio o ejecutar código arbitrario.
Las vulnerabilidades anunciadas por Cisco son:
* Los Cisco Unified IP Phones que ejecutan firmware SCCP y SIP podrían contener un desbordamiento de búfer provocado por la forma en la que manejan las respuestas DNS. Esto podría ser aprovechado por un atacante remoto por medio de una respuesta DNS especialmente manipulada para disparar un desbordamiento de búfer pudiendo ejecutar código arbitrario en un teléfono vulnerable.
* Los teléfonos que ejecutan firmware SCCP podrían contener una denegación de servicio. Esto podría ser aprovechado por un atacante remoto por medio de un paquete de petición de echo ICMP demasiado larga para causar que el teléfono se reinicie.
* También existe una denegación de servicio en el servidor HTTP de los Cisco Unified IP Phones que ejecutan firmware SCCP. Esto podría ser aprovechado por un atacante remoto, por medio de una petición HTTP especialmente manipulada enviada al puerto 80, para causar que el teléfono se reinicie. Esto puede evitarse si se deshabilita el servidor HTTP interno.
* Los Cisco Unified IP Phones que ejecutan firmware SCCP podrían contener un desbordamiento de búfer en el servidor SSH interno. Un atacante remoto no autenticado podría aprovechar este problema, por medio de un paquete especialmente manipulado enviado al puerto TCP 22, para provocar que el teléfono se reinicie o para ejecutar código arbitrario. Esto puede evitarse si se deshabilita el servidor SSH.
* Los Cisco Unified IP Phones que ejecutan firmware SIP se ven afectados por un desbordamiento de búfer provocado por la forma en la que manejan los datos codificados como MIME (Multipurpose Internet Mail Extensions). Un atacante remoto podría aprovechar este error a través de un mensaje SIP especialmente manipulado para provocar un desbordamiento de búfer que incluso podría llegar a permitir la ejecución de código arbitrario en un teléfono vulnerable.
Noticia completa en: Hispasec