1

Abstract—En este artículo se propone el desarrollo de una

aplicación que permite escalar la plataforma de Voz sobre IP Asterisk para Call Center denominada astrouter. Se propone una arquitectura general del Call Center en 4 capas funcionales. La aplicación se probó en un ambiente controlado en el cual se generaron llamadas aleatoriamente y se simularon los agentes del Call Center. Se capturaron los datos generados por los ACD utilizando los algoritmos rrmemory y med . Index Terms— Asterisk, Call Center , ACD, VoIP , Software

Libre.

I. INTRODUCCION

sterisk es hoy en día el proyecto Open Source más representativo de una completa PBX y herramienta

desarrollo, programada en lenguaje C y que funciona sobre ambientes Linux, FreeBSD, y Mac OS X. Además de poder ser utilizada como PBX o Gateway, también ha sido adoptado como plataforma para Call Center.

Según la revista Linux Magazine[3], del listado de las compañías de software de la comunidad Open Source con mayor impacto en el mercado para el año 2008, en el octavo lugar después de empresas como 3tera, Amazon y Alfresco se encuentra Digium [11], principal patrocinador y desarrollador del proyecto Asterisk. Se esperan más de 35 millones de líneas VoIP representadas por pequeños y medianos negocios en los próximos 3 años [3].

II. EL PROYECTO ASTERISK

El bajo costo de implementación y mantenimiento de la

plataforma Asterisk en comparación con las soluciones tradicionales para Call Center la hacen una solución muy atractiva para pequeñas y medianas empresas. Adicionalmente al ser un proyecto de código fuente abierto, permite facilidades en su configuración, modificación e integración con otras plataformas y/o aplicaciones. Lamentablemente la escalabilidad de Asterisk es un tema que se esta discutiendo

Oscar Andrés Rocha Reina: oarochar@unal.edu.co, estudiante de Maestría

en Ingeniería - Ingeniería Telecomunicaciones, Universidad Nacional de Colombia.

Zoila Ramos Rodríguez: ziramosd@unal.edu.co, Profesor, Departamento de Ingeniería de Sistemas e Industrial, Universidad Nacional de Colombia

actualmente. Como lo afirma Anthony Minessale creador del proyecto Freeswitch y exdesarrollador del proyecto, “Asterisk fue originalmente diseñado con una arquitectura monolítica lo que significa que el procesamiento, la interfaz de usuario y todos los datos residen en una sola entidad (el proceso principal de Asterisk)[1] ”.

La arquitectura de Asterisk puede resumirse en un núcleo

principal compuesto por un modulo de switching, que se encarga de la conexión entre los diferentes canales, y un manejador de procesos de entrada y salida (Lectura, Escritura).

Alrededor del núcleo se han desarrollado APIs para

aplicaciones nativas de Asterisk como Voicemail(), Meetme() Queue() etc, adicionalmente un API para el manejo de formatos de archivos como mp3, gsm y wav usados en la grabación digital de llamadas, reproducción de archivos de audio y música en espera. También implementa los protocolos mas usados para voz sobre IP como SIP, IAX2[15], H323 y otros como Dahdi[16] y Agent para otro tipo de canales. El último API implementa toda la funcionalidad para el proceso de transcodificacion. Asterisk soporta la mayoría de los codecs alaw, ulaw, gsm, speex, ilbc y G729 [13].

Posiblemente una de las funcionalidades más interesantes en mi concepto es la capacidad de invocar aplicaciones externas al proceso de Asterisk por medio de eventos telefónicos e intercambiar datos entre los dos procesos. Esta interfaz se denomina AGI (Asterisk Gateway Interface) y su variante FASTAGI que corre el proceso externo en otro maquina diferente a Asterisk. También tiene desarrollada una interfaz que permite la recepción de comandos desde cualquier programa externo que maneje sockets, con el motivo de controlar o generar acciones desde un cliente externo no telefónico. Esta interfaz se denomina AMI [14] (Asterisk Manager Interface). El AMI maneja un protocolo basado en mensajes de texto del tipo Action - Response y eventos generados del tipo Event. Esta interfaz se utiliza para la creación de aplicaciones que interactúan de forma dinámica con Asterisk. La mayoría de interfaces de usuario, aplicaciones de conferencias web y marcadores utilizan el AMI.

