Las extensiones internas se bloquean cuando el acceso a internet se cae. ¿Cómo resolverlo?

29 Jul

Este es un problema viejo y aunque la solución puede encontrarse buscando por internet, quise tomarme unos minutos para escribir un breve post que habla del problema y como resolverlo.

Estoy seguro que a varios les ha pasado: tienes tu conmutador configurado perfectamente y todo marcha bien. De pronto, de la nada, tus extensiones internas se caen: no haces ni recibes llamadas. Revisas un poco y te das cuenta de que no tienes internet. ¿Pero para que necesito internet si mis extensiones son internas? ¿Qué tiene que ver una cosa con la otra? Es ahí donde entramos.

El problema radica en la manera en como Asterisk resuelve los dominios de las troncales SIP a donde necesita conectarse. El canal SIP utiliza un método de consulta de DNS síncrono, lo que quiere decir que cuando llega una petición de resolver un DNS (ej. siptrunk.alianza.com) el canal SIP le pregunta al servidor DNS, espera la respuesta, y cuando finalmente la obtiene continú con su siguiente petición SIP. En un mundo ideal esto no es problema, ya que la resolución por DNS es muy rápida y toma unos cuantos milisegundos, por lo que normalmente no la notamos. Pero… ¿qué ocurre cuando por alguna falla en internet, el servidor de DNS al que solemos apuntar se cae o simplemente no podemos acceder a él? Pues la respuesta es que esto provoca un efecto  dominó en Asterisk que ocasiona que todo el canal SIP se caiga.

¿Cómo puede pasar esto?

Imagina el siguiente caso:

  1. Juan quiere hacer una llamada a través de su troncal de pbx.micarrier.com, así que levanta su teléfono y llama al número deseado.
  2. Asterisk recibe la petición de llamada y le manda a su DNS la solicitud de resoler pbx.micarrier.com, pero al utilizar paquetes por UDP, Asterisk no se da cuenta de que el equipo está offiline, así que le da un cierto tiempo de timeout a que el servidor responda.
  3. Mientras que Asterisk espera a recibir la respuesta, Jorge desea hacer una llamada a través de pbx.miotrocarrier.com, pero aún no puede enviar la llamada porque Asterisk está ocupado con la petición anterior.
  4. Para cuando Juan por fin recibe la respuesta de request timeout, Jorge ya lleva buen rato esperando a que su petición apenas comience, así que muy probablemente Jorge reciba un timeout pero a nivel de SIP, porque Asterisk se tardó mucho en responderle por estar ocupado en la petición de Juan.
  5. Si a este escenario le agregan más usuarios y más carriers, el sistema se hace más complejo exponencialmente, ocasionando una serie de retrasos que eventualmebte tiran todo el servidor porque nada responde (todos se quedan esperando a todos y ninguna llamada logra salir).

Esto es un problema a nivel de código de Asterisk: si las peticiones fueran asíncronas la espera de uno no se convertiría en la espera del otro y todos serían felices. Pero como se menciona en los foros de desarrollo de Asterisk, esta es una funcionalidad que requiere mucho tiempo para ser resuelta, y que al menos en la versión 1.8.21.0, persiste.

¿Cómo lo resolvemos?

Hay algunas soluciones:

  • Editar manualmente el /etc/hosts y poner allí todos los dominios y direcciones IP que necesitemos. El problema es que esto no funciona para resolución inversa de DNS, así que tiene fallos. Otro problema es que tendríamos que agregar manualmente cada dominio, lo cual puede consumir mucho tiempo, además de que si el proveedor actualiza su IP, nuestra resolución fallaría.
  • Configurar en Asterisk las IPs fijas de cada carrier. Fácil de hacer pero de igual manera, es manual, así que nos exponemos a los problemas de tener que estar vigilando nuestro PBX constantemente.

La solución que mas predomina es la de instalar localmente (en el mismo servidor de Asterisk) un servicio de cache de DNS, como es el caso de bind. Esto hará que el equipo almacede de manera local la información de consulta frecuente para que en caso de fallos con el internet, Asterisk sobreviva del cache. Y es bastante fácil de hacer.

En CentOS/RedHat lo hacemos fácil:

yum install bind bind-utils bind-libs caching-nameserver

En Debian/Ubuntu, también es sencillo:

apt-get install bind9

En CentOS/RedHat, por default el servicio no arranca automáticamente, así que debemos decirle a Linux que lo arranque cuando el sistema prenda.

chkconfig named on

También aprovechamos y lo arrancamos:

/etc/init.d/named start

Con esto el servicio de named ya está corriendo. Ahora le decimos a Linux que lo utilice. Editamos el archivo /etc/resolv.conf y nos aseguramos que solamente contenga una linea como la que sigue:

nameserver 127.0.0.1

Si usamos Elastix, hacer el cambio también desde la interfaz web. Abrimos el menu de System > Network y editamos la configuración para dejar únicamente un DNS:

DNS en Elastix

De esta manera, obligamos a que use el local. Si el local falla, lo peor que pasa es que perdemos nuestra troncal, pero es mejor recibir una respuesta negativa del DNS a no recibir respuesta.

