Una vez más y por la respuesta obtenida, nuestra fecha de cursos del 21 al 24 de septiembre se llenó. Por la demanda, abrimos una nueva fecha en octubre, quedando así 2 en el mismo mes.
El calendario próximo queda como sigue:
Para cualquier duda relacionada con nuestros cursos, visiten la página de nuestros cursos o háganos llegar sus dudas a través de nuestro formulario de contacto.
¡Los esperamos pronto!
El eco en una señal de telefonía ocurre cuando tenemos 2 conductores a diferentes impedancias. El desacople de las mismas ocasiona que la señal se refleje y se perciba por nuestro cerebro como 2 señales diferentes. Si el eco es superior a 150ms, comienza a volverse molesto ya que como humanos nos distrae de la conversación que estamos teniendo.
En un sistema 100% VoIP el eco no existe. Definitivo: no existe. Sin embargo, dado que aún ocupamos medios analógicos para poder nosotros enviar o recibir el audio (micrófonos y altavoces), es en estos dispositivos donde el eco puede ocurrir. El punto más común donde se produce el eco es en el medio que ocupemos para conectarnos con medios 100% analógicos, como la línea telefónica, así que es responsabilidad de nuestras tarjetas o gateways, hacerse cargo de cancelar este eco, ya sea mediante hardware o software (recuerden que en VoIP, la voz al final son datos, y los datos pueden manipularse por software).
Para poder manipular el eco en Asterisk tenemos 2 opciones:
Para opciones de hardware podemos comprar tarjetas que soporten esta característica. En tarjetas Sangoma podemos ir por los modelos que tengan la letra D (como la B600DE, A200DE, A101DE). El problema con estas tarjetas es que no son actualizables, es decir, no podemos comprar el módulo de cancelador de eco después. Las tarjetas Digium tienen la ventaja de que podemos adquirir el módulo de cancelador de eco por separado, asi nuestra inversión está asegurada.
En este artículo nos centraremos en las soluciones para software, ya que la mayoría de nosotros tiene equipos que no cuentan con el módulo en HW necesario para lograr esta función, y para hacerlo, primero haremos la instalación de OSLEC (Open Source Line Echo Canceller), la cual, tiene que ser compilada dentro de DAHDI.
Empezando con el trabajo: primero necesitamos conseguir el código fuente de DAHDI y también el código fuente de Wanpipe (los drivers de Sangoma que contienen la referencia a OSLEC).
cd /usr/src wget http://downloads.asterisk.org/pub/telephony/dahdi-linux-complete/releases/dahdi-linux-complete-2.4.1.2+2.4.1.tar.gz wget ftp://ftp.sangoma.com/linux/current_wanpipe/wanpipe-3.5.22.tgz tar -zxf dahdi-linux-complete-2.4.1.2+2.4.1.tar.gz tar -zxf wanpipe-3.5.22.tgz
Quizá se pregunten: ¿por qué descargar wanpipe si lo podemos conseguir en el código fuente de Linux? Simplemente porque wanpipe es más pequeño y tarda menos en descargarse.
Luego, creamos las carpetas necesarias dentro del código de DAHDI y copiamos la parte de OSLEC que necesitamos:
cd /usr/src/dahdi-linux-complete-2.4.1.2+2.4.1/linux/drivers mkdir staging cp -r /usr/src/wanpipe-3.5.22/OSLEC/echo staging
En este punto, hay 2 archivos que debemos de modificar:
/usr/src/dahdi-linux-complete-2.4.1.2+2.4.1/linux/drivers/staging/echo/Kbuild
/usr/src/dahdi-linux-complete-2.4.1.2+2.4.1/linux/drivers/dahdi/Kbuild
Empezamos por el primero (el cual está vacio). Solo necesita que agreguemos una línea en su interior:
# # Archivo /usr/src/dahdi-linux-complete-2.4.1.2+2.4.1/linux/drivers/staging/echo/Kbuild # obj-m += echo.o
El segundo archivo si tiene contenido. Buscamos un contenido similar a este:
# Archivo: /usr/src/dahdi-linux-complete-2.4.1.2+2.4.1/linux/drivers/dahdi/Kbuild # Only enable this if you think you know what you're doing. This is not # supported yet: #obj-m += dahdi_echocan_oslec.o # # A quick and dirty way to build OSLEC, if you happened to place it # yourself in the dahdi source tree. This is experimental. See README # regarding OSLEC. #obj-m += ../staging/echo/
Quitamos el comentario a las 2 lineas de código para dejarlo así:
# Archivo /usr/src/dahdi-linux-complete-2.4.1.2+2.4.1/linux/drivers/dahdi/Kbuild # Only enable this if you think you know what you're doing. This is not # supported yet: obj-m += dahdi_echocan_oslec.o # # A quick and dirty way to build OSLEC, if you happened to place it # yourself in the dahdi source tree. This is experimental. See README # regarding OSLEC. obj-m += ../staging/echo/
Procedemos a recompilar DAHDI desde nuestra carpeta /usr/src/dahdi-linux-complete-2.4.1.2+2.4.1
cd /usr/src/dahdi-linux-complete-2.4.1.2+2.4.1 make make install
2 passos más: editamos /etc/dahdi/system.conf
# # Archivo /etc/dahdi/system.conf # # Tomen en cuenta reemplazar sus canales por los de su equipo # En este ejemplo tengo una tarjeta de 4 puertos FXO fxsks=1-4 echocanceller=oslec,1-4
Y aplicamos los cambios desde el CLI de Linux:
dahdi_cfg -vv DAHDI Tools Version - 2.4.0.1 DAHDI Version: 2.4.0.1 Echo Canceller(s): OSLEC Configuration ====================== Channel map: Channel 1: FXS Kewlstart (Default) (Echo Canceler: oslec) (Slaves: 01) Channel 2: FXS Kewlstart (Default) (Echo Canceler: oslec) (Slaves: 02) Channel 3: FXS Kewlstart (Default) (Echo Canceler: oslec) (Slaves: 03) Channel 4: FXS Kewlstart (Default) (Echo Canceler: oslec) (Slaves: 04)
Si todo carga sin errores, ¡listo! tenemos habilitado el cancelador de eco OSLEC, que es considerablemente mejor contrarestando el eco que el default de MG2.
Estos pasos son bastante buenos para reducir el eco de nuestra línea, pero si aún así tenemos problemas, podemos usar fxotune para virtualmente, eliminar el eco remanente. Es muy sencillo de usar. El procedimiento sería el siguiente:
Visto en código sería algo así:
/etc/init.d/asterisk stop fxotune -i # Esto puede demorar algunos minutos echo 'fxotune -s' >> /etc/rc.local /etc/init.d/asterisk start
Nota final: El fxotune debe ser ejecutado cuando Asterisk NO está corriendo. En el ejemplo anterior, estoy agregando el fxotune -s al rc.local para que cargue en automático, pero esto hará que tras el re-arranque, se ejecute hasta después de que Asterisk ya inició (lo cual no está bien). Si queremos asegurarnos que cargue siempre, podemos agregar al rc.local las instrucciones para que Asterisk se detenga, se ejecute fxotune y luego re-arranque Asterisk. Hay muchas maneras de hacer esto, pero eso escapa a la intención de este artículo.
Siguiendo todos estos pasos, el eco debe quedar prácticamente eliminado. Hasta el momento he hecho instalaciones que han mantenido eco con uno de estos pasos, pero nunca alguno que haya persistido con los 2.
¡Suerte!
En numerosas ocasiones he usado el Endpoint Configurator de Elastix para facilitar la configuración de múltiples teléfonos de manera rápida y sencilla. Sin embargo, recientemente que empecé a ocupar los teléfonos Cisco SPA502G y SPA504G me topé con que Elastix no los reconoce (o al menos, no directamente), así que no podía usar el configurador automático con ellos.
Los teléfonos de la serie SPA provienen de Linksys, el fabricante de equipo de red para SoHo que Cisco adquirió, pero estos a su vez provienen de Sipura, que es un fabricante que pocos conocen y que hace mucho tiempo, Linksys compró. La configuración entre los diferentes modelos no ha cambiado mucho a pesar de los años, así que un Cisco SPA504G se configura prácticamente igual que un Linksys SPA942, y esos SI son detectados por el configurador de Elastix.
Entonces… ¿Cómo hacemos para que Elastix detecte estos nuevos modelos?
Una forma muy sencilla es engañando al configurador, haciéndolo creer que se tratan de SPA942. Para hacerlo, solo tenemos que agregar las MACs de Cisco dentro del archivo /var/www/db/endpoint.db (el cual viene en formato de sqlite). El código sería el siguiente:
sqlite3 /var/www/db/endpoint.db sqlite> INSERT INTO "mac" VALUES(45, 4, 'C8:9C:1D', 'Cisco - SPA504G'); sqlite> INSERT INTO "mac" VALUES(46, 4, 'E0:5F:B9', 'Cisco - SPA504G'); sqlite> .quit
Estas 2 series de MACs, la E0:5F:B9 y la C8:9C:1D son las que por experiencia he encontrado que estos nuevos teléfonos tienen. ¿Qué quieren decir los otros campos?
Tras hacer el cambio, podemos re-ejecutar el endpoint y obtendremos algo como esto:
Esto nos indica que nuestros teléfonos ya fueron reconocidos, así que podemos aplicar la configuración de la extensión para configurar nuestros nuevos teléfonos.
¡Suerte!
Dada la alta demanda que tuvimos para nuestros cursos del 4 al 7 de agosto (y para la cual ya tenemos cupo lleno), decidimos abrir una segunda fecha intensiva:
Además de la fecha en Monterrey que ya teníamos programada:
El cierre de nuestra fecha de julio es esta semana, el próximo viernes 22/julio. Para más información puedes consultar la página de nuestros cursos o bien, envíamos un mensaje a través de nuestro formulario de contacto.
Desde alrededor de las 18:00hrs del sábado 16/julio hasta este momento he estado haciendo tareas de migración en el servidor que hospeda a esta página. Por tal motivo, es problable que algún URL arroje algún error pues todavía hay detalles que me falta afinar.
Si alguien detecta que algo no esta funcionando como debiera, por favor hágamelo saber en los comentarios.
Saludos,
En ocasiones anteriores he hecho la mención de fail2ban, una herramienta escrita en Python que analiza logs del sistema y responde en caso de que ciertas condiciones se cumplan, por ejemplo, 5 intentos de contraseña SSH equivocada en un periodo de 10 minutos. Dada la proliferación de ataques a equipos Asterisk para tratar de hacer llamadas de larga distancia, tiene sentido que ocupemos esta herramienta para protegernos de los amantes de lo ajeno.
Ahora bien, ¿cómo configuramos esta herramienta para que nos evite los cargos de miles de dólares en llamadas fantasmas?
Primero, lo instalamos. En Debian podemos usar el mundialmente reconocido apt-get:
apt-get install fail2ban
O, si tenemos Centos, primero asegurémonos de que tengamos EPEL (un repositorio que nos da acceso a mucho software útil) y luego instalamos fail2ban:
rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm yum -y install fail2ban
Fail2Ban se configura en 2 partes básicas:
Editemos el archivo jail.conf y agreguemos esto hasta abajo:
[asterisk-iptables] enabled = true filter = asterisk action = iptables-allports[name=ASTERISK, protocol=udp, port=5060] sendmail-whois[name=ASTERISK, dest=micorreo@algunmail.com, sender=fail2ban@example.org] logpath = /var/log/asterisk/full maxretry = 5 findtime = 600 bantime = 10800
Lo que estamos especificando es lo siguiente:
En esta liga encuentras el manual oficial para el jail.conf.
Ya definido el jail, necesitamos crear el filtro que atrapará los ataques. Esto se define (de acuerdo a lo que especificamos arriba) en el /etc/fail2ban/filter.d/asterisk.conf (los valores con # son comentarios, solo se dejan por referencia)
[INCLUDES]
# Read common prefixes. If any customizations available -- read them from
# common.local
#before = common.conf
[Definition]
#_daemon = asterisk
# Option: failregex
# Notes.: regex to match the password failures messages in the logfile. The
# host must be matched by a group named "host". The tag "<HOST>" can
# be used for standard IP/hostname matching and is only an alias for
# (?:::f{4,6}:)?(?P<host>S+)
# Values: TEXT
#
failregex = Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Wrong password
Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - No matching peer found
Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Device does not match ACL
Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Username/auth name mismatch
Registration from '.*' failed for '<HOST>(:[0-9]{1,5})?' - Peer is not supposed to register
NOTICE.* <HOST> failed to authenticate as '.*'$
NOTICE.* .*: No registration for peer '.*' (from <HOST>)
NOTICE.* .*: Host <HOST> failed MD5 authentication for '.*' (.*)
VERBOSE.* logger.c: -- .*IP/<HOST>-.* Playing 'ss-noservice' (language '.*')
# Option: ignoreregex
# Notes.: regex to ignore. If this regex matches, the line is ignored.
# Values: TEXT
#
ignoreregex =
Se observa que estamos tratando de atrapar a los siguientes:
En esta liga encontramos el manual de los filtros de fail2ban.
Finalmente, solo nos queda activar el servicio. En Debian ya quedó instalado automáticamente, solo tenemos que arrancarlo:
/etc/init.d/fail2ban start
En CentOS, tenemos que habilitar el autoarranque para que inicie al arrancar el equipo:
chkconfig --add fail2ban chkconfig fail2ban on /etc/init.d/fail2ban start
Fail2ban es un excelente apoyo contra ataques que dejan registros en logs y no solo nos sirve para Asterisk, también para SMTP, SSH, HTTP o cualquier otra cosa que queramos monitorear. Esto, en conjunción con buenas prácticas de seguridad para Asterisk, nos darán un sistema más confiable y menos propenso a sufrir daños por parte de atacantes.
¡Suerte!
Si alguno de ustedes es como yo, muy probablemente les guste batallar con los betas. Suelo ser de aquellos que en cuanto sale una nueva versión corro a adoptarla, no importándome los problemas de estabilidad o soporte extra que esto conlleva. Sin embargo, hay algunos casos en los que definitivamente no es posible sacrificar la confiabilidad de un sistema, aunque esto nos traiga nuevas funcionalidades.
En sus inicios yo literalmente brinqué de Asterisk 1.0 a 1.2 sin pensarlo, lo mismo 1.2 a 1.4, y esto es hablando en entornos en producción (mala idea, yo sé, afortunadamente funcionó bien), pero cuando quise hacer lo mismo para 1.6 me paré en seco: mis sistemas se caían sin razón aparente, muchas cosas cambiaron, el AgentCallbackLogin dejó de existir y en general fue una experiencia poco placentera, al grado que decidí quedarme con 1.4 (y hasta la fecha) lo he seguido haciendo.
Con la reciente noticia de que Asterisk 1.4 alcanzó su último maintenance release, el momento de hacer el cambio es ahora. Muchos colegas en la materia opinarán que la 1.6 nunca acabó de ser lo que se esperaba. Yo digo a mis alumnos en los cursos (bajo opinión personal) que Asterisk 1.6 fue el Windows Vista de Digium: para cuando ya se corrigieron la mayor parte de los detalles que tenía, salió Asterisk 1.8, así que el salto sería directo, de 1.4 a 1.8, sin pasos intermedios. Opino yo: ¿para que hacer 2 migraciones cuando se puede hacer una sola?
Cuando nos queremos actualizar, leer los changelogs desde 1.4 a 1.8 puede resultar abrumador: simplemente son demasiados cambios para darnos cuenta de que tanto es lo que tenemos que mover en nuestros planes de llamadas y nuevos campos de configuraciones. Afortunadamente, existe la página de Asterisk Up-to-speed.
En este sitio están concentrados todos los cambios entre versiones 1.4 –> 1.6.0 –> 1.6.1 –> 1.6.2 –> 1.8, de manera que resulta mucho más fácil darle una leida para ver que tanto cambio conforme a lo que usamos, así como aprender cuales son las nuevas funcionalidades sin tener que repasar todo el manual de aplicaciones. Es una referencia literaria bastante buena y fácil de usar y se las recomiendo a todos aquellos que como yo, estuvieron muy cómodos con la versión 1.4 y decidieron evitar en lo más posible el salto entre versiones.
Recuerden que no hay día que no llegue ni plazo que no se cumple. Si no lo han hecho, conviene que vayan invirtiendo tiempo en planear sus migraciones. Mejor pensarlo bien cuando hay tiempo, y no cuando se tenga la presión de hacer una nueva instalación.
¡Suerte!
Muchas veces me han pregunado si Asterisk soporta MP3 como música en espera: la respuesta es si y no. Debo decir que si porque en efecto, con el módulo format_mp3 se pueden reproducir MP3, pero debo decir no porque solamente se soportan los de bitrate constante (y hoy en día, prácticamente todos son de bitrate variable, o VBR), además de que el consumo de CPU causado por el transcoding realmente puede afectar al sistema.
Entonces, ¿cómo podemos hacer para convertir nuestra colección favorita de audio MP3 a wav, gsm, ulaw o cualquier otro de los formatos que Asterisk soporte? El mecanismo es más sencillo de lo que se cree, siempre y cuando se tengan los conocimientos mínimos de Linux para hacerlo.
apt-get install sox libsox-fmt-mp3
[/codesyntax]
Si tu música ya está en un formato que Asterisk soporta (ej. wav mono a 16-bit 8khz), brinca al paso 3
# Para Asterisk 1.8+ for i in `ls *.mp3` do sox $i -r 16000 -c 1 -s -w `echo $i|cut -d. -f1`.wav rename 's/.wav/.wav16/' *.wav done # Para Asterisk menor a 1.8 for i in `ls *.mp3` do sox $i -r 8000 -c 1 -s -w `echo $i|cut -d. -f1`.wav done
[/codesyntax]
#!/bin/bash for i in `find $1 -name "*.$2"` do j=`echo $i | cut -d . -f 1` asterisk -rx "file convert $j.$2 $j.$3" done
[/codesyntax]
./convierte.sh /var/lib/asterisk/moh wav gsm
[/codesyntax]
Lo argumentos que el script recibe son:
El resultado es que tendrás una carpeta con varios archivos (los originales MP3, los intermedios wav y los finales en el codec que escojas). Puedes convertir a cuantos codecs quieras siempre y cuando Asterisk los soporte.
Estos pasos también son válidos si tienes tus archivos de audio en un codec (en la carpeta /var/lib/asterisk/sounds) y quieres convertirlo a otro codec completamente diferente.
¡Suerte!
El pasado sábado 25 de junio terminamos una fecha más de cursos en México DF. Quiero agradecer a todos los que lo hicieron posible al estar con nosotros durante los 4 días que duró y en los cuales cubrimos Asterisk completamente: desde aprender lo que es Linux, a crear un marcador predictivo utilizando archivos de llamadas y AGIs.
Ante la constante demanda que ha habido en los últimos meses por nuestros cursos, nos es muy grato hacer públicas las nuevas fechas y ciudades para nuestros próximos cursos:
Curso básico (2 días)
– México, DF. 30 y 31 de julio
– México, DF. 4 y 5 de agosto
– Monterrey, Nuevo León. 10 y 11 de agosto
Curso completo (básico, intermedio y avanzado) fin de semana
– México, DF. 30 y 31 de julio, 6 y 7 de agosto
Curso completo (básico, intermedio y avanzado) intensivo
– México, DF. 30 y 31 de julio
– México, DF. 4, 5, 6 y 7 de agosto
– Monterrey, Nuevo León. 10, 11, 12 y 13 de agosto
Para obtener más información, puedes consultar nuestra página de Cursos Asterisk o bien, enviarnos un correo electrónico a través de nuestro formulario de contacto.
¡Esperamos pronto tenerte con nosotros!
Una gran ventaja que tenemos en Linux es la facilidad de crear procesos automatizados que nos ayuden a ejecutar tareas cotidianas. Para nuestros usos comunes como administrador de equipos basados en Asterisk/Elastix/FreePBX, puede ser una labor cotidiana respaldar la configuración alojada en bases de datos de MySQL.
SSH nos permite ejecutar comandos en servidores Linux remotos y traernos el resultado al mismo tiempo, por lo que resulta ideal para realizar un respaldo en un equpo distante y almacenarlo en nuestro equipo Linux loca. El comando para hacerlo sería el siguiente (asumiendo que usamos la contraseña default de MySQL en nuestro equipo remoto):
[codesyntax lang=»bash»]
ssh 192.168.1.100 "mysqldump -peLaStIx.2oo7 --databases asterisk | gzip -9" > respaldo.sql.gz
[/codesyntax]
El comando de arriba se encargará de hacer un dump de la BD asterisk. Si quisiéramos traernos también el CDR, hariamos lo siguiente:
[codesyntax lang=»bash»]
ssh 192.168.1.100 "mysqldump -peLaStIx.2oo7 --databases asterisk cdr | gzip -9" > respaldo.sql.gz
[/codesyntax]
O si quisiéramos traernos TODAS las bases de datos:
[codesyntax lang=»bash»]
ssh 192.168.1.100 "mysqldump -peLaStIx.2oo7 --all-databases | gzip -9" > respaldo.sql.gz
[/codesyntax]
Hay que tomar en cuenta que estamos asumiendo lo siguiente:
Adaptando este comando podemos prácticamente hacer cualquier tipo de respaldo remoto. Si agregamos la conexión mediante llaves públicas y privadas, podemos dejar estas actividades programadas en el cron para no tener que estar proporcionando la contraseña de SSH cada vez que nos conectamos.
¡Suerte!