DISEÑO E IMPLEMENTACIÓN DE UNA APLICACIÓN PARA LA DISTRIBUCIÓN DE LAS LLAMADAS EN MÚLTIPLES SERVIDORES ASTERISK MANEJANDO EL

ACD PARA CALL CENTER BAJO LINUX

Ing. Oscar Andrés Rocha Reina Msc ( c ), Ing Zoila Ramos Rodríguez Ph.D ( c )

A

2

Fig 1. Esquematización del diseño de Asterisk

III. ASTERISK PARA CALL CENTER

Para pequeñas y medianas empresas Asterisk representa una solución muy atractiva como PBX y plataforma para Call Center. Para este ultimo caso, Asterisk tiene desarrollado nativamente un ACD el cual implementa una serie de algoritmos de distribución de llamadas como los son random, ringall, roundrobin y rrmemory entre otros [17]. Estos algoritmos permiten distribuir la llamadas entrantes recibidas por la plataforma entre los agentes disponibles invocando a la aplicación Queue(). Esta aplicación se encarga básicamente de aplicar el algoritmo seleccionado para cada una de las colas, dado un número un llamadas entrantes, y un número de agentes disponibles y no disponibles ese instante. Cada uno de los agentes debe realizar con anterioridad un proceso de Login ante el sistema invocando la aplicación AgentLogin(). Para cada evento telefónico que sucede en la cola (login de un agente, ingreso a la cola de una llamada, cuelgue de una llamada), se genera un evento que es escrito en el socket del AMI el cual esta disponible mediante la conexión tipo socket TCP-IP hacia Asterisk.

El ACD esta diseñado para operar en una sola maquina, por ende el estados de los agentes y las colas no es distribuido. De la misma manera la comunicación entre varias maquinas Asterisk es estática y se define en el plan de marcación. Esto dificulta la escalabilidad de la plataforma para Call Center.

Como alternativa, es posible desarrollar una aplicación que permita distribuir las llamadas sobre diferentes servidores Asterisk desde un punto centralizado que conozca el estado de todos los nodos y permita escalar la solución al manejar varios servidores Asterisk al mismo tiempo. La conexión entre la aplicación y los servidores Asterisk se realizaría mediante el AMI permitiendo recibir información sobre los eventos de las maquinas en tiempo real y las posibilidad de enviar comandos.

Se han reportado problemas con múltiples conexiones al Manager de Asterisk que envían una cantidad considerable de comandos y anormalidades en el funcionamiento del software

(deadlocks) cuando las terminales conectadas sufren algún tipo de anomalía [2]. Versiones recientes de Asterisk han solucionado este tipo de problemas pero el volumen de salida de los eventos del AMI ha crecido considerablemente [4].

IV. DESARROLLO PROPUESTO - ASTORUTER

El propósito de la aplicación es permitir escalar la solución

de Asterisk para Call Center, al manejar simultáneamente varias maquinas aumentando en conjunto el numero de agentes en el sistema y la utilización de algoritmos de distribución de llamadas que tengan en cuenta variables propias del ACD. La aplicación la denominare astrouter.

Inicialmente la arquitectura de la solución en general se muestra en la figura 2. Esta debe considerar una separación lógica en capas, de todo el sistema, distribuyendo en cada una de ellas tareas específicas complementarias.

Fig 2. Arquitectura en capas funcionales.

En la mayoría de los casos las llamadas provienen de la

RPBC, por lo tanto debe existir un(os) equipo(s) que realicen el proceso de conmutación de RPBC a VoIP1. Estos equipos son servidores Asterisk con hardware especializado de bajo costo para manejar líneas digitales (enlaces T1, E1, PRI) o líneas análogas. Las primeras tarjetas para Asterisk eran bastante básicas y todo el procesamiento del DSP lo realizaba Asterisk, requiriendo altos tiempos de disponibilidad del procesador. Actualmente el nuevo hardware por ejemplo de la empresa Sangoma [12] tiene un DSP incorporado en sus tarjetas. También en esta capa se debe realizar el proceso de transcodificación si lo hay.