Podemos validar que todo está corriendo revisando que el puerto 53 esté ocupado por el servicio de named:

[root@pbx ~]# netstat -anpl | grep 53
tcp        0      0 0.0.0.0:9090                0.0.0.0:*                   LISTEN      3953/java
tcp        0      0 127.0.0.1:53                0.0.0.0:*                   LISTEN      4745/named
tcp        0      0 127.0.0.1:953               0.0.0.0:*                   LISTEN      4745/named
udp        0      0 127.0.0.1:53                0.0.0.0:*                               4745/named

Y claro está, no puede faltar la super prueba del ping que muestre que los dominios resuelven correctamente:

[root@elastix ~]# ping asteriskmx.com
PING asteriskmx.com (216.93.172.112) 56(84) bytes of data.
64 bytes from 216.93.172.112.servepath.com (216.93.172.112): icmp_seq=1 ttl=53 time=74.6 ms
64 bytes from 216.93.172.112.servepath.com (216.93.172.112): icmp_seq=2 ttl=53 time=74.5 ms
64 bytes from 216.93.172.112.servepath.com (216.93.172.112): icmp_seq=3 ttl=53 time=74.9 ms

--- asteriskmx.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 74.563/74.723/74.912/0.265 ms

Hecho estos sencillos pasos, tu sistema estará preparado para caidas en el internet y tus troncales SIP no causarán que todo tu sistema se muera.

Solo una nota final: el servicio de named/bind al parecer vacia su cache cuando arranca. Esto quiere decir que si se va la luz y el internet al mismo tiempo, perderás la conectividad y todo se caerá (lo siento, no hay solución universal), pero en caso de que eso pase todo lo que necesitas hacer es detener el servicio y con esto tus DNS fallarán inmediatamente, con lo que te quedarás sin troncales SIP pero no si extensiones locales.

¡Suerte!

Versión mejorada del mensaje “all circuits are busy” de Elastix/FreePBX (v4)

8 Abr

Actualización 2016-01-13: La liga de los archivos de sonido ya está disponible nuevamente.

Hace casi 2 años escribí un artículo sobre como mejorar los mensajes de código de error en llamadas por E1 para Elastix. El tiempo ha pasado y han habido cambios tanto en Asterisk como en Elastix, ocasionando que algunas partes de ese viejo post ya no funcionen, por lo que decidí reescribirlo y mejorarlo.

Este código les permitirá dar mensajes más descriptivos para los códigos de error Q931 que los enlaces digitales arrojan al momento en que una llamada sale mal. Con respecto del post anterior, estas son las mejoras:

  • Existen más códigos de error documentados.
  • Las voces son sintetizadas con acento neutro (para todos los que nos leen en América Latina, esto es más cómodo que el acento español que se tenía antes)
  • Ya solo se requiere meter el código en un único archivo .conf, no es necesario usar el .ael.

Según la versión de Elastix que estemos ocupando, el código debe insertarse en uno de los 2 archivos siguientes:

  • /etc/asterisk/extensions_override_elastix.conf
  • /etc/asterisk/extensions_override_freepbx.conf

Preferentemente usar el extensions_override_elastix.conf, pero si no existe, usar el otro. Coloquen este código al final del archivo:

[macro-outisbusy]
exten => s,1,Progress
exten => s,n,Set(MSG=all-circuits-busy-now&pls-try-call-later) ; Clausula default
exten => s,n,Goto(s-${HANGUPCAUSE},1)
 
; Numero no existe
exten => s-1,1,Set(MSG=no-existe)
; No hay una ruta para llegar a este equipo. Tratar como no existe
exten => s-2,1,Set(MSG=no-existe)
; Celular fuera de area de servicio
exten => s-20,1,Set(MSG=celular-no-disponible&intente-mas-tarde)
; Numero mal marcado
exten => s-28,1,Set(MSG=cannot-complete-as-dialed&check-number-dial-again)
; Numero fuera de servicio
exten => s-27,1,Set(MSG=fuera-servicio&intente-mas-tarde)
; Red fuera de servicio
exten => s-38,1,Set(MSG=fuera-servicio&intente-mas-tarde)
; Falla temporal en la red
exten => s-41,1,Set(MSG=falla-red&intente-nuevamente)
; Congestion por alta cantidad de trafico
exten => s-42,1,Set(MSG=alto-trafico&intente-mas-tarde)
; La central telefonica no dio respuesta
exten => s-102,1,Set(MSG=falla-red&intente-nuevamente)
; Problema de interconexion de carriers
exten => s-127,1,Set(MSG=no-proveedor&intente-mas-tarde)
 
exten => _s-.,n,Playback(${MSG},noanswer) ; Reproducir el mensaje
exten => _s-.n,Macro(hangupcall)

Los nuevos archivos de sonido pueden descargarse desde la liga Sonidos mejorados para Elastix. Recuerden que hay que desempaquetar el .zip y el contenido subirlo a la carpeta /var/lib/asterisk/sounds para que puedan reproducirse sin problemas.

