Colas

De Asterisk Wiki
Saltar a: navegación, buscar

El nombre formal que suelen recibir los sistemas de Colas es el de Distribución Automática de Llamadas. Este tipo de sistemas suele ser muy popular concretamente en el mundo de los Centros de Llamadas, o Call Centers, con fines específicos de servicio postventa, servicio de atención al cliente o incluso servicios de información comercial como usos predominantes.

Como su nombre indica, una Cola de llamadas es exactamente esto, un orden secuencial para estas, de tipo primera en entrar, primera en salir, y una serie de "estrategias" por las cuales, las llamadas son distribuidas, de forma totalmente automática, entre los distintos usuarios o agentes que componen el centro de llamadas.

Imagen de un Call Center actual

Conceptos Generales

Cuando una llamada entra en un sistema de telefonía, puede pasar por un flujo de comandos, antes de ser conectada con la otra parte de la misma. Pero en ocasiones, todas las partes pueden estar ocupadas, pero aún así interesadas en que la llamada no se pierda.

Por regla general, hacer esperar a un llamante, es una mala idea, dado que las personas no estamos dispuestas a permanecer en comunicación con una máquina por un largo periodo de tiempo, por ello en la mayor parte de las ocasiones un Buzón de Voz puede ser una solución muy solvente.

Pero hay veces, que los llamantes tienen la necesidad imperiosa de ponerse en comunicación con alguien, en el intervalo más corto posible de tiempo, considerando que el llamado o llamados se encuentra(n) disponible(s) en el/los teléfono(s). Considerando, que esta necesidad se extrapolase incluso a más de una persona simultáneamente, sería en esta situación cuando se hace imprescindible el uso de algún sistema de secuenciación de las llamadas para dar prioridad a una frente a la otra. Con esto surge el concepto de Cola de Llamada, y en consecuencia, la necesidad de figurar método de distribución de las mismas.

En Asterisk el sistema de Colas de llamadas sigue dos principios básicos:

  • A la idea de establecer la secuenciación, no existe ninguna prioridad especifica, y el método en este caso es la creación de una cola FIFO.
  • Al método de distribuir las llamadas de la mejor forma posible, es llamado Estrategia.

Además durante el estado intermedio, desde el momento que entra en la cola, hasta que la estrategia cumple su función y es comunicado correctamente, pueden existir una serie de "Servicios" adicionales, que pueden aliviar la espera de una forma más o menos conveniente: Música en Espera, mensajes de atención, entre los que se incluyen tiempo estimado de espera, etc...

El sistema de Colas de Asterisk es gestionado con un módulo llamado app_queue.so, y configurado a través del fichero de configuración, queues.conf

Miembros o Agentes de Colas

Por otro lado debemos aclarar otro concepto fundamental del sistema de Colas. Todos aquellos usuarios de un sistema Asterisk, que son capaces de recepcionar llamadas ubicadas dentro de una Cola, son considerados Miembros. Antiguamente, esto se gestionaba con un módulo especifico, de tipo canal llamado chan_agents.so, y su respectivo fichero de configuración agents.conf, en el que se registraban los posibles usuarios de las colas específicamente. Esto registraba algunos problemas de flexibilidad y en la gestión del sistema de distribución automática de llamdas, por eso esta "funcionalidad" se traspaso al fichero principal de Colas de Asterisk.

Con el nuevo "modelo", ya no especificamos determinados usuarios, como accesibles específicos al sistema de colas, sino que directamente son los propios dispositivos concretos por cualquier interfaz o protocolo (SIP/IAX/DAHDI) los que se registran en la cola. Existen dos formas de realizar esta asociación o "registro":

  • De forma Estática, es decir, una cola Concreta, tiene un dispositivo miembro siempre "conectado" por defecto
  • De forma Dinámica, los dispositivos se registran en el sistema y salen de este a voluntad a través de una extensión específica del Plan de Marcación

Aplicación Queue

Esta aplicación, dentro del Dialplan, es la que manda un usuario llamante, a una cola en concreto. La sintaxis especifica de esta Aplicación es la siguiente:

  • Queue(<nombre_de_la_cola>,<opciones>,<URL>,<anuncio_alternativo>,<timeout_absoluto>,<script_AGI>,<macro>,<gosub>,<regla_de_multa>)

Son muchos parámetros los que podemos pasar, pero realmente fundamental, solo el primero, con el nombre de la cola para que podamos acceder a la misma desde la extensión en la que se ejecute

