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!

Como reiniciar masivamente los teléfonos Aastra de tu red

26 Sep

Recientemente nos topamos con la necesidad de resetear cerca de 200 teléfonos Aastra en una misma red. Pudimos haber esperado a que los teléfonos comenzaran a registrarse solos, pero debido a que era un soporte de emergencia, utilizamos este script:

[codesyntax lang=»bash»]

#!/bin/bash
USER=admin
PASS=22222
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-user=$USER --http-passwd=$PASS http://$IP/logout.html -O - > /dev/null
   wget -qT 1 --no-cache --http-user=$USER --http-passwd=$PASS http://$IP/sysinfo.html -O - > /dev/null

   # Reset
   echo Reiniciando $IP
   wget -qT 1 --no-cache --post-data=resetOption=0 --http-user=$USER --http-passwd=$PASS http://$IP/reset.html -O - >/dev/null
done

[/codesyntax]

Lo que éste hace es escanear la red, abrir la interfaz web de todos los teléfonos, accesa con el usuario y contraseña default (admin/2222) y una vez adentro ingresa al menú Reset y posteriormente acciona el reseteo del teléfono. Para hacer uso de este script es necesario hacerlo ejecutable (chmod 755) y cambiar la variable de RED para que concida con la red que queremos resetear.

¡Suerte!

 

Terminado el curso de Vicidial

12 Sep

Durante los últimos 4 días estuve en Tampa, FL tomando un curso acerca de Vicidial, una suite open source con marcador predictivo para call centers basados en Asterisk. El curso fue impartido por Matt Florell, el creador del software, y durante las horas que estuvimos en el salón de clases pude aprender y corroborar muchos detalles interesantes sobre este sistema que aunque lleva varios años en el mercado, pocos se han dado a la tarea de conocerlo.

El curso se divide en 2 partes: el Manager y el Admin. Durante el curso de Manager se da una explicación a detalle de como utilizar la interfaz web de Vicidial: como se crean campañas de entrada y salida, como se cargan registros, como se configuran carriers para enviar las llamadas, como podemos controlar la distribución de llamadas entre los agentes, etc. Todas y cada una de las opciones de las más de 200+ que hay para alterar en la suite fueron vistas y explicadas. A pesar de que en la interfaz web es posible leer la documentación HTML que viene con el software, muchas veces las cosas no se comprenden tan bien como cuando puedes debatirlas, y este fue uno de los casos. Inclusive las explicaciones ayudaron a visualizar escenarios que no habiamos contemplado, pero que pueden resultar muy útiles para cualquier callcenter.

En la segunda parte del curso se vieron detalles mucho más técnicos: como instalar el sistema, como hacer troubleshooting, cuales son las causas comunes de que un sistema de estos falle (el famoso time synchronization error o el there are no available sessions), así como muchas otras características avanzadas que el mortal promedio no ocupa, como el uso de los APIs, la captura extendida de números telefónicos, etc. Al final terminamos con una instalación de Vicidial en cluster (lo que ofrece máxima escalabilidad al sistema) y corrimos pruebas de rendimiento para comprobar que todo estuviera bien y supiéramos hasta donde podemos llegar con él. En general, un curso muy teórico y con mucha información. Debo reconocer que mis favoritos fueron los últimos dos días, pues fue cuando realmente tuve oportunidad de jugar con el sistema.

Vicidial hoy en día es un producto que deja muy por atrás a toda la competencia, tanto en funcionalidades como en precio. Aquellos que han probado el módulo de callcenter de Elastix puedo decirles fácilmente que no tiene nada que ver con Vicidial: Elastix fue pensado como un PBX para empresa, no como medios para un callcenter, y Vici está muy por encima en funcionalidades. ¿Acaso el precio podría hacer la diferencia? No, porque es el mismo que con el resto del open source: ¡gratis!, así que tampoco es necesaria una inversión millonaria en sistemas como Avaya o Cisco que a pesar de ser propietarias, se quedan cortos en características.

En mi opinión personal, el único problema que le veo a un software como Vici es precisamente su mayor fortaleza: el grado de complejidad que tiene lo hace para alguien sin conocimientos resulte una tarea muy complicada el tratar de echar a andar una campaña con él. Sin embargo, una vez que se libra esa curva de aprendizaje, los que ahora lo conocemos sabemos que es bastante sencillo de ocupar, y que pueden hacerse cosas geniales con él. Repetiré lo que les digo a mis alumnos del curso de Asterisk: el límite de lo que puedes hacer, es la capacidad del administrador.

Para más información sobre este software, visiten vicidial.org. Si requierieras apoyo profesional para una implementación de Vicidial para un callcenter, por favor utiliza nuestro formulario de contacto.

¡Suerte!

Nueva fecha de Cursos Asterisk para octubre

9 Sep

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:

  • México, D.F. del 5 al 8 de octubre.
  • México, D.F. del 26 al 29 de octubre.

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!

Como eliminar el eco en llamadas: instalando OSLEC y usando fxotune

7 Sep

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:

  1. Hardware: es la más cara de las opciones, ya que nos exige comprar hardware dedicado a esta función. Sin embargo, es la de mejor rendimiento ya que libera al CPU de esta carga extra.
  2. Software: justo lo contrario, es la opción más económica, pero depende del CPU para hacer el procesamiento.

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:

  1. Detenemos Asterisk para que los canales DAHDI no estén en uso
  2. Creamos el archivo /etc/fxotune.conf (se crea automáticamente usando el comando fxotune -i)
  3. Cargamos los coeficientes encontrados cada vez que arranque el sistema
  4. Reiniciamos Asterisk

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!