¡Suerte!

Recibe notificaciones push en tu móvil de llamadas hechas en Asterisk

13 Dic
pushover

Pushover está disponible para iOS y Android

Hace unos cuantos meses empecé a probar una aplicación para iOS/Android llamada Pushover que te permite crear notificaciones personalizadas de tipo push en tu móvil. El servicio es gratuito (solo debes comprar la aplicación que cuesta $4 USD) y te permite recibir hasta 7500 notificaciones al mes (suficientes creo yo). La aplicación es muy fácil de configurar: tras darte de alta solo debes registrar una aplicación (se te proporcionará un token al registrarla) y tomar nota de tu user key. Tras obtener esos datos, crea un script como el que sigue (puedes ponerlo en /sbin/push.php):

#!/usr/bin/php
<?php

// Reemplaza este valor por tu verdadero userKey de Pushover
$userKey = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";

/**************************************************
 Reemplaza este valor con el de tu propia aplicación.
 Si no lo cambias recibirás notificaciones de parte de "Asterisk México"
 (según la cantidad de usuarios que usen este token, pueden acabarse las notificaciones
 permitidas por Pushover al mes 
***************************************************/
$appToken="ptTjW6PlKHU7lB5jOdhLN7vHlKSIei";

curl_setopt_array($ch = curl_init(), array(
  CURLOPT_URL => "https://api.pushover.net/1/messages.json",
  CURLOPT_RETURNTRANSFER => true,
  CURLOPT_POSTFIELDS => array(
     "token" => $appToken,
     "user" => $userKey,
     "message" => $argv[1],
   )));
curl_exec($ch);
curl_close($ch);

?>

No te olvides de hacer el script ejecutable:

chmod 755 /sbin/push.php

Con esto el script ya debe de enviarte notificaciones a tu teléfono. Puedes enviarte un mensaje de prueba para validarlo. Teclea en el CLI de Linux:

/sbin/push.php "Este es un mensaje de prueba"

Si lo ejecutas, deberas recibir una notificación como la siguiente:

Ejemplo de notificación de Pushover

Ejemplo de notificación de Pushover

Ahora toca decirle a Asterisk que nos envíe notificaciones. Vamos a ver el código necesario para 2 escenarios: Asterisk puro y Asterisk bajo FreePBX (Elastix/Trixbox)

 

Para Asterisk Puro:

Lo que necesitamos insertar es insertar una llamada a la aplicación System que invoque nuestra aplicación con los valores que necesitamos. Por ejemplo, supongamos que tenemos esta línea en nuestro plan de llamadas para hacer una marcación internacional (archivo extensions.conf):

exten => _00ZXXXX.,1,Dial(DAHDI/g0/${EXTEN})

Lo que requerimos es mandar llamar a la notificación antes de que se genere el Dial, quedando algo así:

exten => _00ZXXXX.,1,System(/sbin/push.php "Llamada de ${CALLERID(num)} hacia ${EXTEN}")
exten => _00ZXXXX.,n,Dial(DAHDI/g0/${EXTEN})

Es importante que escapemos correctamente las comillas » «, de lo contrario solo nos llegará la primer palabra del mensaje.

Si tratamos de marcar al exterior, recibiremos una notificación como la que sigue:

Notificaciones de llamadas de Asterisk en Pushover

Notificaciones de llamadas de Asterisk en Pushover

Con esto ya quedan las notificaciones a nuestro sistema usando Asterisk puro.

Para FreePBX/Trixbox/Elastix:

Editamos el archivo de extensions_custom.conf y hacemos uso del hook que ya existe en FreePBX para no tener que modificar nuestro código:

[macro-dialout-trunk-predial-hook]
exten => s,1,System(/sbin/push.php "Llamada de ${CALLERID(num)} hacia ${OUTNUM}")

Ojo: esto enviará notificaciones por cada llamada que use troncales. Si quieren que solo se use para cierto tipo de llamadas, necesitan validar la variable ${OUTNUM} para que solo contenga los números que ustedes quieran.

 

¡Suerte!

Como bloquear extensiones al final del día (cerrar extensión cuando el trabajador se retira)

3 Dic

En ocasiones en nuestras oficinas (sobretodo en grandes corporativos), estamos sujetos a presupuestos de llamadas por mes. Esto quiere decir que recibimos una bolsa de minutos a ciertos destinos (para control de gastos) y debemos cuidarlos, ya que si nos los agotamos tendremos que hacer solicitudes de «crédito» interno y ante nuestros superiores parecería como que estamos desperdiciando dinero (llamadas) de la empresa.

Contemplando escenarios similares a este, podemos configurar Asterisk para que las extensiones de cada persona sean bloqueadas al momento en que la persona se retira a su casa. De esta manera, si alguien se queda cercano a su área de trabajo no podrá tomar su teléfono y hacer llamadas al exterior, reduciendo el crédito del trabajador que ya se fue (y ahorrándose el suyo). Al día siguiente, cuando el trabajador regresa, marca un código de desbloqueo junto con su contraseña y su teléfono vuelve a estar habilitado.