El resto de los parámetros:

  • Sobre las opciones, la mayoría sobre modificadoras de las Opciones especificas de la cola en "tiempo de ejecución"
  • Sobre la URL, parecida la utilidad que dada con la aplicación Dial para mandar una dirección a la parte que reciba la llamada
  • Se puede establecer una pista de audio como anuncio alternativo al especificado en las opciones especificas y generales
  • El tiempo máximo que puede pasar una llamada en espera dentro de la Cola
  • Si queremos lanzar un script AGI en el momento que conecta con el miembro de la cola
  • Los dos siguientes parámetros son lo mismo pero con un Macro o una Subrutina
  • La regla para el sistema de Multasque utilizará por defecto.

Queue(queuename[,options[,URL[,announceoverride[,timeout[,AGI[,macro[,gosub[,rule]]]]]]]])

Configuración del Sistema

Según visto, todo el sistema de colas se configura a través del fichero queues.conf. La estructura del mismo es muy lineal al resto de los ficheros de configuración de Asterisk de otros módulos.

Por un lado tenemos la configuración general en la que podemos especificar parámetros generales del comportamiento del sistema de colas. Esta se especifica con el contexto [general]

Por otro lado, tenemos configuraciones especificas, de las colas en detalle, inclusive, los miembros de las mismas.

Configuración General

Los principales parámetros más utilizados para adaptar una cola común a voluntad son los siguientes:

  • persistentmembers: Cuando registramos miembros de forma dinámica, estos tienen la capacidad de acceder al sistema, salir, y además otras funciones dentro de las colas. Si por un casual la máquina Asterisk se reiniciase, al estar almacenados en la "memoria dinámica" para Asterisk, estos registros se perderían. Con este parámetro activado (yes), utilizamos la base de datos de Asterisk AstDB, para almacenar los registros en tiempo real, pero de forma persistente, aún por encima de posibles inconveniencias con la máquina. Por defecto siempre esta activado.
  • autofill: En versiones pasadas de Asterisk, en el momento que un usuario se ponía en la primera posición de la cola y estaba dispuesto a ser atendido por un agente, hasta que esta comunicación no se realizaba, la cola quedaba "congelada". Si activamos esta opción con yes este comportamiento puede ser modificado a un estilo más "concurrente", para el caso en el que hayan varios agentes disponibles de forma simultanea, todos los primeros puestos de la cola auto-"rellenen" esos puestos vacíos que cada agente puede atender.
  • monitor-type: Existen varios métodos de grabación de llamadas, tenemos el primer sistema llamado "Monitor", y uno más actualizado "MixMonitor", con este parámetro especificamos cual queremos utilizar. La diferencía como podemos ver en Monitorización de Llamadas radica en la forma en la que se realiza la grabación.
  • updatecdr: Sirve para forzar la actualización del registro del detalle de llamadas para los agentes dinámicos al acceder a las Colas.
  • shared_lastcall: En caso que tengamos un agente registrado en varias colas, a efectos de estrategias por ejemplo considerando el tiempo en recibir una siguiente llamada (parametro WRAPUPTIME, llamemosle, tiempo en volver a estar preparado el agente), con este comando activado, la última llamada será tomada en consideración para todas las colas en las que este registrado simultáneamente.

Configuración Especifica de las Colas