La siguiente capa debe ser la capa de enrutamiento en donde estaría ubicada la aplicación astrouter encargada de distribuir las llamadas de una forma más eficiente.

1 Todo el manejo de las llamadas del ACD nativo de Asterisk son realizadas con Voz sobre IP.

3

En la tercera capa se encontrarían las aplicaciones o funcionalidades. Para el Call Center el ACD nativo de Asterisk, monitoreo en línea de los agentes, grabación digital de las llamadas y demás servicios de Asterisk puede suministrar.

La cuarta capa debe ser la capa de datos y almacenamiento donde se guardarían tanto los registros telefónicos como las grabaciones digitales2.

El astrouter seria un ACD enrutador de llamadas primario que pasaría las llamadas a los ACD locales de cada maquina implementando diferentes algoritmos, reutilizando las mismas colas locales de cada servidor Asterisk, dando así el manejo terminal de la llamada a cada una de estos. El uso de las colas locales permitiría un registro detallado de los eventos y el manejo de Agentes (Login y Logout). La redirección de las llamadas desde los servidores de conmutación hasta los servidores de agentes se realizaría mediante troncales IAX2 o SIP entre los diferentes servidores.

Dentro de la literatura actual la aplicación propuesta se asemeja ha los denominados Call Center Virtuales (VCC). Algunos autores como en [7] definen que un Call Center virtual es creado mediante la interconexión de múltiples ACD a través de una red de conmutación de circuitos o de paquetes. Adicionalmente estos VCC pueden implementarse netamente en redes de conmutación de circuitos o de paquetes o en una arquitectura hibrida combinando ambas tipos de redes. Algunas arquitecturas a nivel general de los VCC sugeridos por [32] se muestran el la figura 3, estas son:

• ACD en Red (Network ACD). • Balanceo de Carga (Load Balancing). • Por Desborde (OverFlow).

La arquitectura de ACD en Red (Network ACD) representa

un sistema que es capaz de mantener todas las llamadas en una cola central antes de enrutar las llamadas hacia los diferentes Call Center para ser atendidas. El enrutamiento solo se realiza cuando hay agentes disponibles en uno de los Call Center [7].

La arquitectura de balanceo de carga (Load Balancing)

enruta las llamadas desde un switch central hacia los ACD tradicionales donde las llamadas son encoladas localmente [7]. Finalmente la arquitectura por desborde (OverFlow) permite solamente el encolamiento local de las llamadas en un Call Center primario, el cual es capaz de desbordar las llamadas hacia otro Call Center [7]. Las arquitecturas se muestran en la figura 2.

La aplicación que se desarrollo se asemeja a una

arquitectura de balanceo de carga, pero a diferencia de esta no maneja un solo switch central, sino un conjunto de switches

2 Para efectos de rendimiento es recomendable realizar el proceso de

grabación de llamadas en dispositivos como un RAMDRIVE, permitiendo almacenar las grabaciones temporalmente en memoria RAM, eliminando el posible cuello de botella en los procesos de entrada y salida. Una vez terminada la llamada, esta es almacenada en un sistema de archivos compartido como NFS y transferida a la capa de datos [8].

que se encontrarían en la capa 1 del modelo propuesto.

Fig 3. Arquitecturas de un Call Center Virtual

La aplicación como tal realiza una única conexión

persistente al AMI de cada uno de los servidores. Esta orientada al manejo de eventos y es multihilo.

Se escogió como lenguaje de programación C++ sobre

Linux y la programación orientada por objetos. Se utilizo la clase CThread, desarrollada por Walter E. Capers [5] para el manejo de los hilos y la clase ClientSocket desarrollada por Rob Tougher's [6] para el manejo de sockets.

Los algoritmos implementados en el astrouter fueron:

• Minium Expected Delay (MED) [10]. • Round Robin Memory (RRMEMORY) [7]. • Join the Shortest Queue (JSQ) [7].

