Con le ultime due release di asterisk (1.6 e 1.8) il funzionamento e l’utilizzo delle code è cambiato molto, limitandone l’uso allo stretto indispensabile e togliendo alcune possibilità utili nelle configurazioni di tutti i gironi.
Nella prima versione di VoiceOne (la 1.0), che si appoggiava all’ormai vecchio ma stabile asterisk 1.2, le code erano gestite in maniera statica, associando ad ognuna di esse uno o più agenti come member della coda. Ad ogni interno era infatti associato un agente il quale poteva essere volontariamente registrato o deregistrato dall’utente con delle apposite applicazioni. In questa maniera era possibile per ogni interno decidere dinamicamente di smettere di ricevere chiamate dalle code di cui faceva parte (deregistrando l’agente), senza dover inserire il DND e senza quindi rendersi irreperibile per tutti gli altri tipi di chiamata (interne, dirette, ecc…). L’interno poteva poi registrare nuovamente l’agente, abilitandosi alla ricezione delle chiamate in coda.
Il comando di Asterisk che permetteva questo funzionamento era l’ AgentCallbackLogin che è stato deprecato nella versione 1.4, rimosso nella versione 1.6 e pertanto assente nella versione 1.8 di Asterisk. L’uso degli agenti si è ridotto quindi alla sola implementazione di call center avanzato, in cui gli utenti, una volta registrati alla coda con il comando AgentLogin, instaurano una chiamata permanente tra interno e centralino e sono di fatto sempre in linea. Su questo canale ricevono automaticamente le chiamate che arrivano in coda e vengono segnalate all’utente con un beep e possono venire riagganciate con la pressione di un tasto ed il conseguente invio di un tono dtmf. Questa soluzione però non è adatta all’uso che solitamente viene richiesto in fase di configurazione, ovvero che le chiamate vengano messe in coda e da li facciano squillare i telefoni in un ordine di priorità assegnata, saltando da telefono a telefono fino a ricevere risposta. Non si può infatti pretendere che chi risponde rimanga per tutta la durata della sua presenza in ufficio in linea con il centralino, tenendo pertanto occupato l’interno, in attesa che arrivi una chiamata.
La logica degli agenti rimane quindi attiva su Asterisk ma solo per usi avanzati che poco spesso, se non quasi mai, vengono richiesti. L’alternativa è l’uso diretto degli interni come member della coda. In VoiceOne 1.8 è infatti possibile indicare per ogni member la tecnologia che si desidera utilizzare:
- SIP/IAX: l’interno viene chiamato direttamente senza scatenare nessuna macro di gestione della chiamata
- Agent: la chiamata viene passata all’agente che deve essere registrato
- Local: viene chiamato l’interno associato attraverso le macro e la gestione della chiamata di VoiceOne
Delle tre la configurazione di default è la prima, ovvero quella che prevede l’utilizzo della tecnologia dell’interno. Il primo limite di questa configurazione è l’impossibilità di de-registrarsi dalle code, smettendo di ricevere chiamate da esse. Un altro punto dolente è l’impossibilità di far suonare un gruppo di interni e successivamente un altro gruppo di interni indicando per gli interni che si vuole suonino insieme la stessa priorità. In caso di interni con uguale priorità, Asterisk allerterà sempre e solo un interno, il primo libero. E’ quindi possibile far suonare tutti i membri della coda (con la strategia ringall) oppure un membro alla volta, scegliendolo pseudo-casualmente (strategia random) con memoria (stategia rrmemory) o in ordine di priorità (strategia linear). Il vantaggio rispetto all’uso dei canali Local è che nel CDR di Asterisk apparirà solo una riga, indipendentemente da quanti salti sono stati effettuati prima che la chiamata venisse risposta. Con l’uso dei canali Local (come avveniva con l’uso dei vecchi Agenti) infatti viene generata una chiamata ogni volta che viene allertato un telefono con un’esplosione di righe di log nel CDR e la conseguente difficoltà di lettura.
L’unico modo di far suonare diversi gruppi di telefoni in coda sembra essere descritto qui attraverso l’uso del QUEUE_MAX_PENALTY. Una gestione di questo tipo deve essere però stabilita con una macro apposita e altamente personalizzata in funzione della configurazione desiderata, risultando difficilmente manutenibile nel tempo e poco chiara.
Un’alternativa c’è ed è quella di gestire le chiamate con una macro che allerti prima un gruppo di interni ed in mancanza di risposta ne allerti un’altro, per poi tornare eventualmente al primo gruppo formando un ciclo; il tutto riproducendo al chiamante una muscia d’attesa. Chiaramente in questo caso si perdono alcune funzionalità proprie della coda come: il mantenimento della priorità delle chiamate e il messaggio periodico. Queste limitazioni, tuttavia, sono sopportabili se il traffico telefonico non è elevato ed il tempo di risposta medio è basso.
La questione rimane tuttavia aperta, a questa guida ne seguiranno altre che approfondiranno ulteriormente il problema e forniranno nuovi strumenti per lavorare con le code.
With the last two releases of Asterisk (1.6 and 1.8) the operation and use of the queues has changed significantly, limiting a lot their use and taking away some useful options.
In the first version of VoiceOne (1.0), which supported the old but stable Asterisk 1.2, the queues were handled in a static mode, associating each of them one or more agents as a member of the queue. For each extension was associated an agent who could be voluntarily registered or unregistered by the user with the appropriate applications. In this way each extension could decide to stop receiving calls from the queues to which it belonged (unregistering the agent), without having to activate the DND and therefore become unavailable for all other call types (internals, directs, etc…). The extension could then re-register the agent, enabling itself to receive calls of the queue.
The Asterisk command that allowed this operation was the AgentCallbackLogin which was deprecated in version 1.4, removed in version 1.6 and therefore absent in the version 1.8 of Asterisk. The use of agents was reduced only to the implementation of advanced call center, where users, once registered in the queue with the command AgentLogin, permanently establish a call between extension and PBX remaining always in line. On this channel users will automatically receive the calls that arrive in the queue signaled with a beep and they can be hanged up with the push of a button and the subsequent sending of a DTMF tone. This solution, however, is not suitable for the use that is usually required, that is put calls in a queue and send them to phones in an order of priority assigned, jumping from phone to phone up to get an answer. It can not be expected that respondents will remain for the duration of its presence in the office in line with the operator, thus keeping busy inside, waiting for a call is received. It can not be expected that an agent will remain for the duration of its presence in the office in line with the PBX, keeping its phone busy, waiting for a call is received.
The logic of the agents remains active in Asterisk, but only for advanced uses that infrequently, if ever, are required. The alternative is the direct use of the extensions as members of the queue. In VoiceOne 1.8 is in fact possible to indicate for each member the technology you want to use:
- SIP/IAX: the extension is called directly without triggering any macro of call handling
- Agent: the call is passed to the agent who must be registered
- Local: it is called the associated extension through macros, and VoiceOne call management
The first configuration is the default one, which involves the use of the extensions technology. The first limitation of this configuration is the inability to de-register from the queues, stopping receive calls from them. Another sore point is the inability to play a group of extensions and then another group of extensions to indicate that you want to play together inside the same priority. In the case of extensions with same priority, Asterisk will alert always and only an extension, the first one free. It is therefore possible to alert all members of the queue (with the strategy ringall) or a member at a time, choosing pseudo-random (random strategy) with memory (rrmemory strategy) or in priority order (linear strategy). The advantage, compared of the use of Local channels, is that in Asterisk CDR will appear only one line, no matter how many jumps were performed before the call was answered. With the use of Local channels (like it happened with the use of older agents) it is generated a call each time a phone is alerted with an explosion of log entries in the CDR and the consequent difficulty of reading.
The only way to play different groups of phones in the queue appears to be described here through the use of QUEUE_MAX_PENALTY. A management of this type, however, must be established with a specific and highly customized macro depending on the desired configuration, making it difficult to maintain over the time and unclear.
There is an alternative and that is to handle calls with a macro that first warning a group of extensions and, in nobody answer, it will alert another group, and then eventually come back to the first group forming a cycle, playing a music on hold to the caller. Clearly in this case, you lose some features of the queue such as: maintaining the priority of calls and the periodically message. These limitations, however, are bearable if the telephone traffic is not high and the average time of answer is low.
The question remains open, other guides will follow this one that will deep face the problem and provide new tools to work with the queues.
