Archive for giugno, 2011

No more missed calls with ring group

29 giu 2011

No Comments »

Una sostanziale differenza nell’uso dei gruppi tra il vecchio VoiceOne 1.0 ed il nuovo VoiceOne 1.8 è rappresentata dal fatto che le chiamate che allertano un gruppo di telefoni e che vengono risposte da uno di questi, non vengono più registrate come perse dagli altri. La differenza è dovuta principalmente al passaggio da Asterisk 1.2 ad Asterisk 1.8 ed è visibile su tutti quei telefoni (ad esempio Snom e Yealink) che supportano la segnalazione che Asterisk manda a tutti gli interni del gruppo se uno di questi risponde alla chiamata. Nella vecchia versione di Asterisk, così come per tutti quei telefoni hardware o software che non supportano questa specifica segnalazione, quando una chiamata faceva squillare un gruppo di interni ed uno di questi rispondeva, quest’ultimo si vedeva la chiamata registrata correttamente come “Chiamata Entrante” mentre gli altri la registravano come “Chiamata Persa”. Bastava quindi assentarsi dall’ufficio per una mezza giornata che, al rientro, si potevano trovare sul telefono decine di chiamate perse. Molte di queste chiamate però potevano essere state risposte da altri interni appartenenti agli stessi gruppi nei quali eravamo inclusi anche noi. Ora siamo sicuri che se al nostro rientro troviamo chiamate perse queste non sono effettivamente state risposte nè da noi, nè da un nostro collega.

How to setup VoiceOne LDAP directory on Yealink T28

28 giu 2011

No Comments »

Ecco qui una breve guida per configurare sui telefoni Yealink (nello specifico il modello T28) l’accesso alla rubrica LDAP di VoiceOne attivabile con l’apposito modulo LDAP acquistabile sullo store.

Come prima cosa è necessario accedere all’interfaccia web di configurazione del telefono, andare nella sezione “Contacts” e poi sulla scheda “LDAP“. Configurare i campi della scheda come segue:

  1. LDAP Name Filter: (|(cn=%)(sn=%)(gn=%)(o=%))
  2. LDAP Number Filter: (|(telephoneNumber=%)(mobile=%)(facsimileTelephoneNumber=%))
  3. Server Address: <ip di VoiceOne>
  4. Port: 389
  5. Base: dc=voiceone,dc=it
  6. UserName: cn=<id utente associato all’interno>,ou=people,dc=voiceone,dc=it
  7. Password: <password dell’ìnterno>
  8. Max. Hits(1~32000): 50
  9. LDAP Name Attributes: cn sn gn
  10. LDAP Number Attributes: telephoneNumber mobile facsimileTelephoneNumber
  11. LDAP Display Name :%cn
  12. Protocol: VERSION 3
  13. Search Delay(ms)(0~2000): 100
  14. LDAP Lookup For Incoming Call: DISABLED
  15. LDAP Sorting Results: ENABLED
  16. LDAP Lookup For PreDial/Dial: DISABLED

La configurazione è molto semplice e permette di ricercare sul telefono sia per nome che per numero tra i contatti su cui l’utente ha visibilità, e quindi i contatti privati dell’utente e quelli pubblici aziendali. Per reperire il campo username è necessario conoscere l’id utente associato all’interno. Questo valore non è il numero di interno ma l’identificativo dell’utente associato all’interno stesso. E’ possibile recuperare questo valore nella sezione “Utenti” del pannello di configurazione di VoiceOne, aprendo la scheda di modifica dell’utente associato all’interno desiderato. La password dell’utente è invece uguale a quella dell’interno.

Nota per il modello T22P: quando si accedere ad LDAP dal telefono viene mostrato 0/0, dando l’impressione che non funzioni, ma digitando una ricerca allora appariranno i contatti corrispondenti.

Fatene buon uso.

Asterisk 1.8 queues in VoiceOne

28 giu 2011

2 Comments »

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:

  1. SIP/IAX: l’interno viene chiamato direttamente senza scatenare nessuna macro di gestione della chiamata
  2. Agent: la chiamata viene passata all’agente che deve essere registrato
  3. 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.