Como hemos visto, una cola en concreto puede definirse creando un contexto específico con el nombre de la misma entre corchetes. Ejemplo: [Cola1]. Dentro del mismo podemos añadir todos los parametros específicos de la misma, los más comunes a continuación:

  • musicclass: El nombre de la clase especifica de la Música en Espera con la que queremos dotar a la cola.
  • announce: Si queremos lanzar una pista de audio como anuncio tan pronto un llamante acceda a esta cola, aquí especificamos el nombre de la misma.
  • servicelevel: Podemos especificar un tiempo en segundos, este establecera intervalos para demarcar en las estadisticas, el nivel de servicio con el que responden los agentes de las clas.
  • context: Podemos especificar un contexto en nuestro DialPlan. Si durante la espera el llamante hace una marcación DTMF, lo reencaminaremos a la extension que se asocie a esa marcación dentro del contexto especificado. Útil por ejemplo si queremos dar otras opciones alternativas a la espera en cola. Ejemplo: "Recordarle que usted esta esperando a nuestro departamento de Atención Comercial, si quiere hablar con Asistencia en Carretera, marque el 1".
  • penaltymemberslimit: Aqui podemos decir el número de miembros minimo que debe haber en una cola registrados para que el sistema de "Multas" se aplique
  • timeout: Tiempo máximo en segundos que se puede llamar al miembro que corresponde al cruzar la cola
  • retry: Tiempo mínimo en segundos para intentar llamar a otro miembro en caso que el miembro al que llamabamos no respondio a nuestra llamada en el tiempo establecido en timeout
  • timeoutpriority: Considerando que en la Aplicación Queue podemos especificar un tiempo máximo antes de desconectar al llamante de la cola, y que en la configuración podriamos especificar un tiempo relativo, para que el usuario pueda llamar a un miembro especifico, habría que considerar que mientras que no se establezca la comunicación (inclusive las llamadas a las extensiones), se considera tiempo de espera en cola. Por tanto ambos parametros de tiemout (relativo y "absoluto") podrían entrar en conflicto. Con este parametro si elegimos app damos prioridad al absoluto de la aplicación Queue, y si ponemos conf damos prioridad al especifico del a cola del fichero de configuración
  • wrapuptime: Tiempo en segundos que tiene un agente para "prepararse" al terminar una llamada, para poder esta listo para poder recibir la siguiente. Básicamente sirve para dar un respiro a los agentes y que no estén recibiendo llamadas sin parar.
  • autopause: Podemos especificar si queremos que en caso que un agente no coja una llamada dentro del tiempo especifico en timeout, lo pasaríamos a estado "Pausado". Además también podríamos especificar con all si queremos que se Pause, no solo en la cola donde esta este parámetro, sino en todas las colas en las que este registrado.
  • maxlen: Podemos limitar el número de llamantes máximos permitidos en la cola. En caso que pongamos 0, se consideraría ilimitado.
  • Existen una serie de variables globales concretas que podríamos "rellenar" en caso activar los siguientes parámetros:
    • setinterfacevar: Afecta a variables especificas del miembro
    • setqueueentryvar: Afecta a aspectos relativos al momento pasado en la cola
    • setqueuevar: Afecta a temas referentes a la cola en si
  • monitor-format: Podemos especificar el tipo de Formato que utilizaremos en la grabación de llamadas
  • Existe la posibilidad de controlar tanto el hecho que un llamante entre en una cola con el parámetro joinempty o sea expulsado de la misma leavewhenempty si se dan una o varias circunstancias dentro de una cola a voluntad por nosotros. Estas circunstancias pueden ser las siguientes (separadas por comas):
    • paused: Todos los miembros estan pausados
    • penalty: Todos los miembros tienen un nivel de "Multa" demasiado bajo (inferior a la variable QUEUE_MAX_PENALTY)
    • inuse: Todos los miembros están ocupados
    • ringing: Todos los miembros estan siendo llamados
    • invalid: El estado de los dispositivos miembros es tipo Invalido
    • unknown: No existe conocimiento del estado de los dispositivos miembros.
  • Podemos enviar también determinados Eventos a la interfaz AMI utilizando los siguientes parámetros
    • eventwhencalled: Eventos relacionados a los agentes
    • eventmemberstatus: Evento relacionado a los miembros
  • reportholdtime: Podemos indicar si queremos enviar al miembro que recepciona al llamante, el tiempo que ha pasado el mismo en la cola (para calibrar su nivel de "felicidad")
  • ringinuse: Considerando que solo el protocolo SIP reporta constantemente el estado "En Uso" a nuestra máquina Asterisk, esta comprobación tendría que hacerse para otros protocolos de forma especifica por el sistema de colas. En este caso especificamos si queremos realizar esta comprobación previa a lanzar al usuario de la cola al miembro disponible.
  • memberdelay: Podemos especificar en segundos un tiempo fijo antes de poner a un llamante y un miembro de la cola en contacto
  • defaultrule: Si queremos especificar la regla por defecto en el sistema de "Multas"
  • timeoutrestart: En caso que el llamante mientras se intenta poner en contacto con un Miembro, es cortado la llamada por el mismo, permitir el hecho de resetear el tiempo especificado en el parámetro timeout en caso que ocurra esto exclusivamente.

Miembros de Colas Estáticos

Por un lado podríamos definir miembros estáticos dentro de la cola en cuestión. La sintaxis concretaría sería de la siguiente forma:

member => <Tipo_Canal>/<Nombre_Dispositivo>,<Prioridad>,<Nombre_del_Miembro>

Ejemplo:

member => SIP/ext11,10,Harry Potter

Miembros de Colas Dinámicos

Por otro lado, utilizando aplicaciones especificas en el Plan de Marcación los dispositivos registrados en el sistema Asterisk pueden acceder a las colas como Miembros Dinamicos.

  • Para entrar podemos crear una extensión con la siguiente Aplicación: AddQueueMember(<nombre_de_la_cola>)
  • Para salir, otra extensión con la aplicación: RemoveQueueMember(<nombre_de_la_cola>)

