Sinologic

Etiqueta: tutorial

  • Manual de Instalación Debian+Asterisk+FreePBX+A2Billing+Asternic Stats

    Desde Asterisk-Perú nos llega una nota que parece interesante:

    «Este es un intento de realizar un manual de instalación del SO Debian Etch r5, Asterisk 1.4 y FreePBX 2.5, y tratar de hacerlo lo mas gráfico y sencillo posible, donde la idea principal es que cualquier persona sin experiencia pueda comenzar a instalar y utilizar Asterisk, empezando con la instalación del sistema operativo y sus dependencias para luego instalar asterisk y administrarlo via web usando FreePBX»

    Podeis descargar el borrador de aquí:
    http://www.2shared.com/file/4231300/6f3519d3/Instalacin_Debian_Etch_r5Asterisk_14FreePBX_25.html

    Le he estado echando un vistazo y personalmente me ha parecido 10 veces más largo, complicado para alguien que se supone que no sabe, y falto de características necesarias tanto a nivel de seguridad como de configuración. Con Debian la instalación se simplifica casi al punto de no necesitar casi usuario que pulse el «Siguiente, siguiente, siguiente,…» y la instalación del sistema es bastante mejorable, pero bueno… hay muchos «trucos y atajos» que serían interesante implementar. 😛

    No obstante, queda claro que es un borrador y que aún no es definitivo.

    Gracias por el aviso a Erick Manzur

  • La documentación oficial de Asterisk, en VoIP-Info.org

    En la lista de desarrolladores de Asterisk empezó un hilo muy interesante donde se hablaba de incorporar en el código fuente de cada módulo, información textual en XML que permita crear un manual de forma dinámica y así poder disponer de documentación detallada sobre lo que hace cada módulo y parte de Asterisk.

    La idea parece estar dando sus frutos y ya no únicamente se incluye la documentación en el código fuente, si no que además está disponible en el wiki (Nota: cuando me refiero simplemente a «el wiki» me estoy refiriendo, por supuesto a Voip-info.org).

    Aquí teneis el enlace principal del Wiki donde está toda la documentación escrita por el momento:
    http://www.voip-info.org/wiki/view/Asterisk+Documentation

    Una joya que va diréctamente a «favoritos»… 🙂

    Vía AsteriskNews

  • Todo lo que has querido saber de DAHDI

    Nada más revisar el correo, me entero que el equipo de desarrolladores de Asterisk acaba de publicar la primera versión oficial del famoso DAHDI que tanto ha dado que hablar.

    Entra aquí para conocer más información sobre DAHDI.

    En la lista de paquetes publicado hoy se encuentran estos:

    dahdi-linux 2.0.0

    Este paquete DAHDI-LINUX contiene los módulos de kernel necesario para poder utilizar las tarjetas de comunicaciones.

    dahdi-tools 2.0.0

    Las DAHDI-TOOLS son las aplicaciones necesarias para cargar la configuración hacer tests a algunas tarjetas, y algunas cosas más que se irán añadiendo poco a poco.

    dahdi-linux-complete 2.0.0+2.0.0

    El paquete DAHDI-LINUX-COMPLETE es la unión de los dos anteriores, para no tener que descargar dos paquetes independientes.

    El modo de compilación es tan sencillo como siempre lo ha sido el Zaptel:

    cd /usr/src
    wget -c http://downloads.digium.com/pub/telephony/dahdi-linux-complete/dahdi-linux-complete-2.0.0+2.0.0.tar.gz
    tar xvfz dahdi-linux-complete-2.0.0+2.0.0.tar.gz
    cd dahdi-linux-complete-2.0.0+2.0.0
    make
    make install
    make config

    Una vez hecho esto, nos encontraremos con algunos cambios importantes.

    Para empezar, los módulos para las tarjetas ya no se encuentran en el directorio:
    /lib/modules/2.6.XX-X-XXX/misc

    si no que se encuentran en un nuevo directorio:
    /lib/modules/2.6.XX-X-XXX/dahdi

    En este directorio nos encontraremos con algunos módulos conocidos para tarjetas como el wctdm24xxp, wctdm, wcte11xp, wcte12xp, e incluso el pciradio y el xpp.

    Pero también nos encontraremos con otros nuevos:

    dahdi.ko (que sustituye al zaptel.ko)
    dahdi_dynamic*.ko (que sustituye al ztdynamic, al ztd_eth y al ztd_ethmf)
    dahdi_transcode.ko (que sustituye al zttranscode)
    dahdi_dummy.ko (que sustituye al ztdummy)
    y lo más novedoso:
    dahdi_echocan_XXX.ko (completamente nuevos y son los canceladores de eco software que ahora pueden ser cargados y descargados sin necesidad de recompilar el zaptel)

    Para iniciar el DAHDI, tan solo tenemos que reiniciar el sistema, o bien iniciar el servicio:

    asterisk# /etc/init.d/dahdi start
    Loading DAHDI hardware modules:
    wct4xxp: error   wcte12xp: error   wct1xxp: error   wcte11xp: error   wctdm24xxp: error   wcfxo: error   wctdm: error   xpp_usb: done
    No hardware timing source found in /proc/dahdi, loading dahdi_dummy
    Running dahdi_cfg: done.

    Facil ¿verdad?

    Eso sí, DAHDI solo es compatible con versiones de Asterisk 1.4.22 o superior y Asterisk 1.6.0 o superior, versiones inferiores abstenerse. 😛

    Continuar con la lista de cambios…

  • Cómo configurar un fax virtual T38 en Asterisk

    Partiendo que no lo he probado aún (a ver si durante estas necesarias vacaciones puedo dedicarle un ratito), he visto un artículo muy interesante sobre el T38modem, una especie de IAXmodem pero con soporte para enviar faxes mediante T38 con Asterisk.

    Asterisk soporta T38 en modo passthrough en SIP, esto es, lo deja pasar, pero no iniciar ni acabar una llamada.

    Justamente, el T38modem se basa en la misma filosofía que el IAXmodem por lo que sería posible disponer de esta ventaja tal y como comentan utilizando Hylafax como servidor de faxes de la misma manera que podríamos tenerlo con el IAXmodem pero con T38 en lugar de T30. Suena bien, ¿verdad? 😀

    Vamos a ver cómo se hace:

    cd ~
    cvs -z9 -d :pserver:anonymous@openh323.cvs.sourceforge.net:/cvsroot/openh323 co ptlib_unix
    cvs -z9 -d :pserver:anonymous@openh323.cvs.sourceforge.net:/cvsroot/openh323 co -D «5/21/2007 23:59:59» opal
    cvs -z9 -d :pserver:anonymous@openh323.cvs.sourceforge.net:/cvsroot/openh323 co t38modem

    Con esto habremos descargado las librerías y la aplicación t38modem.
    Ahora vamos a compilar:

    cd ~/pwlib
    ./configure
    make
    sudo make install

    cd ~/opal
    ./configure
    make
    sudo make install
    sudo ldconfig

    cd ~/t38modem
    make USE_OPAL=1 USE_UNIX98_PTY=1 opt
    make USE_OPAL=1 USE_UNIX98_PTY=1 install

    Vamos a probar que realmente se ha instalado y funciona…

    /usr/local/bin/t38modem -tt -o /var/log/t38modem.log –no-h323 -u T38modem –sip-listen udp\$127.0.0.1:6060 –sip-redundancy 3 –ptty +/dev/ttyT38-1,+/dev/ttyT38-2,+/dev/ttyT38-3 –route «modem:.*=sip:<dn>@127.0.0.1» –route «sip:.*=modem:<dn>»

    Ahora vamos a preparar la configuración para 3 módems, para lo que supondremos que hemos instalado previamente el servidor Hylafax como indica Julian en su web y continuaremos:

    cp ~/t38modem/HylaFAX/config.ttyx /var/spool/hylafax/etc/config.ttyT38-1
    ln -s /var/spool/hylafax/etc/config.ttyT38-1 /var/spool/hylafax/etc/config.ttyT38-2
    ln -s /var/spool/hylafax/etc/config.ttyT38-1 /var/spool/hylafax/etc/config.ttyT38-3

    Como en el IAXmodem, vamos a modificar el archivo inittab para que esté siempre activa esta aplicación:

    echo «t1:2345:respawn:/usr/sbin/faxgetty ttyT38-1» >> /etc/inittab
    echo «t2:2345:respawn:/usr/sbin/faxgetty ttyT38-2» >> /etc/inittab
    echo «t3:2345:respawn:/usr/sbin/faxgetty ttyT38-3» >> /etc/inittab
    kill -HUP 1

    Reiniciamos el servidor Hylafax:

    /etc/init.d/hylafax restart

    Y chequeamos que todo está funcionando corréctamente:

    cat /var/spool/hylafax/status/ttyT38-1

    Lo que nos debería mostrar un mensaje como este: Running and idle

    Ahora vamos a ver cómo conectamos el T38modem a Asterisk, para lo que crearemos un usuario SIP propio en /etc/asterisk/sip.conf

    [T38modem]
    type=friend
    host=127.0.0.1
    permit=127.0.0.1
    context=outgoing
    port=6060
    allow=all
    canreinvite=no

    y en este mismo archivo, en el contexto [general]:

    t38pt_udptl=yes

    Para enviar faxes, tan solo hay que utilizar algún cliente Hylafax y será el usuario T38modem el que se encargue de hacer la llamada mediante T38 por SIP. 🙂
    Para recibir faxes, como siempre, enviando el fax entrante a SIP/${EXTEN}@T38modem.

    Si a alguien le funciona, se agradece un comentario.
    Si teneis problemas, lo que he dicho antes… a pelearse y googlear un poco. 😛

    Enlace: http://voip-info.org/wiki/view/T38modem+configuration+with+Asterisk

  • 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.

  • 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

  • Como ejecutar aplicaciones durante una llamada

    En la lista de Asterisk-ES a veces se comenta una utilidad que parece que no mucha gente conoce llamada «dynamic features». Oficialmente esta característica forma parte del conjunto de «recursos» que componen Asterisk y que, como su nombre indica, son añadidos dinámicos, lo que realmente significan, recursos que pueden ser accedidos dinámicamente durante una llamada.

    Estos añadidos son por ejemplo, las transferencias, el parking de llamadas y el mapa de aplicaciones (applicationmap), entre otros, y se definen en el archivo features.conf donde vamos a encontrar opciones y una serie de parámetros junto con un código de tecla que debemos pulsar para poder utilizarlos.

    Como ejemplo de estos añadidos encontramos los básicos como:

    • blindxfer (transferencia ciega)
    • atxfer (transferencia atendida)
    • automon (grabación bajo demanda)
    • pickupexten (captura de llamadas que suenan en los terminales del «grupo»)
    • automixmon (grabación bajo demanda y posterior mezcla de las locuciones)

    Hay una parte muy interesante llamada applicationmap que consiste en una serie de combinaciones que podemos modificar para ejecutar aplicaciones básicas de dialplan, durante una conversación.

    Por ejemplo: testfeature => #9,peer,Playback,tt-monkeys

    Este comando permitirá que cuando el llamante como el llamado durante una conversación, pulse las teclas # y 9, se reproduzca la locución tt-monkeys, algo muy gracioso, pero muy interesante en ciertos momentos.

    Existe una limitación para este tipo de comandos, y es que no es recomendable utilizarlo para ejecutar aplicaciones relacionadas con el dialplan directo, es decir: Macro, Goto, Background, WaitExten y algunas de este tipo, pero en cambio sí que se puede ejecutar un «AGI(aplicacion.agi)» 😛

    Para evitar el uso accidental de este tipo de comandos on-line, se hace necesario habilitar dicho comando mediante una variable llamada DYNAMIC_FEATURES justo antes de hacer la llamada: Set(DYNAMIC_FEATURES=testfeature)

    En Asterisk 1.6, nos encontramos algunas novedades bastante interesantes, como:

    • atxferdropcall (permite no perder la llamada en caso de que la transferencia no se realice corréctamente, en cuyo caso volvería a sonar en el usuario que inició la transferencia)
    • atxfernoanswertimeout (permite cambiar el timeout que una llamada transferida esté a la espera antes de volver a la extensión que inició la transferencia)
    • Grupos para habilitar varios applicationmaps sin necesidad de definirlos todos:
      Set(DYNAMIC_FEATURES=grupo)

      donde:
      [grupo]
      testfeature=>#9

    Grandes cosas se pueden llegar a hacer utilizando estas ventajas de Asterisk que son poco conocidas pero muy, muy útiles si se conocen.

    Que lo disfruteis. 😀

  • Empezar con Asterisk

    Hoy en una conversación con unas personas que no conozco de nada, he escuchado una comparativa bastante curiosa sobre un software y una casa, y realmente después de pensar he hecho un simil sobre la forma que tienen muchas personas de instalar una aplicación y utilizarla, como si estuviesemos hablando de una aplicación tan sencilla como el Notepad de Windows.

    Asterisk es una aplicación que corre bajo el sistema operativo GNU/Linux (que el amigo RMS no se me mosquee otra vez), por lo tanto, intentar ejecutarlo en otro sistema no compatible es como intentar construir una casa en el agua, o flotando a 5m., directamente no se puede o no es viable.

    Asterisk también es una aplicación que maneja conceptos tan amplios (no voy a decir difíciles, simplemente amplios) como la telefonía, y las redes de datos, así, esto es algo que la persona que quiera instalar un Asterisk debe conocer al menos, una base, saber porqué y cómo. Debemos saber que una casa tiene puertas y ventanas, y debe estar asentada en un suelo plano y fijo. Si construimos nuestra casa sobre barro o sin puertas, de poco nos va a servir.

    Además de estos conceptos, es necesario conocer otros como: qué es un protocolo, en qué consiste eso que llaman «VoIP», puertos que se utilizan, de qué tipo, etc., de la misma manera que debemos saber que una casa debe tener un cuarto de baño, un dormitorio, una cocina,…

    Para colmo, y como excepción a este tipo de aplicación, debemos saber cómo configurar esta aplicación para que haga lo que queremos: Qué muebles son necesarios poner y dónde, así nuestra casa puede ser medianamente habitable y podamos sentirnos agusto en ella.

    Una vez que tengamos hecho todo esto, podremos empezar a aprender a utilizar Asterisk en condiciones.

    Muchas personas empiezan la casa por el tejado, o bien comprando directamente una casa prefabricada que en cuanto hace un poco de viento se desploma y que, como no saben nada de configurar, terminan poniendo el WC como mesita de noche al lado de la cama y frente a la freidora.

    Así que… un consejo para aquellos que esteis empezando…

    Dedicadle tiempo a aprender los conceptos básicos, a familiarizaros con la configuración y a buscar y buscar información sobre cómo se hace, y no tanto preguntar para conseguir construir una casa rápidamente, o la terminareis haciendo con hojas y palillos y tarde o temprano se os caerá encima cuando esteis durmiendo en la cocina.

    Si teneis que aprender de forma urgente, apuntaos a uno de tantos cursos sobre Asterisk que seguramente hay cerca de donde vivís.

    Si pensais que utilizando una distribución prefabricada tipo TrixBox/Asterisk-GUI/Elastix vais a conseguir montar un Asterisk serio y rápido, estais equivocados, el Asterisk ya estará montado y medio configurado y no habreis aprendido nada y fallareis donde siempre fallan los que empiezan así, en la base.

    Para comenzar, unos enlaces interesantes con documentación aún más interesante:

    Feliz aprendizaje de Asterisk. 😀

  • Aclarando conceptos sobre SIP y VoIP

    El protocolo SIP (que significa Protocolo de Iniciación de Sesiones) nació en 1996 cuando Mark Handley y Eve Schooler presentaron el primer borrador ante la IETF de lo que sería un protocolo de comunicaciones IP que solucionaría gran parte de los inconvenientes de protocolos anteriores.

    En este borrador se exponían conceptos nuevos y que posteriormente pasaría a utilizarse en todo el mundo como uno de los protocolos más utilizados en las aplicaciones de mensajería instantánea, aplicaciones CRM, ERP y por supuesto VoIP. Entre estos nuevos conceptos destaca alto tan básico como el «registro», por el cual un usuario informaba a la red dónde podía recibir invitaciones de comunicaciones por parte de otros usuarios, lo que permitía que un usuario pudiera recibir un mensaje en su casa y si luego se trasladaba al trabajo y se «registraba», el mensaje lo recibiera en el trabajo y no en su casa.

    El protocolo SIP es un protocolo de señalización, es decir, SIP no transporta audio ni vídeo, por lo que sería incompleto decir que en una comunicación de VoIP en SIP solo interviene este protocolo que se transmite por el puerto 5060 TCP o UDP.

    Entonces ¿como se puede enviar audio y vídeo por SIP?. Sencillamente, no se puede, SIP no está diseñado para esto, aunque sí que permite indicar el sistema y el puerto por el que se puede enviar un flujo de datos que encapsula la voz y el vídeo. Para este flujo de datos se utiliza otro protocolo: SDP (que significa “Session Description Protocol” en español «Protocolo de Descripción de Sesiones«) y envía los parámetros de inicialización de audio y vídeo transmitidos por streaming por varios puertos UDP altos (por encima del 1024)

    La comunicación SIP se realiza entre lo que se denominan «Agentes de Usuario SIP» comúnmente conocido como «usuario SIP», «Servidores de Registro» también conocido como «SIP Server» y «SIP Proxy» también conocido como «SIP Proxy» 😛

    – Usuarios SIP:
    Un usuario SIP puede ser una aplicación de mensajería, un softphone, un teléfono IP, y en general cualquier dispositivo o software que sea compatible con SIP y que tenga la capacidad de «registrarse» con una cuenta SIP. Los usuarios SIP reciben una URI formada por «usuario»@»dominio» donde el campo dominio se corresponde con el Servidor SIP donde se encuentra registrado.

    – Servidor SIP:
    Un servidor SIP es una aplicación o dispositivo que permite crear y gestionar cuentas SIP y permitir que los Usuarios SIP se «registren» almacenando la dirección IP donde deben acceder para realizar la comunicación con este usuario.

    – Proxy SIP:
    Un Proxy SIP es una aplicación que permite que cualquier usuario SIP envíe un comando a otro usuario SIP.

    Con estos tres conceptos claros, empieza la parte divertida, cuando dos usuarios SIP quieren hablar entre si, hace falta:
    – Dos usuarios SIP (100@dominio y 200@dominio)
    – Un servidor SIP donde se registrarán los dos usuarios
    – Un proxy SIP para enviar los paquetes necesarios desde uno de los usuarios al otro para empezar a establecer una comunicación.

    Una vez establecida la comunicación, el envío de los paquetes streaming de audio y vídeo se realiza únicamente y exclusivamente entre la aplicación registrada como 100@dominio y la aplicación registrada como 200@dominio, por lo que queda demostrado que SIP es un protocolo P2P tan mal visto por los medios de comunicación. 🙂
    En este caso, el usuario 100@dominio también podría iniciar la comunicación introduciendo el usuario 200@direccionIP donde «direccionIP» sería la que tuviese ese usuario en ese instante. ¿pero qué ocurre cuando el usuario cambia de IP? ¿Perdemos la posibilidad de llamarle? Justamente para eso sirve el servidor SIP y el Proxy SIP.

    Aprovechando estas definiciones interesantes, me gustaría aclarar algunas más relacionadas con la VoIP:

    – B2BUA (Back 2 Back User Agent)
    El B2BUA es una aplicación para controllar llamadas entre usuarios SIP y se diferencia de un Proxy SIP en que este únicamente gestiona el estado de una llamada cuando se realiza, mientras que el B2BUA mantiene el estado de las llamadas y las mantiene para conseguir información valiosa en determinados entornos como facturación, redireccionamiento de llamadas en caso de caída de un proveedor SIP, etc.
    Asterisk es mucho más que un B2BUA ya que no únicamente controla todo esto, si no que incluso puede llegar a realizar acciones que ni un Proxy SIP ni un B2BUA pueden realizar como: grabaciones de llamadas, sistemas de buzón de voz, reproducción de locuciones, ofrecer menús IVR, reproducir música en espera, y un larguísimo etc.

    – Media Gateway (MGW)
    El Media Gateway es una aplicación o dispositivo que convierte la señalización SIP y el audio streaming, recibidos por SIP en el formato necesario para que sea transportado por otra «tecnología» como líneas analógicas, digitales, diferentes protocolos IP, etc.

    – Softswitch
    El Softswitch es una aplicación o dispositivo que realiza las labores de un Proxy SIP y un Media Gateway.
    Ejemplo de softswitch es el conocido FreeSwitch al que además le han añadido algunas opciones más típicas de centralitas.

    – PBX
    Un PBX es una centralita basada en la red telefónica (analógica, digital o incluso móvil) que realiza las acciones que ya conocemos de toda centralita: gestionar transferencias, programar menús IVR, grabar conversaciones, etc.

    – Media Server
    Un Media Server es un dispositivo o aplicación que permite almacenar contenido multimedia (audio, vídeo, imágenes, etc…) y que puede enviarla mediante algún tipo de protocolo sin importarle a quien.
    Es un reproductor de contenido multimedia que se conecta a cualquiera de los sistemas que he mencionado con anterioridad y ofrece este contenido a uno o varios usuarios.
    Tras esta breve explicación, espero que estos conceptos hayan quedado más claros y evitar utilizar una aplicación para realizar tareas más propias de otras. 🙂

  • Cómo analizar datos VoIP con EtherReal (Wireshark)

    Hace tiempo que conozco esta aplicación y, aunque me gusta más utilizar otras modo texto y algunos «trucos» shell scripts para encontrar lo que suelo buscar, se puede decir que la aplicación para analizar datos de la red más popular es sin duda Etherreal (ahora llamada Wireshark) por funcionar en Linux y en Windows y en modo gráfico que eso siempre gusta a muchos. 🙂

    Como es bien sabido, hay ciertos factores «medio-ambientales» que influyen en toda comunicación, esto es… cierta configuración de un router afecta al tipo de NAT y por lo tanto al registro de extensiones externas a la red, la utilización de opciones «desconocidas» puede acarrear que los terminales tengan cortes o incluso no lleguen a ver la IP del Asterisk, etc., es entonces cuando se requiere utilizar herramientas de análisis de la red para conocer exáctamente qué está provocando estos problemas.

    Acabo de encontrar un tutorial muy interesante en inglés sobre cómo configurar y extraer los datos interesantes (en una red VoIP) utilizando la herramienta Wireshark.

    El tutorial lo podeis encontrar aquí:
    http://www.panoramisk.com/151/analyzing-voip-with-wireshark/en/#more-151