How to change the ringtone of the phone according to the call

24 giu 2011

No Comments »

La necessità a cui daremo soluzione in questo breve tutorial è quella di modificare la suoneria riprodotta dal telefono pilotandola dal centralino e stabilendola in funzione del chiamante, del tipo di chiamata, della linea d’ingresso o del momento in cui la chiamata viene effettuata. Tutti i principali telefoni Voip, quali ad esempio quelli prodotti da Snom e Yealink, permetto di stabilire diverse suonerie in funzione della comunicazione passata dal centralino al telefono all’interno della richiesta SIP. Il principale esempio di applicazione è la differenziazione delle suonerie tra chiamate interne ed esterne: le prime devono infatti suonare diversamente dalle seconde in modo da essere facilmente riconoscibili.

La comunicazione del tipo di chiamata viene quindi inviata da VoiceOne attraverso un comando inserito nella macro. Il telefono che riceve questa informazione, se opportunamente configurato, esegue la suoneria associata al valore comunicatogli. Il comando inserito nella macro, ad esempio nella “Dial Standard Extension” (che viene eseguita per le chiamate tra interni) è il seguente:

exten = s,n,SIPAddHeader("Alert-Info:<http://www.notused.com>\;info=alert-internal\;x-line-id=0")

Questo comando aggiunge l’ header SIP Alert-info che comunica il tipo di chiamata valorizzando il parametro info con il valore alert-internal. Il telefono che riceve  questa informazione eseguirà la suoneria associata alla label alert-internal. Le label sono personalizzabili anche se per comodità solitamente vengono usate quelle che Snom popola di default (anche se comunque modificabili), ovvero: alert-internal, alert-external ed alert-group. Altri telefoni come Yealink non danno valori di default ma chiedono all’utente di specificali liberamente fino ad un massimo di 10. Possono essere passati valori diversi in situazioni diverse. Se nessun valore è passato dal centralino al telefono allora quest’ultimo eseguirà la suoneria di default associata all’account.

Applicazioni interessanti di questa funzionalità sono:

  1. utilizzare suonerie diverse in funzione del chiamante facendo suonare diversamente i telefoni se a chiamare è il numero di cellulare di un dirigente o di un gruppo di clienti
  2. utilizzare una suoneria diversa dopo l’orario di chiusura per far suonare i telefoni anche ad uffici chiusi mentre il chiamante sente il messaggio di chiusura, ma allo stesso tempo informare gli utenti rimasti in ufficio che la chiamata è arrivata in orario di chiusura
  3. utilizzare suonerie diverse in funzione della linea da cui è entrata la chiamata, per sapere, ad esempio, a quale società del gruppo era destinata.

E’ ora disponibile a titolo di esempio il plugin “Incoming Call to Group setting Phone Ringtone” che include una macro attraverso la quale inviare una chiamata ad un gruppo impostando il valore di alert-info.

Fatene buon uso.

How to change the Caller ID of incoming calls

22 giu 2011

No Comments »

In questo breve articolo vedremo com’è possibile modificare l’identificativo chiamante per le chiamate in ingresso su VoiceOne. Lo scopo di questa azione è fare in modo che sul telefono compaia un nostro riferimento alfanumerico (“Amministrazione”, “N. Verde”, …) in aggiunta a quello passato dalla rete e al numero di telefono del chiamante. Questo permette a chi riceve la chiamata di avere alcune informazioni aggiuntive sulla stessa, come ad esempio la linea da cui è entrata o la scelta effettuata dall’utente nell’IVR (risponditore automatico).

Supponiamo infatti che la nostra organizzazione abbia due linee telefoniche: una intestata alla società AAA e una intestata alla società BBB. Le due società condividono lo stesso ufficio e una unica segretaria smista le chiamate per entrambe. La necessità è quindi quella di informare il posto operatore che risponde a tutte le chiamate se queste sono arrivate sulla linea della società AAA (e quindi devono essere risposte con un “Buongiorno, risponde la società AAA) o invece erano destinate alla società BBB (e quindi devono essere risposte con un “Buongiorno, risponde la società BBB). L’informazione viene passata all’operatore tramite l’identificativo chiamante che viene visualizzato sul telefono. Solitamente questo identificativo indica solamente il numero del chiamante ma è possibile aggiungere dei caratteri prima del numero: nel nostro caso aggiungeremo AAA o BBB in funzione della linea di entrata della chiamata.