Además si un usuario esta dentro de la cola, tiene la opción de quedarse en estado "Pausado" y así no recibir llamadas entrantes durante el tiempo que permanezca en este estado. Para ello utilizar las siguientes aplicaciones:

  • Para entrar en estado Pausado: PauseQueueMember(<cola>,<Miembro>)
  • Para salir del estado UnpauseQueueMember(<cola>,<Miembro>)

Si no especificamos en estas dos aplicaciones ninguna cola (respetando la primera posición vacia), las utilizariamos de forma generalizada, para todas las colas a las que pertenezca el Miembro en cuestión.

Ejemplos:

  • PauseQueueMember(Cola1,SIP/ext11): Entraría en pausa el miembro del dispositivo ext11 por el protocolo SIP, concretamente en la Cola1
  • PauseQueueMember(,SIP/ext11): Entraría en pausa el mismo dispositivo, para todas las colas que estuviera registrado

Configuración de Estrategias

Como veíamos al principio, el mecanismo que sigue el sistema de Colas para la distribución Automática de las llamadas en las mismas, es mediante el uso de estrategias.

Simplemente existe un parámetro específico de las colas para definir las mismas: strategy. Las posibles estrategias que nos encontramos son las siguientes:

  • ringall: Es la más sencilla, llama a todos los agentes disponibles simultáneamente. Muy útil como alternativa de una aplicación Dial llamando a múltiples pares, dado que podrías registrar más información en el CDR acerca de los mismos..
  • leastrecent: Llama al dispositivo que hace más tiempo que colgó una llamada en esta cola.
  • fewestcalls: Llama a la extensión que menos llamadas haya recepcionado
  • random: Llama a una extensión entre las disponible de manera aleatoria.
  • rrmemory: Siguiendo un sistema Round Robin, recordamos a quien le pasamos la última llamada.
  • rrordered: Igual que rrmemory pero teniendo consideración en el orden secuencial especificado en la lista de Miembros de la cola en concreto.
  • linear: Siguiendo un orden estricto secuencial, según especificado en la lista de Miembros de la cola en concreto.
  • wrandom: Parecido a random, pero tiene en cuenta las Prioridades Especificas de los Miembros como veremos en la subsección correspondiente.

Configuración de Anuncios Avanzados

Es posible lanzar anuncios más sofisticados, que solo el primer anuncio detallado en los parámetros específicos. Para ello tenemos los siguientes parámetros específicos adicionales:

  • Por un lado todos los parámetros para especificar pistas de audio concretas a determinados aspectos:
    • queue-thankyou: Pista que dice: "Gracias por su paciencia"
    • queue-youarenext: Dice: "Usted es el primero en la linea"
    • queue-thereare: Dice: "En estos momentos hay..."
    • queue-callswaiting: Dice: "...llamadas esperando"
    • queue-holdtime: Dice: "El tiempo estimado de espera es de..."
    • queue-minutes: Dice: "...minutos"
    • queue-seconds: Dice: "...segundos"
    • queue-reporthold: Dice: "Tiempo de espera"
    • queue-periodic-annouce: Dice: "Todos nuestros agentes están ocupados, por favor espere al siguiente agente disponible"
  • Por otro lado parámetros específicos para controlar estos anuncios:
    • periodic-annouce: Podemos señalar que otras pistas serán lanzadas de modo periodico, si especificamos sus nombres separados por comas. Se lanzarán de forma secuencial en el orden que están escritos aquí.
    • periodic-announce-frequency: Frecuencia en segundos con la que lanzaremos los mensajes periodicos definidos por nosotros.
    • random-periodic-announce: Decimos si queremos cambiar el orden de los anuncios periodicos definidos por nosotros a un modo aleatorio.
    • relative-periodic-announce: Si ponemos yes, decimos si queremos que el tiempo periodic-announce-frequency, empiece en el momento que termina de reproducirse una de las pistas especificada en periodic-annouce. En otro caso, el tiempo empezara a contar, en el momento que empieza a reproducirse.
    • annouce-frequency: Frecuencia en segundos con la que lanzaremos los mensajes periodicos genéricos
    • min-announce-frequency: Tiempo mínimo en segundos que debe pasar antes de volver a mandar otro mensaje, útil para evitar el caso que haya demasiados movimientos en la cola, no estemos mandando mensajes constantemente.
    • announce-holdtime: Especificamos si queremos que el anuncio de tiempo de espera se lance. Si ponemos once, solo lo indicara una vez al principio.
    • announce-position-limit: Ponemos la posición en la cual se podría anunciar o no, la posición relativa en la cola del llamante según especifiquemos en announce-position
    • announce-position: Especificamos si queremos que la posición se anuncie. También puede estar sujeta condicionalmente, si especificamos limit, solo se empezara a anunciar, a partir del momento que pase el limite impuesto en announce-position-limit, en cambio si ponemos more solo se anunciara hasta que llegue a ese limite.
    • announce-round-seconds: Si especificamos algo, podemos decir en cuantos segundos queremos redondear en el anuncio de Tiempo en espera, en caso contrario, los segundos no se anunciarán.