V. PRUEBAS DE LA APLICACIÓN

Con el fin de probar el software desarrollado se configuro un ambiente de pruebas que refleja la una operación de Call Center que consta de 90 agentes con un máximo de 120 llamadas activas en todo el sistema. Este se muestra en la figura 4.

Teniendo en cuenta las observaciones realizadas para la simulación de Call Center en [7], [8] y basados más específicamente en el modelo presentado en [8], se desarrollo un pequeño programa en C++ para la generación aleatoria de llamadas.

Esta aplicación considera P periodos, en cada uno de los

cuales se atienden K tipos de llamadas. Se tienen en cuenta las siguientes reglas:

4

Fig 4. Esquema en capas del astrouter propuesto.

• El número de llamadas, se genera siguiendo una

distribución de Poisson, con media λ, para cada periodo P.

• Los tiempos de duración de cada llamada, se generan siguiendo una distribución exponencial con media 1/µp para cada periodo P.

• Los tiempos en cola de cada llamada, se generan siguiendo una distribución exponencial con media 1/υp para cada periodo P.

Con un estimado 1000 llamadas por hora es posible calcular

el valor de λ:

28.03600

1000, ====

t

ptp λλ (1)

Para cada periodo P debe calcularse un valor de λ diferente. Para el cálculo de la duración de las llamadas y el tiempo en espera, la media de la distribución exponencial se calcula de la siguiente manera:

λ

1=m (2)

Si la duración promedio de la llamada es de 5 minutos la media es igual a:

2.05

1==m (3)

Con esta media se generan los números aleatorios siguiendo la distribución exponencial para cada período P. Estos valores se multiplican por 60 y se redondean a cero decimales para obtener los segundos completos. El mismo procedimiento se realiza para los tiempos en cola de cada llamada. Para las pruebas no se tuvo en cuenta caída de nodos en el sistema tanto de servidores de conmutación como servidores de agentes. Adicionalmente se realizaron pruebas en ambientes homogéneos y heterogéneos. Se utilizo la clase RNG (Random Number Generation) [6] para la generación de números aleatorios dada una distribución de probabilidad.

Cada servidor de conmutación para generar una llamada crea un archivo de texto con extensión .call que es procesado por Asterisk. La estructura del archivo se muestra a continuación:

Channel:Local/346@default

Callerid: 3165000

MaxRetries: 0

RetryTime: 0

WaitTime:0

Context: cliente

Extension: s

Priority:1

Set: TiempoCola=13

Set: TiempoHablado=1339

En este archivo además de las variables telefónicas se define

el tiempo en cola y el tiempo de conversación de cada llamada. Una vez la llamada es generada, dentro del plan de marcación Asterisk se definen las variables TiempoCola y TiempoHablado y se genera un evento de usuario denominado LlamadaEntrante. Este evento es capturado y procesado por el astrouter. Estas instrucciones se definen en el plan de marcación de cada servidor de conmutación.

; Servidor de Conmutacion (1)

exten => 346,1,Answer()

exten => 346,n,Set(TiempoCola=${CUT(TiempoCola,,1)})

exten=> 346,n,Set(TiempoHablado=${CUT(TiempoHablado,,1)})

exten=>346,n,UserEvent(LlamadaEntrante|DID:${EXTEN}|

Channel: ${CHANNEL})

exten =>346,n,Wait(1)

exten =>346,n,MusicOnHold()

Una vez el astrouter decide a que servidor de agentes enviar la llamada, se genera un evento de redirección de canal al servidor de conmutación a la extensión apropiada, por ejemplo la extensión 001 es la forma de comunicarse con el servidor de agentes numero 1.

; Para el servidor de Agentes (1)

exten => 001,1,Set(CALLERID(name)=${TiempoCola})

exten => 001,n,Set(CALLERID(number)=${TiempoHablado})

exten => 001,n,Dial(IAX2/t_acd1/003)

exten => 001,n,Hangup

De esta manera a través de las variables Callerid Name y

Number se pasan los tiempos de duración de las llamadas de un servidor Asterisk a otro. Se utiliza un troncal IAX2 para establecer la llamada y se genera utilizando la aplicación Dial.

