Categoría: Sinologic

  • Transmitiendo archivos por audio en Asterisk

    Como si fuera un Amstrad CPC 64 con su cinta para transmitir datos procedente de una señal de audio, la gente de 5-in-5 están desarrollando un método para transmitir archivos mediante audio a través de Asterisk: Asterisk File Transfer Protocol (A-FTP).

    La pega, como en aquel entonces, es la velocidad. Llegan a transmitir una fotografía de 8kb en apenas 3 minutos y 29 segundos (uauu!!!) XD

    La técnica consiste en convertir un archivo cualquiera en sonidos audibles utilizando para ello los algoritmos de CSound. Una vez obtenido el archivo de sonido, el sistema llama a otro Asterisk encargado de hacer el paso contrario y convertir esos sonidos en un nuevo archivo de datos.

    Muy curioso.. 🙂

    Más información: http://5-in-5.com

  • A por la estandarización de Asterisk

    Cada empresa que instala y configura Asterisk dispone de alguien con conocimientos suficientes para hacer esta labor, algunos tienen más conocimientos y otros no tantos pero en el fondo, cada uno cuenta con dos puntos importantes: capacidad de aprender y un objetivo a cumplir, donde este será instalar un sistema, instalar Asterisk, configurar los dispositivos, tarjetas, líneas, etc, y configurar Asterisk como lo necesite su empresa o su cliente.

    Cuando ocurre algún inconveniente o un comportamiento no esperado se suele buscar ayuda bien en la lectura de numerosas webs, blogs, listas, foros, etc… o bien diréctamente a cualquiera que pueda ayudar.
    Es aquí donde empiezan los problemas iniciales. Cada uno ha aprendido por su cuenta, buscando, encontrando, leyendo y preguntando, de ahí se sacan conclusiones propias y uno hace lo que buenamente sepa o pueda.

    De la misma manera que el software libre da libertad de escoger cómo, cuándo, dónde y porqué, configurar Asterisk también da bastante libertad y un comportamiento puede realizarse de varias maneras y todas válidas (mejores o peores) pero el desconocimiento o una falta de metodología adecuada suelen acarrear inconvenientes, no únicamente por lo que hayamos hecho o dejado de hacer, si no a la hora de preguntar y esperar una respuesta. Cada persona tiene su técnica, sus trucos y consejos que hacen que, en teoría, una configuración que se comporte igual a otra, sean diferentes y dichas diferencias pueden sorprendernos con comportamientos no deseados.

    Concretamente, el confiar en que no definiendo un parámetro en algún archivo de configuración, el comportamiento será correcto, no se cumple en Asterisk (básicamente porque el comportamiento habitual de los sistemas de comunicaciones en España es bastante diferente al de EEUU) y muchas personas se dan cuenta que el hecho de poner un parámetro resuelve todos sus problemas.

    Por este motivo, el equipo de desarrolladores de Asterisk tiene muy mal acostumbrado a los usuarios que les permiten «omitir» ciertos valores en determinados parámetros sin recibir ni un triste mensaje de aviso o error, algo que para los ojos de la persona que desconoce la importancia de este parámetro, representaría la diferencia entre acabar felizmente y pasarse una semana leyendo listas de correos y foros.

    Por poner un ejemplo, al definir un usuario SIP en el archivo ‘sip.conf’, el parámetro ‘host’ es imprescindible y sin ella, simplemente no podremos registrarnos con ese usuario, no obstante, si nos olvidamos de definirlo, Asterisk ni se inmuta, no dice nada, lo ve normal y no se queja. ¿Resultado? algo tan sencillo como definir un usuario SIP, se puede llegar a convertir en toda una tortura para la persona que no caiga en este detalle.

    En la configuración del extensions.conf, la cosa se complica, ya que además, no solo hay que conocer qué hay detrás de una llamada entre una extensión y otra, si no que además debemos escribirlo a sabiendas que el jefe, cliente o quien vaya a utilizar el sistema, seguro que va a querer cambiar el comportamiento de esta, de manera que todo lo que hagamos debe ser planteado de forma que sea fácil y rápidamente modificable y no nos suponga empezar desde cero.

    Fallos tan garrafales como comunes como poner un Answer() antes del Dial(..), hacen que el sistema no se comporte como esperemos y eso puede provocar grandes pérdidas de tiempo que para una empresa, se convierte en dinero.

  • Cuidado con los servidores DNS en Asterisk

    Muchas personas, para evitar que su servidor Asterisk se quede bloqueado en el caso en que falle la conexión a Internet, suelen recurrir a diversas técnicas (explicación):

    • Utilizar direcciones IP en lugar de nombres de dominio.
    • Añadir los nombres de dominio que vayan a utilizar en el archivo /etc/hosts.
    • Instalar un servidor DNS en la red local que le sirva de caché y aisle las peticiones de resolución de nombres.

    En muchos casos, la primera opción no es viable, ya que muchos proveedores de servicios IP utilizan el mismo nombre de dominio para realizar round-robin y distribuir la carga entre varios servidores con distinta IP pero el mismo nombre de host.

    Son muchos los que optan por instalar el servidor DNS en el mismo sistema o bien dentro de la red local, pero aquí es donde hay que tener especial cuidado.

    Los servidores DNS son accesibles mediante los puertos 53 UDP y TCP (en algunos casos) y si estos son accesibles desde internet, y los utilizan los sistemas de nuestra red puede ocurrir que seamos vulnerables a diversos exploits e «inyecciones falsas» de registros IP/nombres en la caché DNS lo que puede llevarnos a páginas falsas o incluso a ataques phishing.

    Ahora, con las últimas vulnerabilidades encontradas (y publicadas) en el mismísimo protocolo de DNS son muchos los que se están aprovechando de esto.

    Concretamente, hoy he visto logs de ataques y donde consiguen inyectar direcciones IPs de diferentes páginas (de spam y porno por lo general) en servidores Bind.

    Por suerte, hay técnicas para prohibir el acceso al servidor DNS desde direcciones IPs diferentes a las de la red local, desde el propio servidor Bind o bien desde el maravilloso iptables de Linux.

    Así que… cuidado con los servidores DNS que tengamos instalados, no vayan a darnos alguna sorpresa desagradable. 🙂

  • Adiós OpenSer, Hola Kamailio!

    Por la web de Saúl me entero de una noticia sorprendente: el proyecto OpenSER cambia de nombre a Kamailio.

    Como suele suceder en estos casos en los que un proyecto conocido cambia de nombre, es para evitar problemas con marcas registradas y por lo general, pertenecientes a empresas, por lo que además de poder encontrar la información pertinente en la conocida web OpenSER.org, la página web oficial se trasladará a Kamailio.org (actualmente es la misma) aunque la anterior seguirá funcionando durante el traslado.

    La palabra Kamailio es una palabra hawaiiana que significa «hablar o conversar«. Por lo visto esta palabra es fácil de recordar y el significado continua en sintonía con el objetivo de la aplicación. 🙂

    Como indica Saúl, el logotipo no lo han cambiado por ahora, pero seguro que pronto nos toparemos con más novedades como suele ocurrir en estos casos, en los que, aprovechando que se cambia el nombre, también se cambian más cosas. Esperemos que el buen ambiente de la comunidad, y el alto nivel de desarrollo continúen como hasta ahora. 🙂

    Más información: http://www.kamailio.org

  • AsteriskColombia publica un set de voces para Colombia

    Mediante un comentario en la web me avisan que la empresa NetSecuritySolution acaba de publicar un conjunto de voces en español para Colombia llamado K-rem. Pese a que comentan que son voces neutras, la verdad es que un poquito sí que se nota que proceden de Colombia, he de decir que suenan bastante bien y el detalle de haberlo publicado para la comunidad Asterisk, lo que es muy de agradecer y desde aquí le damos las gracias por su apoyo a la comunidad de Asterisk.

    Podeis escuchar un ejemplo de estas fantásticas voces en este enlace: ivrrecording

    No obstante, (ahora una crítica constructiva a esta empresa) para poder descargar este conjunto es necesario «registrarse» en la página web de la empresa NetSecuritySolutions lo cual no aconsejo ya que los comerciales tienen la fea costumbre de enviar spam a todo usuario interesado en Asterisk, y entre esta fea costumbre y lo «originales» que pueden llegar a ser los diseñadores webs utilizando el logo de Asterisk que hice hace algún tiempo para Sinologic con la aprobación expresa de Digium para su uso en este blog (como podeis ver en la imagen de abajo) tan solo me queda animar a esta empresa a que cambien de «estrategia comercial» por alguna más original y sobre todo legal.

    Enlace: http://www.netsecuritysolutionsltda.com
    (Descarga directa)

  • FreeSWITCH 1.0.1 Released!

    Veo que acaban de anunciar la versión 1.0.1 de FreeSWITCH.
    Entre las ventajas que incluye esta versión frente a la versión 1.0, se encuentran:

    • ASR Open Source (mod_pocketsphinx)
    • TTS Open Source (mod_flite)
    • Improved ACL with user matching.
    • Soporte mejorado de SNOM.
      entre otras… 🙂

    Enlace: http://www.freeswitch.org/node/130

  • Softphone SIP para PocketPC y compatible con WM5

    Con el éxito de los PocketPC y móviles-PDA han ido apareciendo últimamente muchos softphones comerciales y alguno que otro gratuito, la mayoría compatibles con SIP y alguno que otro IAX, pero casi todos requieren de Windows Mobile 6. Pues he encontrado uno con una pinta bastante interesante y que funciona con Windows Mobile 5 (WM5).

    SetupVoIP es un softphone SIP bastante curioso y muy, muy simple de configurar y aunque no sea libre, por lo menos, es gratuito (freeware).

    Descargar (mirror 1)
    Descargar (mirror 2)

  • Fedora lanza su servicio de VoIP basada en Asterisk

    Fedora, el grupo de desarrollo Open de RedHat, ha anunciado el lanzamiento de Fedora Talk, un servicio gratuito para aquellos usuarios registrados de Fedora y que permitirá realizar llamadas entre usuarios mediante SIP, así como poder recibir llamadas desde teléfonos (EEUU y UK) para contactar con los usuarios conectados.

    Este servicio está basado íntegramente en Asterisk como indica su página web y esperan crecer y poder ofrecer servicios adicionales.

    El futuro está abierto a interpretaciones 🙂

    Enlace: http://talk.fedoraproject.org/index

  • Asterisk 1.4.21.2 y 1.2.30 Released!

    Empezamos el día con una nueva versión de Asterisk: acaba de ser lanzada 2 nuevas versiones de Asterisk, debido a 2 bugs encontrados en el IAX que han sido gestionados como vulnerabilidades como podeis ver en: AST-2008-010 y AST-2008-011.

    Las nuevas versiones las encontrareis en:
    http://downloads.digium.com/pub/asterisk/

  • Cómo configurar el envío de emails desde Asterisk

    Es una pregunta bastante común y pese a que su respuesta es la misma, voy intentar dejarlo tan claro como sea posible.

    Asterisk es una aplicación, como cualquier otra que corra bajo Linux, y por lo tanto sigue una norma que siguen todas las aplicaciones en Linux: Asterisk NO ENVIA EMAILS, si no que se comunica con el servidor SMTP que tengamos instalado en nuestro sistema local y es este el que envía el email. Incluso si queremos utilizar un servidor remoto con una cuenta, el procedimiento sigue siendo el mismo.

    Por este motivo, y por que todas las aplicaciones en linux funcionan prácticamente igual (apache, pureftpd, syslog, etc…) suelen darle los emails que quieren enviar a una aplicación bastante conocida: SendMail.

    SendMail es un servidor de envío de emails (SMTP) y fue uno de los primeros y más avanzados servidores de este tipo, pero su poca fiabilidad (demasiados bugs para los administradores de redes) unido a su complejidad si queríamos configurar un servidor serio, hizo que apareciesen otros servidores SMTP más ligeros, simples y rápidos que Sendmail.

    No obstante, todos los sistemas continúan intentando enviar emails dejándolos a Sendmail y es por esto por lo que los nuevos y más sencillos servidores SMTP utilizan un truco para hacerse pasar por Sendmail y poder «suplantarlo», esto es, crean un enlace simbólico en el sistema con el nombre «sendmail», de manera que cuando una aplicación intenta acceder a «sendmail», realmente quien contesta es esta aplicación. 🙂

    Como ya he comentado, casi todas las aplicaciones que tienen la necesidad o la opción de enviar emails utilizan el servidor SMTP local, esto ha hecho que muchas distribuciones, para facilitar la configuración y envío de emails, instalen por defecto algunos sustitutos de sendmail como por ejemplo exim o postfix son las más conocidas.

    El principal problema de utilizar el servidor SMTP local es el proveedor: Debido al aumento de correos SPAM, los proveedores y los servidores de correo que van a recepcionar tu email comprobarán si realmente el servidor del que procede el email es realmente un servidor «oficial» o bien un servidor que se dedica a enviar SPAM, y como el servidor local no es realmente un servidor en toda regla (no tiene registros MX en el DNS de algún dominio, tiene una dirección IP dinámica, o ha sido utilizado por otro spamer) es por lo que se aconseja encarecidamente utilizar una cuenta de algún servidor de emails ya verificado y seguro.

    Posiblemente, tras la instalación de nuestra distribución preferida, podremos enviar emails con el comando:

    echo «Prueba de email» |mail -s «Prueba de email» miUsuario@miDominio.com

    Pero cuando hayamos enviado varios de este tipo y empecemos a confiarnos, veremos como nuestro cliente de correo empezará a considerarlo spam, o puede que ni llegue. Es entonces cuando tendremos que configurar nuestro servidor SMTP local para que envíe los emails mediante una cuenta autentificada.

    Para el ejemplo de configuración voy a hacerlo con Exim (el servidor que viene por defecto con Debian), quizá sea uno de los más sencillos de configurar y de manejar, aunque personalmente siempre he preferido Qmail por ser mucho más seguro, no obstante, como nuestro objetivo no es configurar un servidor de correos en toda regla, vamos a hacerlo con Exim (versión 4) que es la que trae Debian (y Ubuntu) de serie.

    Lo primero que tenemos que hacer es asegurarnos que lo tenemos instalado:

    apt-get install exim4 exim4-config

    Una vez que lo hayamos instalado, aparecerá una pantalla de configuración. Si no aparece, podremos acceder a ella en cualquier momento ejecutando el comando:

    dpkg-reconfigure exim4-config

    ¿Sencillo verdad? 🙂

    Será entonces cuando nos pregunte por distintas opciones de configuración:

    – ¿Quiere utilizar archivos separados para la configuración?
    Respondemos SI

    – ¿De qué forma queremos configurar nuestro servidor?
    Respondemos «enviar por SMARTHOST, y recibir por SMTP o Fetchmail»

    – Escriba el nombre del sistema:
    Respondemos con nuestro dominio: miDominio.com

    – Escriba la dirección IP desde donde va a atender las conexiones al SMTP:
    Respondemos: 127.0.0.1

    – Escriba otros servidores destino que el SMTP será aceptado:
    Aquí no respondemos nada, lo dejamos en blanco.

    – Sistemas a los que reenviar emails ?
    No piques, esto también hay que dejarlo en blanco. 😛

    – Escribe el sistema que gestionará el correo saliente de este sistema:
    (Aquí escribimos nuestro servidor SMTP remoto, por ejemplo…)
    smtp.miDominio.com

    Si queremos utilizar una cuenta de gmail, el servidor SMTP de gmail hay que especificarlo junto con el puerto que va a utilizar, y sería esto: smtp.gmail.com::587 (ojo que lleva dos simbolos de dos puntos antes del puerto)

    – ¿Quiere ocultar el nombre local del sistema local del email saliente?
    Pues NO.

    – Quiere cachear las peticiones DNS para ahorrar ancho de banda?
    Pues NO.

    Bien, hasta ahora tenemos algunos parámetros básicos configurados, pero no hemos indicado el usuario ni la contraseña con el que queremos autentificarnos para enviar emails. Si probásemos a enviar emails, seguramente nuestro servidor remoto recibiría un email de un tal root@localhost y nos lo rechazaría. 🙂

    Vamos a configurar los datos importantes:

    1º. – Editamos el archivo /etc/exim4/passwd.client y escribimos algo como esto:

    smtp.miDominio.com:usuario:contraseña

    En el caso de que queramos utilizar la cuenta de email, deberíamos poner algo como esto:

    gmail-smtp.l.google.com:usuario@gmail.com:contraseña
    *.google.com:usuario@gmail.com:contraseña
    smtp.gmail.com:usuario@gmail.com:contraseña

    De esta manera, sea cual sea el nombre del servidor SMTP que utilicemos en gmail, le enviaremos los parámetros correctos y nos aceptará el envío.

    2º.- Protegemos el archivo para que nadie tenga acceso a leer nuestros datos:

    chown root:Debian-exim /etc/exim4/passwd.client

    3º.- Si estamos configurando nuestra cuenta de Gmail, hay que indicarle (otra vez) que el envío debe hacerlo por el puerto 587 en lugar del estandar (el 25), por lo que tendremos que editar el archivo:

    /etc/exim4/conf.d/transport/30_exim4-config_remote_smtp_smarthost

    y justo encima de la línea que dice algo como: (hosts_try_auth…) añadir lo siguiente:
    port=587

    4º.- Por último, vamos a configurar nuestra identificación saliente:

    echo «root@localhost: usuario@miDominio.com" >> /etc/exim4/email-addresses

    Y listo, lo último que nos queda es recargar la configuración:

    ejecutamos: update-exim4.conf (es un comando 🙂

    Y probamos a enviar un email como hemos hecho antes…

    echo «Prueba de email» |mail -s «Prueba de email» miUsuario@miDominio.com

    y veremos cómo nos llega con el usuario y dominio correcto. 😀

    Bueno, parece más complicado de lo que realmente es. Una vez que se ha configurado unos cuantos sistemas con esta técnica, se hace todo diréctamente y sin tener que recordar los pasitos.

    Una vez tengamos esto hecho y podamos enviar emails con nuestra cuenta oficial, entonces podremos recibir los emails que hayamos configurado en el buzón de voz de Asterisk, o incluso nuestras alertas de arranque de asterisk o incluso enviar faxes mediante Hylafax,…

    Más información:
    http://www.exim.org/
    http://wiki.debian.org/GmailAndExim4
    http://wiki.debian.org/PkgExim4