Prioridades en las Llamadas

Antes comentábamos que las colas en si, no establecían prioridades en estas por si mismas. Pero esto no quiere decir, que nosotros pudiéramos establecer un sistema de prioridades especial utilizando algunos recursos avanzados que nos aporta el sistema de Colas de Asterisk.

Prioridades de Asignación

Utilizando un parámetro de las colas concreto: weight. Es un numero entero, que cuanto más alto, se considera que la cola tiene más prioridad.

Consideramos más prioridad de una cola, siempre y cuando, los agentes, estén registrados en ambas colas simultáneamente, la cola con mas prioridad, les asignaría más usuarios que la cola con menos.

Si por ejemplo tenemos el caso de una persona que ejerce las funciones de operadora, atiende las llamadas entrantes y se las pasa a un servicio de atención postventa. Si alguien llama por una consulta genérica, la operadora podría transferirle a una extensión que ejecuta una aplicación de Colas a una cola con poca prioridad, en cambio si es para un problema urgente que tiene a la empresa paralizada, la operadora podría transferir la llamada a otra extensión con otra cola diferente, la cual tiene el máximo peso entre todas las colas. En este sentido el filtrado de prioridades tendría que hacerse de forma totalmente manual.

Pero podríamos ir más allá en el ejemplo. Combinando otras funcionalidades de Asterisk, podríamos crear una Lista de números "Máxima prioridad" los cuales al entrar en nuestro sistema, serían encaminados automáticamente a una extensión que ejecuta una Cola de máxima prioridad, en cambio el resto, pasaría a una cola de prioridad estándar. Por ello, aunque el sistema de Colas en si, no permita este tipo de "priorización", como venimos viendo desde el principio, el potencial de Asterisk con sus múltiples combinaciones entre Aplicaciones, Módulos, Interfaces, etc, lo hace casi ilimitado.

Prioridades Especificas de los Miembros

Cuando definimos los miembros, con la sintaxis member => sabemos que el primer parámetro es el dispositivo al que hace referencia, pero el segundo, es la prioridad que queremos darle en la cola en concreto.

La utilidad de la prioridad de los miembros, es que si utilizamos estrategias como wrandom que influencia la prioridad que tiene uno u otro usuario, para una cola en concreto.

Por ejemplo, si disponemos de poco personal y hay que tratar varios puntos de la empresa, podríamos por ejemplo poner un usuario más conocedor de un tema en concreto, para una cola especifica (por ejemplo servicio comercial) con mucha prioridad por encima de los otros usuarios, y alguno de los otros usuarios, con conocimiento especifico sobre otro tema (por ejemplo servicio posventa), ponerlo con más prioridad en esa cola, de alguna forma, para distribuir preferentemente las llamadas, en función del conocimiento especifico de cada uno de los componentes generales de las colas.

Esto podríamos ajustarlo aun más, dado que el sistema de asignación subyace realmente en un concepto de "Castigos" o "Multas". A mayor prioridad digamos que afecta en mayor "multa". Cuanto mayor sea la "multa" del miembro, más opciones hay que le suene la llamada concretamente en su extensión.

Entiendo el concepto de las "multas" podríamos diseñar en conjunción a las prioridades, un sistema dinámico de asignación de "multas" mucho más complejo aun que el sistema de estrategias convencionales.

Para ello disponemos de un fichero de configuración especifico queuerules.conf[1] en el que podemos definir una estructura de asignación de "multas" con reglas para ello.

Colas tipo Plantilla

Es posible además crear Plantillas para las colas. Si creamos un contexto tipo Plantilla y a continuación ponemos el simbolo (!), lo marcamos como plantilla. Ejemplo: [ColaPlantilla](!)

Luego dentro de cada contexto secundario, podemos especificar si queremos utilizar la plantilla en cuestión, poniendo junto al contexto la plantilla que queremos utilizar entre parentesis. Ejemplo:

[Cola1](ColaPlantilla)

Referencias

  1. Cambiando las "Multas" Dinamicamente" Asterisk: The Definitive Guide (2010)

Véase también

Enlaces Externos