¿Cómo hacer eso?

Partiremos de los siguientes supuestos:

  • El contexto al que mis extensiones «normales» tienen derecho es el from-internal.
  • El código para bloquear la extensión (cuando el trabajador se va), será *51.
  • El código para desbloquear la extensión (cuando el trabajador regresa por la mañana), será *52.
  • Todas las extensiones deben tener un buzón asignado. El número de buzón debe ser el mismo que el de la extensión.
  • La marcación que negaremos será solamente la que corresponda a llamadas locales, larga distancia, celulares e internaciones (es decir, todas las que cuesten).
  • La sintaxis que estoy ocupando (same =>) es para Asterisk 1.6.2 o superior.

Toda la magia viene en el archivo extensions.conf (si usas Trixbox/Elastix/FreePBX, debes de hacerlo dentro del archivo extensions_custom.conf)

[from-internal-custom]
; Estos son los patrones para hacer las llamadas
; Si necesitas cerrar más patrones, agrégalos siguiendo el mismo formato
exten => _ZXXXXXXX,1,Macro(permitir)
same => n,Goto(from-internal-additional,${EXTEN},1)
exten => _04[45]ZXXXXXXXXX,1,Macro(permitir)
same => n,Goto(from-internal-additional,${EXTEN},1)
exten => _01ZXXXXXXXXX,1,Macro(permitir)
same => n,Goto(from-internal-additional,${EXTEN},1)
exten => _00ZXXXXXXXX.,1,Macro(permitir)
same => n,Goto(from-internal-additional,${EXTEN},1)

; Este es el código de bloqueo. Es lo que el trabajador marca antes de retirarse
exten => *51,1,Noop(Bloqueando ${CALLERID(num)})
;same => n,VMAuthenticate(${CALLERID(num)})     ; Descomenta esta línea si quieres pedir contraseña también al bloquear
same => n,Set(DB(bloqueo/${CALLERID(num)})=1)
same => n,Playback(vm-goodbye)
same => n,Hangup
; Este es el código de desbloqueo. Es lo que marca a la mañana siguiente
exten => *52,1,Answer
same => n,VMAuthenticate(${CALLERID(num)})
same => n,Noop(${DB_DELETE(bloqueo/${CALLERID(num)})})
same => n,Playback(auth-thankyou)
same => n,Hangup

; El macro-permitir es lo que valida si una extensión tiene o no activada el bloqueo
[macro-permitir]
exten => s,1,Noop(Revisando permisos de ${CALLERID(num)})
same => n,GotoIf($[${DB_EXISTS(bloqueo/${CALLERID(num)})}]?Bloquear:Permitir)
same => n(Bloquear),Noop(Deteniendo el paso de ${CALLERID(num)})
same => n,Playback(pbx-invalid)  ; Reemplazar por cualquier archivo de sonido deseado
same => n,Congestion()
same => n(Permitir),Noop(Permitiendo el paso de ${CALLERID(num)} --> ${MACRO_EXTEN})