Una vez la llamada es recibida por el servidor de agentes, se ejecutan las siguientes instrucciones en el plan de marcación:

exten => 003,1,Answer

exten => 003,n,Set(TiempoCola=${CALLERID(name)})

exten => 003,n,Set(TiempoHablado=${CALLERID(number)})

exten => 003,n,UserEvent(Join|Queue: TESTQ)

exten => 003,n,Set(TIMEOUT(absolute)=${TiempoCola})

exten => 003,n,Queue(TESTQ||||360|CuelgaLlamada.agi|

${TiempoHablado})

exten => 003,n,Hangup

Además de capturar los tiempos de la llamada, se genera un

evento denominado Join que indica que una llamada va a ingresar al ACD. Al invocar la aplicación Queue(), se pasan como parámetros el tiempo hablado y un pequeño AGI para el tiempo en cola. De esta manera se reproduce una operación de

5

Call Center. Los agentes se configuran como canales locales en el archivo agents.conf en los servidores de conmutación. Se reproduce audio al contestar la llamada con el fin de generar trafico RTP. Toda la actividad se registra en el CDR [19] de los servidores de conmutación y en el Queuelog[18] de los servidores de agentes.

VI. RESULTADOS

Las pruebas se realizaron en ambientes homogéneos y

heterogéneos con los algoritmos MED y RRMemory. Como resultado general MED presento mejores resultados en ambos ambientes presentando mejores indicadores en las diferentes métricas tenidas en cuenta.

La métrica mas utilizada para medir el servicio en general

en un Call Center es el nivel de servicio (GoS). Este indicador se calcula sobre un porcentaje del total de las llamadas entrantes que debe contestarse antes de un umbral de tiempo medido en segundos. Es muy común utilizar el indicador en 80/20, lo que significa que se deben contestar como mínimo un 80% de las llamadas entrantes en menos de 20 segundos. Con este indicar se calcularon los niveles de servicio para cada uno de los servidores usando los dos algoritmos. El resultado se muestra en la figura 5.

58

60

62

64

66

68

70

72

74

Porcentaje

1 2 3

Servidores

Nivel de Servicio 80/20 (GoS)

MED

RRMemory

Fig 5. Nivel de Servicio (homogéneo)

0

5

10

15

20

25

30

35

40

Numero Llamadas

1 2 3

Servidores

Numero de Llamadas Abandonadas

MED

RRMemory

Fig 6. Llamadas Abandonadas (homogéneo)

En la figura 6 se muestra un comparativo de las llamadas abandonadas por cada algoritmo. Se observa claramente una disminución de las llamadas abandonadas en el algoritmo

MED, indicando una mejor distribución de las llamadas sobre los servidores de agentes

VII. CONCLUSIONES

El diseño de Asterisk esta basado en módulos que

interactúan con un núcleo central. Los problemas de utilizar listas encadenas en aplicaciones multihilos es un tema que ya esta siendo replanteado por los desarrolladores y esta actualmente en desarrollo.

La posibilidad de integración de Asterisk con aplicaciones

externas facilita la integración con otro tipo de plataformas. El uso de las interfaces AGI y AMI permite la integración con cualquier tipo de aplicación que utilice sockets en la totalidad de lenguajes de programación de alto nivel.

Se encontró una falencia en la no existencia de un software

que permitiera la distribución de las llamadas sobre varios ACD de diferentes Asterisk aplicando un algoritmo en particular. Basado en los modelos de Call Center Virtuales mas específicamente el de Network ACD se diseño e implemento una aplicación que permite la distribución de las llamadas sobre diferentes máquinas Asterisk haciendo uso del Asterisk Manager Interface (AMI). Para su evaluación se configuro un ambiente de pruebas que simula la operación de un Call Center con 2 servidores de conmutación, 3 servidores de Agentes y uno para el aplicativo desarrollado.

Se probó la aplicación con una carga máxima de 120