Per farlo è sufficiente inserire nella macro di gestione della chiamata (ad es. incoming-call-to-extension) un parametro aggiuntivo con la conseguente possibilità di specificare una stringa testuale al momento della configurazione dell’invocazione della macro nelle regole d’ingresso o nei nodi dell’IVR. Inseriamo quindi in fondo ai parametri della macro la stringa

<param name="prefix" type="TEXTFIELD" label="Prefix" description="Prefix to add to the cid name" />

e contiamo la posizione del nostro parametro nell’elenco dei parametri. Se il nostro parametro è il sesto, potremo invocarlo all’interno del codice della macro con ${ARG6}.

N.B. l’elenco dei parametri di una macro non è modificabile se questa è in uso in una regola o in una applicazione. Per modificarla eliminate la regola o l’applicazione che la blocca e ricordate di ricrearla dopo la modifica. In alternativa potete dupplicare la macro, creandone una nuova cambiando il nome e la label, e mantenendo invariati parametri e codice a meno delle modifiche di questo tutorial (creando ad esempio la macro incoming-call-to-extension-with-cid-prefix).

Dopodichè aggiungiamo la seguente riga all’interno della macro, prestando attenzione che si trovi prima del comando Dial e che il parametro ${ARG6} sia il riferimento al parametro prefisso appena inserito (in caso contrario cambiatelo con ${ARGN} dove N è la posizione del nuovo paramtro nell’elenco di quelli della macro che state creando o modificando):

exten = s,n,Set(CALLERID(name)=${ARGN}${CALLERID(name)})

A questo punto possiamo creare due regole: una che intercetti le numerazioni della linea della prima società e scateni la macro appena modificata con impostato nel campo “Prefix” il valore “AAA”, e un’altra regola che intercetti le numerazioni della seconda società impostando questa volta come valore del campo “BBB”. Il posto operatore vedrà quindi sul monitor del telefono: AAA (seguito dal numero chiamante) per le chiamate destinate alla prima società o BBB (seguito dal numero chiamante) per quelle della seconda.

La stessa cosa può essere applicata anche alle macro scatenate dall’IVR. A che pro? Supponiamo di volere un IVR nel quale il chiamante può scegliere tra amministrazione, commerciale e ufficio personale e che queste selezioni facciano suonare gruppi diversi di telefoni. Alcuni utenti potrebbero essere inclusi in più di un gruppo ed essere interessati a sapere se il chiamante ha richiesto di parlare con un commerciale o con un amministrativo. Modificando la macro incoming-call-to-group posso fare in modo che tutti vedano anteposto al numero un riferimento che indichi la scelta fatta dal chiamante.

Attenzione: molti dispositivi non danno la possibilità di scelta sulla visualizzazione a monitor dell’identificativo chiamante. Non permettono infatti di scegliere se visualizzare il nome, il numero o entrambi. Alcuni di questi usano una logica molto semplice: se è presente solo un identificativo numerico visualizzano questo, altrimenti visualizzano solo l’identificativo nome. Seguendo quanto scritto in precedenza si va a popolare il campo nome e questo comporta che molti telefoni non visualizzino più il numero, ma solo il prefisso che abbiamo inserito. Per ovviare a questo problema è necessario indicare al telefono di visualizzare sia il nome che il numero (operazione possibile ad esempio sui telefoni Snom), oppure sostituire la riga sopra con queste:

exten = s,n,Set(CALLERID(name)=${IF($["${CALLERID(name)}"=""]?${CALLERID(num)})})
exten = s,n,Set(CALLERID(name)=${ARG6}${CALLERID(name)})

in questo modo se il chiamante ha il campo nome popolato, perchè è un interno ho il numero da cui chiama è in rubrica, vedremo regolarmente sul telefono il nome preceduto dal prefisso, altrimenti verrà visualizzato il numero preceduto sempre dal prefisso.

Fatene buon uso.