Una breve explicación de lo que hace cada cosa:

  • Los patrones de ZXXXXXXX, 01ZXXXXXXXXX, 04[45]ZXXXXXXXXX y 00ZXXXXXX. son para controlar las llamadas locales, larga distancia nacional, celulares y LD internacional respectivamente. Si tienes más patrones de marcación o destinos que desees bloquear (por ejemplo, alguna marcación corta por telular), necesitas agregar el patrón correspondiente siguiendo el mismo formato (tras cada patrón debe haber una continuación same => n,Goto(from-internal-additional,${EXTEN},1) que te permite continuar con el contexto from-internal-additional.
  • *51 y *52 son, como habíamos comentado, los códigos para bloqueo/desbloqueo respectivamente. Puedes reemplazar los Playbacks por lo que tu elijas para dar diferentes mensajes
  • El [macro-permitir] es el que checa el contenido del Asterisk DB. Si la familia bloqueo/CALLERID existe, entonces no se le permiten las llamadas. Si no existe, el macro permite el paso y la llamada continúa de manera normal.
  • Las autenticaciones se hacen con la misma contraseña del buzón de voz, así cada quien tiene la suya, es actualizable por el usuario y solo funciona dentro de su mismo teléfono.
  • Si deseas desbloquear manualmente alguna extensión (ej. alguien olvidó su contraseña), solo debes ejecutar database del bloqueo <ext> dentro del *CLI.

Con esto lograremos que al cierre del turno, el trabajador pueda bloquear su teléfono y reactivarlo a la mañana siguiente con solo ingresar su contraseña.

Debo agregar que funciona tan bien que anoche que lo implementé dejé cerrada mi extensión y hoy no me permitía hacer llamadas, hasta que marqué *52 e introduje mi contraseña nuevamente.

¡Suerte!

Reparar todas las tablas de MySQL en un sistema Vicidial

28 Nov

El domingo pasado recibí el correo de un cliente: su sistema de marcación predictiva con vicidial había tenido fallas eléctricas durante el fin de semana, ocasionando que las tablas de MySQL se corrompieran y que el sistema quedara inservible (al menos lo relacionado con la marcación predictiva).

Tras cerca de una hora reparé todas las tablas usando unos comandos simples como los que siguen:

/etc/init.d/mysql stop
cd /var/lib/mysql/asterisk
myisamchk -r *.MYI
/etc/init.d/mysql start

Sin embargo, me percaté que al hacer esto, estaba solo reparando las tablas una por una. El sistema tenía 4 núcleos, por lo que era posible hacer mucho más trabajo al mismo tiempo (4 tareas a la vez) en vez de ir una por una.

El sistema terminó de manera habitual tras el paso de 1 1/2 hrs. Para evitar que tanto tiempo se perdiera en nuevas ocasiones, decidí crear un script en bash que reparara todas las tablas de manera simultánea (limitándose a 1 proceso por cada núcleo del sistema), y me quedó el código así:

#!/bin/bash

# Editar estos valores:
## CORES 		debe ser igual al número de núcleos en el sistema 
##				(revisar el comando "cat /proc/cpuinfo")
## MYSQLDBDIR	debe ser igual a la carpeta de MySQL que contiene la BD
##				que debamos reparar (default: "/var/lib/mysql/asterisk")

CORES=4
MYSQLDBDIR=/var/lib/mysql/asterisk

# Enlistar los archivos
FILES=`ls $MYSQLDBDIR/*.MYI`
RUNS=0
for i in $FILES
do
	SALIR=0
	while [ $SALIR -eq 0 ]
	do
		# Obtener la cantidad de procesos en el sistema
		PROCS=`ps -eF|grep myisamchk|egrep -v "grep"|wc -l`

		# Ejecutamos el while los procesos activos sean menor a CORES
		if [ $CORES -gt $PROCS ]
		then
			echo `date +"%X"` Revisando/Reparando tabla $i
			myisamchk -r $i &
			# Descansamos 1 segundo
			sleep 1
			SALIR=1
		else
			# Esperamos 3 segundos
			sleep 3
		fi
	done

done

# Ya se terminaron de correr todas las instrucciones de reparación,
# pero existe la posibilidad de que algunas de ellas aún estén ejecutándose.
# Revisamos para ver si hay procesos corriendo y avisar al usuario
while [ $SALIR -eq 0 ]
do
	# Obtener la cantidad de procesos en el sistema
	PROCS=`ps -eF|grep myisamchk|egrep -v "grep"|wc -l`
	if [ $PROCS -gt 0 ]
	then
		echo `date +"%X"` Hay $PROCS procesos corriendo. Esperando 10s...
		sleep 10
	else
		echo "No hay procesos corriendo"
		SALIR=1
	fi
done
echo `date +"%X"` Fin. Ya puedes reiniciar MySQL

Los siguientes pasos son algo obvios:

  1. Hay que guardar este script como un archivo checar.sh
  2. Editamos el archivo y cambiamos el número de cores de nuestro sistema, así como la ubicación de la carpeta de MySQL que contiene los archivos de la BD
  3. Darle permisos de ejecución (chmod 755 checar.sh)
  4. Ejecutarlo: ./checar.sh
El script correrá varios procesos en paralelo para revisar cada uno una tabla. Mientras más núcleos tenga nuestro procesador, más rápido el script aprovechará los recursos para crear la reparación.
Espero les sirva.
¡Suerte!

 

Advertencia: Aunque este script puede ayudarnos a reparar nuestras tablas en caso de algún problema (falla eléctrica, corrupción del sistema de archivos, fallo en el disco duro, etc) no hay nada más seguro que respaldar nuestra información periódicamente. Siempre ten a la mano copias de seguridad de aquella información crítica, ya que no podemos hacernos responsables por la pérdida de información causada por el mal uso de las directivas que se muestran en este artículo. Úsalo bajo tu propio riesgo.

La importancia de una línea de código: como hacer debug a tu configuración de Asterisk

20 Mar

El fin de semana por la noche recibí una llamada de un cliente nuestro solicitando apoyo para revisar el estado de su E1. Al parecer habían estado con el servicio de telefonía caido todo ese día, y tras horas de conferencia con su carrier no habían podido encontrar la razón por la cual el servicio del E1 no levantaba. Asterisk podía hacer llamadas entre extensiones, pero no tenían comunicación con el exterior.

Por experiencia, mi primer acercamiento fue revisar el archivo chan_dahdi.conf, que es el responsable del E1. Lo abrí pero no noté nada fuera de lo normal, así que desde la consola de Asterisk procedí a descargarlo de memoria y cargarlo nuevamente, esperando que arrojara algo de información. El resultado fue algo como lo siguiente:

server1*CLI> module load chan_dahdi.so
[Mar 20 02:03:52]   == Registered application 'DAHDISendKeypadFacility'
[Mar 20 02:03:52]   == Registered application 'ZapSendKeypadFacility'
[Mar 20 02:03:52]   == Parsing '/etc/asterisk/chan_dahdi.conf': [Mar 20 02:03:52] Found
[Mar 20 02:03:52] WARNING[9583]: config.c:778 process_text_line: parse error: No category context for line 6 of /etc/asterisk/chan_dahdi.conf
[Mar 20 02:03:52] ERROR[9583]: chan_dahdi.c:12728 setup_dahdi: Unable to load chan_dahdi.conf
[Mar 20 02:03:52]   == Registered channel type 'DAHDI' (DAHDI Telephony Driver w/PRI)
[Mar 20 02:03:52]   == Manager registered action DAHDITransfer
[Mar 20 02:03:52]   == Manager registered action ZapTransfer
[Mar 20 02:03:52]   == Manager registered action DAHDIHangup
[Mar 20 02:03:52]   == Manager registered action ZapHangup
[Mar 20 02:03:52]   == Manager registered action DAHDIDialOffHook
[Mar 20 02:03:52]   == Manager registered action ZapDialOffHook
[Mar 20 02:03:52]   == Manager registered action DAHDIDNDon
[Mar 20 02:03:52]   == Manager registered action ZapDNDon
[Mar 20 02:03:52]   == Manager registered action DAHDIDNDoff
[Mar 20 02:03:52]   == Manager registered action ZapDNDoff
[Mar 20 02:03:52]   == Manager registered action DAHDIShowChannels
[Mar 20 02:03:52]   == Manager registered action ZapShowChannels
[Mar 20 02:03:52]   == Manager registered action DAHDIRestart
[Mar 20 02:03:52]   == Manager registered action ZapRestart
[Mar 20 02:03:52]  Loaded chan_dahdi.so => (DAHDI Telephony w/PRI)

De aquí lo que importa es la línea que nos da el error:

[Mar 20 02:03:52] WARNING[9583]: config.c:778 process_text_line: parse error: No category context for line 6 of /etc/asterisk/chan_dahdi.conf

Tras abrir el archivo chan_dahdi.conf nuevamente y prestar un poco más de atención, las primeras líneas indican lo siguiente:

;autogenerated by /usr/sbin/wancfg_dahdi do not hand edit
;autogenrated on 2011-10-11
;Dahdi Channels Configurations
;For detailed Dahdi options, view /etc/asterisk/chan_dahdi.conf.bak

language=es

[trunkgroups]

[channels]
context=default
usecallerid=yes
hidecallerid=no
callwaiting=yes
usecallingpres=yes
callwaitingcallerid=yes

Y aquí es donde tras poner atención, notamos que el error proviene de una sola línea de código, el language=es está fuera de cualquier contexto, y esto provoca un error de parsing al momento de cargar el módulo, lo que impide que el canal se cargue correctamente y por lo tanto, el E1 nunca levante.

Entonces, ¿Cuales son los pasos para hacer un debug correcto de la configuración de Asterisk?

Los sistemas informáticos, a diferencia de los seres vivos, no cambian por si solos. Si nuestro sistema estaba bien de principio y de pronto algo dejó de funcionar es porque algo cambió. Una manera sencilla de ver los archivos de configuración en el orden en que fueron recientemente modificados es usar el comando ls:

ls -lSt /etc/asterisk | head -n 20

Con este comando ordenaremos los archivos de configuración de más reciente a menos reciente, mostrando solo los últimos 20 modificados. De ahí, podemos ir retrocediendo en nuestros pasos hasta que demos con la línea de código que alteramos y el sistema se restituya tras recargar el módulo o reiniciar Asterisk.

Si tenemos localizado el archivo con el problema, pero no sabemos exactamente en que línea está, el CLI de Asterisk puede resultar muy útil. Solo debemos asegurarnos que el log de eventos se arroja a consola editando el archivo /etc/asterisk/logger.conf

#/etc/asterisk/logger.conf
[general]

[logfiles]
console => warning,error,notice,debug
full => notice,warning,error,verbose

Como se aprecia en el archivo, estamos diciéndole a Asterisk que envie a consola toda la información relacionada con eventos warning, error, notice y debug (nota: el debug arroja MUCHA información, si hemos resuelto el problema lo recomendable es retirarlo del archivo hasta la siguiente vez que lo ocupemos). Recuerden que después de modificarlo deben recargar el logger dentro del Asterisk CLI

*CLI> logger reload

Y por último pueden descargar/cargar el módulo que da problemas en memoria. Este es un ejemplo del módulo de SIP:

amx*CLI> module unload chan_sip.so
Unloaded chan_sip.so
== Unregistered channel type 'SIP'
== Unregistered custom function SIPCHANINFO
== Unregistered custom function SIPPEER
== Unregistered custom function SIP_HEADER
== Unregistered custom function CHECKSIPDOMAIN
== Unregistered application 'SIPDtmfMode'
== Unregistered application 'SIPAddHeader'
== Unregistered application 'SIPRemoveHeader'
== Unregistered RTP glue 'SIP'
== Manager unregistered action SIPpeers
== Manager unregistered action SIPshowpeer
== Manager unregistered action SIPqualifypeer
== Manager unregistered action SIPshowregistry
== Manager unregistered action SIPnotify
amx*CLI> module load chan_sip.so
Loaded chan_sip.so
SIP channel loading...
== Parsing '/etc/asterisk/sip.conf': == Found
== Parsing '/etc/asterisk/sip_general_additional.conf': == Found
== Parsing '/etc/asterisk/sip_general_custom.conf': == Found
== Parsing '/etc/asterisk/sip_nat.conf': == Found
== Parsing '/etc/asterisk/sip_registrations_custom.conf': == Found
== Parsing '/etc/asterisk/sip_registrations.conf': == Found
== Parsing '/etc/asterisk/sip_custom.conf': == Found
== Parsing '/etc/asterisk/sip_additional.conf': == Found
== Parsing '/etc/asterisk/sip_custom_post.conf': == Found
== Parsing '/etc/asterisk/users.conf': == Found
[2012-03-20 01:48:54] WARNING[4896]: chan_sip.c:28479 reload_config: No valid transports available, falling back to 'udp
'.
== SIP Listening on 0.0.0.0:5060
== Using SIP TOS bits 96
== Using SIP CoS mark 4

En este otro ejemplo puede notarse como el módulo SIP arroja un WARNING. Eso es un típico caso de que algo en mi configuración no está 100% bien, por lo que conviene revisarlo.

Este paso de quitar/cargar el módulo en memoria resulta muy adecuado porque la información que arroja ese módulo no se pierde entre toda la demás al momento de hacer un reload. Fíjense en los detalles y pregúntense que quiso decir el CLI cuando les dió un warning o error. Los mensajes suelen ser bastante explícitos, solo depende de ustedes interpretarlos.

¡Suerte!

Como agregar contextos personalizados en todos los servidores de un cluster con Vicidial

13 Oct

Hoy me di a la tarea de implementar un plan de llamadas personalizado en un cluster de Vicidial: mi cliente no quería que existiera la posibilidad de que los agentes marcaran manualmente desde su X-Lite, y al tratarse de un entorno de múltiples servidores, a la larga resultaría complicado mantener por separado cada uno de los archivos extensions.conf de los servidores.

¿Cuál es entonces la mejor manera para crear contextos de plan de llamadas que aparezcan en TODOS los servidores instalados en un cluster de Vicidial sin tener el problema de replicar manualmente los cambios?

La respuesta viene con las últimas versiones de Vici (2.2+) ya que bajo Admin -> System settings viene un espacio interesante donde podemos agregar planes de llamadas personalizados: el Custom Dialplan Entry.

Custom Dialplan Entry para Vicidial

Sin embargo, hay un problema, y es que todo lo colocado en esta caja se escribe dentro del contexto [vicidial-auto], por lo que si decidimos ingresar contextos por separado, romperiamos la funcionalidad del plan de llamadas automático de Vici, pero el truco es más sencillo de lo que se cree. Solo tenemos que iniciar y terminar nuestro bloque con las siguientes líneas:

[codesyntax lang=»bash»]

include => vicidial-auto2

; Este es mi contexto personalizado
[agentes]
exten => _ZXXX,1,Dial(SIP/${EXTEN})
; Fin de mi contexto personalizado

[vicidial-auto2]

[/codesyntax]

¿Qué logramos hacer con esto? Hacemos que nuestro cluster genere todos los contextos personalizados que metamos en medio de nuestras lineas, pero además, no rompemos la funcionalidad de Vici porque la línea de include => vicidial-auto2 hace que la inclusión del contexto [vicidial-auto2] sea transparente, de manera que no rompemos ninguna de las funcionalidades del sistema, y evitamos tener que administrar una linea de comandos para que la exportación de la configuración sea más transparente.

Este truco me sacó de un problema que sé que a la larga, se habría perdido el control de la administración tarde o temprano.

¡Suerte!

Recuperar la contraseña de FreePBX

3 Oct

Muchos han pedido un tutorial de como recuperar la contraseña de FreePBX, lo cual es bastante sencillo una vez que tienes la contraseña de root de Linux. Asumiendo esto, el proceso a seguir es bastante fácil, solo hay que cambiar los passwords desde MySQL. Aquí pongo los comandos directos para hacerlo desde el CLI de Linux (estamos asumiendo que el password de root de MySQL es eLaStIx.2oo7)

Si tienes FreePBX 2.5 o inferior:

[codesyntax lang=»bash»]
echo «UPDATE asterisk.ampusers SET password=’minuevopass’ WHERE username = ‘admin'» | mysql -peLaStIx.2oo7 asterisk
[/codesyntax]

Si tienes FreePBX 2.6 o superior

[codesyntax lang=»bash»]

echo "UPDATE asterisk.ampusers SET password_sha1=SHA1('minuevopass') WHERE username = 'admin'" | mysql -peLaStIx.2oo7 asterisk

[/codesyntax]

Con FreePBX 2.6+ la contraseña se guarda como hash SHA1, por lo que no es posible recuperarla. Sin embargo, en versiones anteriores se guardaba en texto plano, por lo que un simple SELECT nos revelaria cual era la contraseña que teniamos.

OJO: obviamente es necesario cambiar «minuevopass» por lo que queramos que sea nuestra nueva contraseña

¡Suerte!

6 razones por las cuales tu campaña en Vicidial podría no funcionar

28 Sep

Como se ha visto, recientemente hemos tenido mucho movimiento sobre Vicidial, que es una suite open source para instalar un callcenter completo sobre Linux. Pues bien, es bastante común que dado lo complejo que resulta este sistema cometamos errores y que por lo tanto nuestras campañas de marcación predictiva no saquen llamadas al exterior. Aquí recopilo algunos de los errores más comunes al momento de hacer marcación predictiva hacia el exterior:

  • Las campañas tienen el horario incorrecto. Muchas veces, las pruebas las hacemos en las noches y movemos la hora de las llamadas para entender por que no salen. Primer paso: asegurémonos de que la hora de la campaña sea la correcta y que estemos haciendo pruebas dentro del horario REAL en que se supone que nuestras campañas deben de correr.
  • No hay leads disponibles para marcar. Asegurémonos que las listas que tenemos dadas de alta para nuestra campaña tengan leads con los status de marcación válidos. Normalmente, marcamos a los NEW (nuevos leads), NA (No Answer) y B (Busy). Si nuestra lista está llena de leads que no tienen estos status, no se marcará hacia ellos. Agreguemos los nuevos status que queramos dentro de la campaña para ser válidos de remarcarles o bien, importemos nuevos leads para reintentar la operación.
  • No hay leads en el hopper. Si mandamos llamadas demasiado rápido o tenemos muchos agentes, lo más probable es que nos agotemos el hopper realmente rápido. Lo ideal es que nuestro hopper level (a nivel de campaña) esté ubicado en al menos 2.5 veces el número de agentes que podemos tener en línea en un momento dado. Este error es fácil de encontrar ya que nos aparecen indicaciones al hacer login como agente, asi que no debería ser problema localizar de que se trata.
  • Las llamadas no están saliendo a pesar de tener agentes en línea. Esto me pasó recientemente: todos los problemas de arriba habían sido verificados, pero había 5 agentes en línea y ninguno recibía llamadas. El problema fue de que tenía yo creada una campaña de marcación automática con agentes remotos (para enviar mensajes pre-grabados) y esto ocasionó que nos termináramos la cantidad de troncales disponibles para marcar al exterior (aunque nunca se usaron). Moraleja: asegúrate que bajo System Settings, el valor de Max Vicidial Trunks sea más grande que la cantidad total de agentes que tengas en un momento dado, y en caso de que así sea, asegúrate de no tener agentes remotos activos que tengan múltiples lineas de salida activadas. Al parecer, Vicidial reserva lineas aún para los agentes remotos que no las están usando.
  • Las llamadas no enlazan: dan un timeout y la interfaz de agente se queda esperando en estado «ringing». Comúnmente es ocasionado por enlaces digitales que NO son ISDN, como R2 modificado. Algunos proveedores dan mensajes grabados en early media audio dando grabaciones como «el número que marcó no existe». Normalmente, una persona escucharía esto y sabría que hacer, pero un sistema piensa que la llamada nunca se contestó y por lo tanto, ocurre un timeout porque 1) nunca obtuvimos ring y 2) nunca nos contestaron. La única solución es cambiar de enlace o cambiar a marcación manual, de manera que nuestros agentes puedan catalogar por ellos mismos el estado de las llamadas.
  • Las llamadas se cortan a los pocos segundos y nunca se enlazan a los agentes. Descubrí que si en la marcación automática haces un ANSWER antes de enviar un DIAL (es decir, sin un ringing de por medio), Vicidial nunca te enlaza las llamadas y te las marca como NA (No Answer). Lo correcto es que siempre debe haber un ringing antes de que la llamada sea contestada. Con eso evitarás que se marque pero nunca comunique a los agentes.

Como siempre, habrá muchas otras cosas que puedan pasar, pero en este caso estas son las más comunes. Conforme nuestra experiencia vaya aumentando, iremos ampliando la lista.

¡Suerte!

Como reiniciar masivamente todos los dispositivos Cisco SPA de tu red

27 Sep

El día de ayer publicamos un mini tutorial de como reiniciar masivamente todos los teléfonos Aastra de nuestra red. Hoy publicamos el equivalente aplicable para todos los teléfonos Cisco SPA (esto aplica también para la vieja gama de Linksys/Sipura).

El código es aún más sencillo que el de ayer:

[codesyntax lang=»php»]

#!/bin/bash
RED=192.168.1.1/24
echo "Escaneando $RED ..... "
for IP in `nmap -sP -v $RED | grep "appears to be up" | cut -d' ' -f 2`
do
   wget -qT 1 --no-cache http://$IP/admin/reboot -O - > /dev/null
done

[/codesyntax]

Con un poco de ingenio, podemos mezclar ambos scripts para que en caso de tener mezcla de teléfonos, reiniciemos todo lo que nos encontremos.

¡Suerte!