llamadas simultáneas mostrando el funcionamiento de la aplicación aplicando dos algoritmos RRMemory y MED en ambientes homogéneos y heterogéneos. Se mostraron los resultados de las pruebas y de forma indirecta se compararon los algoritmos MED y RRMemory donde MED presenta mejores resultados a nivel general que ambos ambientes [7].

El núcleo de la aplicación desarrollada básicamente permite

leer cualquier evento generado por el AMI de las maquinas a las cuales se conecte con el fin de tomar una decisión en particular. Bajo esta premisa es posible adicionar a la aplicación desarrollada más funcionalidades por ejemplo de un marcador y un servidor de CTI3. Como la aplicación conoce el estado del ACD de cada uno de los servidores, en los momentos de bajo tráfico estaría en la capacidad de generar llamadas de salida, que se distribuirían de la misma manera como llamadas de entrada, haciendo un mejor uso de los recursos. El servidor CTI seria la implementación de una clase que permitiera enviar a los agentes los datos relacionados con la llamada como el número telefónico u otro dato en especial para su posterior integración con otros sistemas tipo CRM4.

Las posibilidades de desarrollo e integración con sistemas

propios del negocio hacen de la plataforma Asterisk una

3 La sigla CTI hace referencia a Computer Telephony Integration. 4 La sigla CRM hace referencia a Customer Relation Management.

6

alternativa muy atractiva para los desarrolladores y empresas que prestan sus servicios a terceros utilizando este tipo de tecnología plataforma.

REFERENCIAS

[1] An Interview with the Creator of FreeSWITCH, Bruce Stewart,

Disponible en , http://www.oreillynet.com/pub/a/etel/2006/07/25/an-interview-with-the-creator-of-freeswitch.html

[2] Asterisk manager experience, Matt Florel, Disponible en : http://www.voip-info.org/wiki/view/Asterisk+manager+experience,

[3] Linux Magazine’s Top 20 Companies to Watch in 2008, http://www.linux-mag.com/id/4766/8/

[4] Asterisk Manager Events , disponible en http://www.voip-info.org/ wiki/view/asterisk+manager+events.

[5] Walter Capers, Creating a C++ Thread Class, disponible en http://www.code project.com/ KB/threads/threadobject.aspx.

[6] A C++ Random Number Generator Class, Disponible en http://oldmill. uchicago. edu/~wilder/ Code/ random/

[7] A. Adetunji, A. Shahrabi, H. Larijani, M. Mannion, Performance Comparison of Call Routing Algorithms over Virtual Call Centers. School of Computing and Mathematical Sciences, Glasgow Caledonian University. 2007, IEEE.

[8] Vijay Mehrotra, Jasson Fame, Call Center Modeling: Methods, Challenges, and Opportunities, proceedings of the 2003 Winter Simulation Conference, IEEE.

[9] Eric Buist, Pierre L’Ecuyer, A Java Library for Simulating Contact Centers, Département d’Informatique et de Recherche Opérationnelle, Université de Montréal Montréal (Québec) 2005.

[10] Cisco ICM Software Release 4.6.2 Script Editor Guide, Chapter 4 Target Selection, 1992-2008 Cisco Systems, Inc. All rights reserve.

[11] Digium Inc , http://www.digium.com/ [12] Sangoma , http://www.sangoma.com/ [13] Asterisk Architecture, http://www.asteriskpbx.org/support/architecture [14] Manager Actions, http://www.voip-info.org/wiki-Asterisk+ manager+

API [15] IAX: Inter-Asterisk eXchange Version 2, RCF5456 , http://www.rfc-

editor.org/authors/rfc5456.txt [16] Digium Asterisk Hardware Device Interface,

http://docs.tzafrir.org.il/dahdi-linux/ [17] Asterisk config queues.conf, some notes about roundrobin and

rrmemory, disponible en http://www.voip-info.org/wiki/view/Asterisk+ config+queues.conf

[18] Asterisk QueueLog, disponible en http://www.voip-info.org/ wiki/view/ Asterisk+ log+queue_log

[19] Asterisk Call Detail Record (CDR), disponible en http://www.voip-info.org/wiki/view/Asterisk+cdr+cs