Howto localized:Innovaphone Call Sequencer (I)
L’innovaphone Call Sequencer è un combinatore telefonico a bordo dell’innovaphone PBX realizzato con dei script XML.
Permette di chiamare automaticamente una serie di numeri, uno dopo l’altro e di riprodurre un messaggio.
Durante la riproduzione del messaggio l’utente chiamato potrà fermare il combinatore digitando il numero “1” sul suo telefono. Digitando “1” l’utente “accetta” l’incarico e ferma il combinatore, digitando invece lo “0” rifiuta l’incarico e il combinatore chiamerà il numero successivo. Il passaggio al numero successivo avvera anche in caso di mancata risposta, occupato oppure mancato invio di numero dopo la risposta.
Di seguito la parola “sequencer” viene utilizzata per indicare l’innovaphone Call Sequencer, quindi il combinatore.
Il combinatore può essere avviato da una chiamata, il chiamante non deve attendere ma potrà svincolare e il Sequenzer contiunuerà in modo autonomo.
Tipicamente il Sequenzer viene attivato da un contatto pulito fornito dal cliente, per esempio l'uscita di un PLC o di una macchina.
Il sequencer è rivolto ad ambienti, dove è richiesta una sequenza di chiamate ben definita e inoltre una chiara assegnazione di responsabilità e presa in carico di un evento. E’ possibile definire fino a 99 numeri da chiamare in fila e la lista può essere ripetuta più volte. Inoltre può essere definito un ultimo utente da chiamare solo se nessuno accetta.
Il presente articolo da maggiori dettagli sul sistema e su come implementarlo.
Attenzione: Come spiegato gli utenti vengono chiamati in successione, quindi uno dopo l’altro e non contemporaneamente. Il sistema innovaphone permette tuttavia anche una chiamata contemporanea di più utenti che alla risposta sentono un messaggio e sono tutti in una conferenza. Questo però si realizza diversamente e non è descritto in quest’articolo.
Il presente documento descrive la Versione 1.0 (vedi sorgente XML).
Requisiti
innovaphone PBX versione 10 o superiore.
Il sequencer impegna 4 DSP, se si installa anche l’opzione di interruzione campagna sono richiesti 5 DSP (attenzione con IP305). Il sequencer utilizza unità di conferenza a bordo dei gateway, vedi releative limitazioni (no IP302).
Per interfacciamento con contatto pulito: una porta analogica (IP302, IP22, IP24,IP28) con relativa licenza porta.
Numeri da chiamare: max 99
Durata messaggio Audio: max. 10 secondi
Durata massima campagna: 20 minuti
Attenzione: Visto le limitazioni (vedi problematiche note), il fatto che il combinatore è un servizio XML a bordo del sistema telefonico e una ridondanza non è possibile, si sconsiglia l’uso in ambienti critici perché il servizio non potrà essere garantito. Ricordiamo inoltre che innovaphone non si assume alcuna responsabilità per eventuali danni diretti e indiretti a persone o cose causate dall’utilizzo di questo servizio. L’utilizzo avviene quindi a proprio rischio, osservate anche le condizioni di utilizzo innovaphone.
Dettagli
Il sequencer si attiva chiamando un determinato numero nel PBX. Il chiamante potrà essere sia un interno del PBX che un esterno in selezione passante; sarà cura dell’amministratore di sistema evitare che numeri non autorizzati avviino una campagna di allarme (vedi Configurazione). In realtà la chiamata avviene verso un’unità di conferenza; di conseguenza essa potrà essere chiamata direttamente con qualsiasi telefono di qualsiasi tipo.
Un centralino può gestire in parallelo più sequencer e quindi sono possibili contatti puliti multipli che faranno scattare diverse serie di chiamate. Da osservare quanto già descritto nei requisiti: ogni serie di chiamate richiede minimo 4 DSP (5 con opzione di interruzione della serie).
Esempio: Due sequencer, un contatto indica il livello alto nel silo di stoccaggio e un altro contatto indica l'avaria di un generatore. Ci saranno quindi due contatti che portano a due serie di chiamata potenzialmente anche nello stesso momento. In questo caso per garantire la funzione saranno necessari 10 DSP disponibili in ogni momento.
Osservate anche quanto riportato nella sezione "Problematica note" alla fine di questa descrfizione
Contatti puliti
Spesso è richiesto di avviare la sequenza di chiamate tramite un contatto pulito.
Il contatto pulito di un sistema esterno chiuderà una porta analogica che di seguito attiverà la serie di chiamate. Per maggiori dettagli vedi configurazione. Il contatto pulito potrà chiudere e rimanere chiuso fino al ripristino oppure dare solo un impulso. In caso di chiusura con un singolo impulso questo deve durare almeno due secondi per un’esecuzione certa. Il sequencer una volta scattato non accetta successivi allarmi fino al termine della campagna in corso. Si evita così che durante una serie di chiamate di allarme ne parta una seconda.
Dal punto di vista telefonico è sufficiente quindi chiamare l’unità di conferenza, attendere due secondi e poi sganciare, non serve rimanere “in linea” durante la serie di chiamate perché il sequencer si autogestisce, ovvero una volta lanciato il sequencer continua il suo operato anche se il chiamante iniziale sgancia.
Serie di chiamate
Una volta avviato il sequencer chiama in sequenza dei numeri telefonici in un ordine fissato dall’amministratore di sistema. L’elenco delle chiamate seriali è limitato a 99. Nel caso in cui si arrivi alla fine della lista senza esito positivo (cioè senza che nessuno abbia confermato l’incarico), il sequencer termina. Se richiesto, è possibile impostare un determinato numero di ripetizioni della lista; in questo caso una volta arrivato a fine lista, il sequencer riavvia la serie di chiamate iniziando dal primo utente. A fine lista inoltre è postibile impostare un tempo di attesa e un tempo di attesa diverso se il sequencer riscontra tutti i numeri chiamati occupati. E’ quindi possibile fare attendere tanto a fine lista nel caso di riscontro di "tutti occupati" e meno in caso di mancata accettazione.
Il sequencer lavora con una logica “lenta” tipica di sistemi di sicurezza; ogni passo richiede un determinato tempo e una serie di chiamate dura alcuni secondi.
Esempio: In una serie di chiamate con due numeri nella lista, il cliente desidera ripetere due volte la serie in caso di insuccesso. Il sequencer tenta di chiamare il primo numero e trova occupato e di seguito tenta il secondo numero anch’esso occupato: il tempo richiesto sarà di oltre 10 secondi. Ripetendo la sequenza per altre due volte trascorreranno quindi ca. 30 secondi, ma potrebbero essere pochi perché non è detto che i numeri chiamati si liberino entro questo lasso di tempo. Se invece viene impostata una pausa di 60 secondi tra un passaggio e l’altro dopo avere tentato di chiamare la prima volta l’intera lista il sequencer attende 30 secondi, poi fa un altro tentativo e attende altri 30 secondi prima di effettuare l’ultimo “giro”; l’ultimo tentativo di chiamata sarà quindi a ca. 150 secondi dopo l’inizio della prima serie.
L’innovaphone Call Sequencer si potrebbe anche vedere come una sorta di escalation di chiamate: se il numero primario non risponde, si tenta quello secondario e così via.
In una serie di chiamate ogni singola chiamata ha diversi possibili esiti:
• L’utente risponde e conferma con la presa in carico digitando “1”: il sequencer termina.
• L’utente risponde ma rifiuta l’incarico digitando “0”: il sequencer continua.
• L’utente risponde ma non digita nulla: il sequencer attende e poi continua.
• L’utente risponde ma digita altri toni (ne “1” ne “0”): il sequencer attende e poi continua.
• L’utente non risponde: il sequencer continua.
• L’utente è occupato: il sequencer continua.
Tutte questi possibili esiti di una chiamata sono rilevati dal sequencer e protocollati in una cartella.
Il seguente disegno mostra il principio di funzionamento:
Overflow
E’ possibile definire un numero che viene chiamato solo al termine della campagna, quindi al termine di tutte le ripetizioni della lista.
Protocollo
Tutti le chiamate e il loro esito vengono protocollati sulla Compact Flash.
E’ anche possibile impostare l’invio degli avvisi di protocollo in parallelo tramite email.
Ogni campagna sarà protocollata in una cartella dedicata, il nome della cartella è composto dalla data e ora di inizio serie:
Nell’esempio sopra “2014_09_03_1424” significa anno=2014, mese=09, giorno=03, ora=14:24.
Nel caso improbabile di più serie nello stesso minuto (possibile solo con serie molto brevi e allarmi ripetuti nello stesso minuto) la cartella avrà un’estensione _1, _2 ecc.
All’interno della cartella si trovano i file di protocollo:
Il protocollo sono file vuoti (0 bytes), il nome del file indica l’ora, il numero chiamato e l’esito.
L’esempio sopra si legge come segue:
1918_39_No_Answer: alle ore 19:18 è stato chiamato il numero 39 che non ha risposto.
1918_370_Answer: poi la chiamata è passata all’interno 370 che ha risposto ma non ha fatto nulla
1919_39_Answer: di seguito alla 19:19 la chiamata è stata passata di nuovo al numero 39 che ha risposto
1919_39_Accept: sempre alle ore 19:19 il numero 39 ha accettato.
Segue la lista dei possibili esiti di una chiamata:
“No_Answer” = mancata risposta
“Answer” = risposta
“Busy” = occupato
“Reject” = rifiutato (ha selezionato “0”)
“Accept” = accettato (ha selezionato “1”)
“Final Loop” = Sequenza terminata senza successo
“xx_Abort_User_yy” = mentre era in corso la chiamata verso il numero xx è stato forzato il termine della sequenza da parte dell’utente yy
I seguenti eventuali errori vengono protocollati:
“Watchdog” = forzata chiusura del sequencer
“Call_to_short” = chiamata per attivare la campagna troppo breve
“unknown” = errore sconosciuto
“Double_Call” = Chiamata durante und campagna attiva
Nel caso di avviso tramite email il protocollo è contenuto nell’oggetto, ecco un esempio:
Interruzione forzata
Come già descritto, una volta attivata, una serie di chiamate continua fino al termine o perché arrivata alla fine della lista (ed eventuali ripetizioni della lista chiamate) oppure perché un utente accetta.
E’ possibile anche fermare il combinatore e quindi una l’interruzione della serie da parte di un utente (abilitato). Questo è utile per esempio se la serie è stata attivata per errore, oppure il personale è già sul posto e non è più necessario un intervento da parte di terzi.
Per cancellare manualmente una serie si comporre un numero, di seguito l’utente sente il messaggio di avviso e se seleziona “1” sente la conferma e il sequencer si ferma.
Nel log (ed email) sarà protocollata l’interruzione della campagna con indicazione dell’utente che l’ha interrotta.
Esempio: 1623_39_Abort User_24
Significa che alle ore 16:23 mentre il sistema stava elaborando l’utente 39, l’utente 24 ha fermato il combinatore.
Localizzazione
I testi si possono localizzare solo direttamente modificando la sorgente del XML, operazione alquanto facile.
La prima parte dell’oggetto dell’email è impostabile in un file di configurazione (vedi configurazione).
I file audio forniti sono in inglese, sarà in ogni caso necessario adattarli al singolo cliente.
Se un utente della serie risponde, sente ripetutamente il messaggio “Alarm, press one for accept or zero for reject”. Se preme lo zero sente “reject”, segue di nuovo l’annuncio principale. Se conferma con “1” sente “accepted” e il sistema aggancia.
Nota: Se si chiama con un telefono l’unità di conferenza viene anche riprodotto il messaggio “Alarm, press one for accept or zero for reject”: non eseguire tale comando ma agganciare. Questa situazione si manifesta solo se a scattare l’allarme è un telefono.
Se un utente chiama il numero per l’interruzione forzata sente ripetutamente il messaggio “press one to abort”, se preme “1” riceve la conferma “job cleared” e la chiamata viene terminata.
Segue la tabella dei messaggi e il nome del relativo file. In parentesi è riportato un ipotetico messaggio localizzato.
Track101 – “Alarm, press one for accept or zero for reject” (allarme livello serbatoio due, premete uno per accettare oppure zero per rifiutare l’incarico)
Track102 – “reject” (incarico rifiutato)
Track103 – “accepted” (incarico accettato)
Track104 – “press one to abort” (premete uno per fermare il combinatore allarme livello serbatoio)
Track105 – “job cleared” (serie allarme livello cancellata)
La registrazione potrà avvenire anche utilizzando il tool “Track recorder” (vedi sezione link).
Nota: Il messaggio principale dovrebbe essere il più corto possibile, altrimenti si rischia che il sequencer vada al prossimo utente prima della sua riproduzione completa. Bisogna anche considerare che l’utente potrebbe non capire bene la prima volta il messaggio, è quindi utile farlo sentire più volte. Il messaggio sarà ripetuto comunque automaticamente, in parallelo ci sono però altri timer che scattano per evitare un prolungarsi del percorso. Ideali sono messaggi con una durata di non oltre cinque secondi.
Applicazioni esterne
Le cartelle del sequencer possono essere lette da applicativi esterni. Inoltre è possibile fermare il combinatore da parte di un software esterno: se si copia (crea) und file “AppEND.txt” nella cartelle “TMP” il sequencer termina.
Attenzione: questa operazione causa nel log il messaggio “unknown”.
Configurazione
Dopo il download della soluzione sul vostro PC entrate nella cartella sorgente dove trovate 4 file XML dei file con estensione .G711 e dei file di testo.
Per prima cosa configurate i file di testo, poi create una cartella sulla CF e copiate il tutto in questa cartella. Di seguito configurate il PBX.
Segue la descrizione dei singoli passi.
Configurazione dei file di testo
I file di configurazione sono file di testo con il parametro nella prima unica riga (contenuto) e iniziano con “Setup”. Sono tutti necessari e quindi da impostare attentamente.
“SetupLoops.text” contiene il numero di ripetizioni da fare oltre il primo giro.
Esempio contenuto “0”: il sistema esegue una volta la lista e poi termina.
Esempio contenuto “2”: il sistema ripete per due volte la lista dopo il primo passaggio (quindi 3 giri in totale)
“SetupLoopPause.txt” indica il numero di secondi di pausa tra un giro e l’altro.
Esempio contenuto “0 ”: appena il sequencer è arrivato alla fine della lista inizia di nuovo con il primo da chiamare
Esempio contenuto “10”: appena il sequencer è arrivato alla fine attende 10 secondi e poi inizia di nuovo a chiamare il primo in lista
“SetupLoopBusy.txt” indica il numero di secondi di pausa tra un giro e l’altro se tutti gli interni sono occupati.
Esempio contenuto “30”: appena il sequencer è arrivato alla fine della lista e tutti i chiamati erano occupati, attende 30 secondi e poi inizia di nuovo a chiamare il primo in lista
“SetupCFNAtime.txt” contiene il timeout per mancata risposta.
Esempio contenuto “15”: dopo 15 secondi la chiamata sarà terminata e il sequencer passa alla chiamata successiva.
Attenzione: Il sequencer passerà alla chiamata successiva anche se l’utente risponde ma non seleziona “0” oppure “1”. Il tempo di attesa per l’invio di un comando è pari a 10 secondi + questo contatore. Se in questo esempio l’utente risponde dopo 15 secondi ha 10 secondi per agire, se risponde dopo 5 secondi ha 20 secondi per accettare o rifiutare l’incarico.
“SetupMailHeader.txt” contiene la prima parte dell’oggetto nell’email.
Esempio contenuto “Allarme zona 1”: gli email avranno come oggetto “Allarme zona 1 – 1644_1234_Accept” e simile.
“SetupMailto.txt” contiene la destinazione delle email. Se vuoto la funzione sarà disabilitata.
Esempio contenuto kwa@innovaphone.com
“SetupMailServer.txt” contiene l’indirizzo IP del mail server, esempio contenuto “172.16.88.99”
Nota: L’invio delle email segue la logica della notifica della Voicemail. Pertanto è possibile immettere altri parametri, vedi sorgente.
Sequenza
La sequenza, quindi l’ordine nel quale avvengono le chiamate, viene impostata creando dei file di testo con nome in ordine numerico crescente che contengono il numero di destinazione. Il sequencer inizia una campagna gestendo prima il file 1.txt, poi il file 2.text e così via.
Esempio:
Il sequencer deve chiamare prima il numero 24, poi il numero 37 e poi il numero 0118. Si creano i seguente file di testo con il seguente contenuto:
File “1.txt” con contenuto “24”
File “2.text” con contenuto “37”
Fiel “3.txt” con contenuto “0118”
L’XML inizia la campagna leggendo il contenuto del file 1.txt, poi incrementa un contatore che va a 2 e apre il file 2.txt ecc. Se un file non viene trovato il programma ritiene di essere arrivato a fine lista.
L’eventuale utente overflow si definisce in un file di testo “X.txt”. Se il sequencer a fine lista e fine ripetizione liste trova un file "X.txt" chiama il numero in esso contenuto.
Una volta configurati tutti i file di testo copiate tutti i file in una cartella sulla CF.
Nota: Dopo il primo avvio del XML il sequencer crea automaticamente una cartella di lavoro “TMP” e una cartella di protocollo “LOG”.
ATTENTION: An automatic creation of the directories doesn't work on a local CF Card or some other Webdav Servers. Because of this, following Subdirectories should be created manually in the Call Sequencer Directory (All with BIG letters):
ALV
LOG
SYN
TMP
Attenzione: In ambienti critici è bene assicurarsi che l’allarme sia comunque preso in carico e quindi impostare per esempio nella sequenza come ultimo numero oppure come utente overflow una postazione telefonica sempre disponibile (per esempio la portineria).
PBX
Nel PBX si devono creare 4 oggetti Voicemail e indicare i relativi percorsi. Da notare che solo l’XML ”AlarmXMLuser”, che permette di cancellare una serie di chiamate da un telefono, richiede un numero (perché deve essere chiamabile) mentre gli altri oggetti richiedono solo un nome. Per convenzione raccomandiamo di utilizzare il nome degli XML come nome nel PBX, facilitando cosi l’individuazione. Nel campo “Script Url” ci sarà quindi indicato
http://172.16.88.98/DRIVE/CF0/AlarmXML/AlarmXML.xml
nel oggetto VM AlarmXML.
Nota: Sia l’XML “AlamXMLuser.xml” che “AlarmXMLc.xml” richiedono il parametro “?$_pbxcoder=g711a”:
(nell’esempio non si vede la “a” finale).
Ora si crea un oggetto BCconference, sarà questo oggetto che una volta chiamato avvia gli XML. “Alert timeout” 60, “Connecting mode” direct, “Answer timeout” 25, non spuntate nulla, neanche “Disconnect last remaining user”.
Se avete configurato correttamente l’unità di conferenza, la potete testarla chiamando la con dei telefoni; se funziona correttamente tutti i chiamanti sono in una conferenza. Precedete solo se questo funziona con i passi successivi.
Per fare scattare il combinatore se viene chiamato l’unità di conferenza è necessario assegnare dei gruppi agli oggetti.
Nell’esempio seguente l’unità di conferenza si chiama innoconf (blu) e le è stato associato il numero “99” e un gruppo “BCCONF” (giallo) che è attivo (asterisco, vedi freccia gialla) mentre agli XML “AlarmXML” a “AlarmXMLC” è stato associato lo stesso gruppo ma non attivo. Osservate che gli XML “AlarmXMLB” e “AlarmXMLuser” NON devono avere associati ad alcun gruppo. Inoltre si vede che all’XML ““AlarmXMLuser” è stato associato un numero (“*95”) e quindi sarà chiamabile, selezionando questo numero un utente potrà bloccare una campagna di allarme. Se questo servizio invece non è richiesto, si potrà fare anche a meno di tale XML. Gli altri tre XML invece non richiedono un numero e non disturbano quindi il piano di numerazione.
Alla fine la vostra configurazione dovrebbe essere simile a quella sopra riportata. Nell’esempio chiamando il 99 si avvia il sequencer.
E’ importante evitare che un interno qualsiasi chiami l’unità di conferenza che fa scattare la sequenza di allarme. Un modo semplice per evitare questo è deviare tutti ma non l’interno abilitato (per esempio la porta analogica).
Nell’esempio infatti vedete una CFU attiva sull’oggetto BC Conference verso il numero 111 che nell’esempio è il numero del P.O.
Nell’esempio sotto è chiaro il dettaglio di questa deviazione: è valido per tutti e devia verso il numero 111, escluso solo il numero 24 (l’unico che è in grado di fare scattare l’allarme).
Nota: Se in uno scenario sono necessari più gruppi di allarme (quindi contatti diversi) si replica questo setup con altri nomi e gruppi.
Contatti puliti
Segue la descrizione di come realizzare l’avvio di un allarme con un contatto pulito fornito dal cliente.
Questo servizio richiede una porta analogica (IP22/24/28 oppure IP302) con relativa licenza PBX. L’avvio della chiamata di allarme potrà essere impostata in modalità immediata oppure ritardata.
Nella configurazione PBX si associa all’interno analogico una hotline che termina sull’oggetto BC Conference:
Nell’esempio sull’interno analogico 34 è stato configurata una hotline (Direct Dial) immediata (campo “after” vuoto). Appena si sgancia il telefono 34 avviene una chiamata al numero 99 (cerchio rosso).
Notate che se si uniscono i due fili che portano ad un interno analogico (se mette in cortocircuito i due fili) questo equivale a uno sgancio della cornetta del telefono analogico. Per salvaguardare l’elettronica sarebbe meglio inserire una resistenza di 300 o 600 Ohm, ma non è strettamente necessario. Chiudendosi quindi il contatto simula uno sgancio e sarà chiamata l’unità di conferenza che avvierà la sequenza di allarme.
Spesso le logiche di sicurezza funzionano al contrario, quindi il contatto è chiuso quando tutto è o.k. e il contatto sarà aperto in caso di disturbo. Se avete tale richiesta, sarà necessario invertire il contatto utilizzando un relè esterno. Ecco il principio:
Il contatto normalmente chiuso del cliente è evidenziato nel quadrato punteggiato, il relè sarà quindi alimentato e chiuso. Si sfrutta un contatto del relè normalmente chiuso (che quindi è aperto se il relè è chiuso) per collegarsi alla porta analogica. Nel disegno è evidenziata in serie anche una resistenza, le due frecce portano alla porta analogica.
Discussione tecnica
Questo paragrafo è destinato a chi legge le sorgenti e tenta di capirne il funzionamento. Chi non è interessato a questo può saltare questo paragrafo (pesante).
Gli XML sono scritti in chiaro con comandi semplici descritti nello schema vm.html.
La descrizione che segue descrive qundi solo i principi su cui ci si è basati nella scrittura del programma.
Il sequencer è composto da quattro XML:
• AlarmXMLuser.xml : un XML che scrive il file /TMP/AppEND.txt per terminare l’applicazione e non viene descritto nel testo presente.
• AlarmXML.xml (denominato “A”) : questo XML viene chiamato dall’XML “A” e quindi viene considerato come una estensione di ”A”.
• AlarmXMLC.xml (denominato “C”).
• AlarmXMLB.xml (denominato “B”)
Gli XML si attivano solo se vengono chiamati da qualcuno e terminano nel momento in cui il chiamante sgancia. Quindi chiamando un XML e riagganciando subito dopo l’XML termina (potrà ancora eseguire qualche operazione dati perché riceve un relativo evento, ma non potrà chiamare nessuno), perché il PBX appena il chiamato o il chiamante termina il collegamento chiude anche tutti i relativi processi e si incapsula la parte attiva.
La soluzione adottata è quella di utilizzare l’unità di conferenza che chiamerà gli XML (“A” e “C”) e, poiché un’unità di conferenza non svincola mai, essi rimangono attivi fino a che terminano da programma. Sono quindi gli XML stessi a terminare il collegamento con l’unità di conferenza, e questo richiede una particolare attenzione per non creare delle situazioni dove il programma stesso non termina mai.
Un XML può solo trasferire la chiamata verso una destinazione ma non può chiamare. Quando un XML esegue una trasferta, termina perché mette in connessione il chiamante con il chiamato anche se rimane una piccola traccia a livello di segnalazione (l’XML potrà per esempio ancora segnalare se la chiamata ha riscontrato occupato).
Per evitare che “A” termini nel momento in cui trasferisce la chiamata al primo numero, si è fatto in modo di chiamare un altro XML e fare eseguire da questo la trasferta. In questo caso “A” termina, ma “ritorna” a destinazione, come una subroutine. Quindi “A” chiama con il commando “exec” un’applicazione esterna, l’XML “B” appunto che trasferisce la chiamata ad un numero. Una volta trasferito ritorna a chi lo ha chiamato, il programma “A”. Questo permette di chiamare un numero qualsiasi di destinazioni in sequenza.
I programmi si scambiano le informazioni attraverso dei file che vengono depositati sulla CF nella cartella “TMP”, quindi anche se “B” viene avviato da “A” esso non sa nulla di “A” (per esempio chi è da chiamare oppure l’esito della trasferta). Ma in una trasferta un XML (il “B”) riesce a rilevare solo 3 stati di esito chiamata: occupato, senza risposta e risposta che sono comunicati da “B” ad “A” nel file “callend.txt”.
E’ necessario rilevare altre due situazioni. Se il chiamato risponde viene rilevato da “B” e trasmesso, ma se l’utente chiamato non fa nulla (quindi non aggancia, non seleziona ma semplicemente ascolta) è necessario terminare attivamente la chiamata. Per questo è presente un timer in “A” che scatta e recupera questa situazione. Più difficile è rilevare se il chiamato digita un tono DTMF (“0” o “1”, per rifiutare o confermare l’incarico) perché le tecniche comuni per rilevare toni DTMF in un XML falliscono avendo una combinazione di due XML (“A” che chiama “B” che inoltre e ritorna) come sopra descritto. Ne “A” ne B” quindi sono in grado di rilevare toni DTMF. Per questo motivo l’unità di conferenza fa partire anche l’XML “C” che ha il compito di riprodurre il messaggio e soprattutto di rilevare i toni DTMF. I toni rilevati (quindi “0” o “1”) vengono segnalati da “C” ad “A” di nuovo tramite dei file. “C” termina perché rileva il tono DTMF “1” oppure perché trova il file AppEND.txt oppure quando il suo timer interno (tarato a 20 minuti), scatta.
Un’altra difficoltà sono la sincronizzazione e il blocco di avvii multipli. Naturalmente è possibile installare tutto più volte in cartelle diverse e configurare diversi oggetti BCconf. Il problema a cui ci riferiamo è la chiamata multipla del sequenzer. Chiamando più volte il BCconf saranno aperte più conferenze e chiamati più XML “A” e “C”. Questo può succedere facilmente utilizzando contatti puliti. Immaginate per esempio che su un apparato scatti un allarme, il contatto si chiude e il combinatore parte. Mentre inizia a chiamare, un addetto sul posto fa un reset dell’allarme, quindi il contatto si apre, ma poi scatta di nuovo perché il guasto non è risolto. Le conseguenze per il sistema sarebbero imprevedibili, perché i processi che non sanno uno dell’altro modificano i file e i risultati. Impossibile quindi capire cosa succede esattamente, chi accetta un incarico oppure chi verrà chiamato per prossimo, il tutto diventerebbe causale.
Per questo è stata pensata una logica che eviti l’avvio del combinatore quando è già attivo.
Scrivere un file per indicare agli altri processi che un programma è già in esecuzione innesca un meccanismo pericoloso. Immaginiamo un riavvio del centralino in tale situazione, non partirebbe più alcun allarme a causa di tutti i file di blocco, la situazione potrebbe complicarsi ulteriormente se un contatto si aprisse e chiudesse più volte; ci sarebbero così non un solo ma tanti avvii di XML. Inoltre ogni volta si dovrebbero bloccare due XLM (l’unità di conferenza avvia sia “A” che “C”). Gli XML e il sistema operativo si possono avviare in modo indipendente e incapsulato più volte: un XML non sa niente di altri XML e non può a rilevare se altri XLM sono attivi oppure no. Questo funzionamento, tipico degli XML, costituisce un problema per il sequencer che non deve funzionare più volte in parallelo (chiamata multipla sulla stessa unità). Naturalmente è possibile invece eseguire più installazioni parallele del sequencer.
Il sequencer risolve il problema dell’avvio multiplo e della sincronizzazione dei processi grazie ad un avvio gestito ed accurato di seguito descritto. Quando l’unità di conferenza chiama sia “A” che “C”, “C” si ferma subito in una routine di attesa e attende che arrivi una chiave unica da parte di “A”. Tutte le routine di attesa descritte hanno un timeout, se non succede nulla entro un determinato intervallo, l’XML termina. “C” attende per esempio 5 secondi l’arrivo della chiave ID. “A” invece appena avviato si crea una chiave ID unica (la cifra lunga visibile anche nel recording e nei VM) e la scrive nel file “TMP/IDsynch.txt”. “C” rivela che esiste il file, lo legge e lo cancella immediatamente; ora sia “A” che “C” lavorano su un unico ID.
“A” dopo avere scritto il file ID, attende che il file sparisca e cioè che sia stato letto da “C”. “C” ora attende per 15 secondi di ricevere da “A” il comando di partenza definitiva, che viene segnalata da “A” a “C” scrivendo un file con il nome del ID nella cartella “SYN”. “A” nel suo percorso iniziale controlla se esistono le cartelle "SYN” e “ALV” e le crea se non ci sono. In “ALV” “A” scrive anche un file con il nome dell’ID. Eseguita questa prima inizializzazione “A” controlla se altro processo è in esecuzione: questo è indicato dal file “Rekur.txt” nella cartella ”TMP”; se esiste tale file un processo XML sta già girado. In un avvio ordinario questo file quindi non ci sarà e sarà ora “A” a scriverlo, evitando che parta un altro processo “A”. Il file di blocco avvio sarà poi cancellato da “A” nel momento in cui termina in modo ordinario l’XML, liberando cosi la strada per un ulteriore avvio ordinario. Arrivato a questo punto “A” sblocca “C” scrivendo nella cartelle “SYN” l’ID creato, quello che “C” controlla nella routine di attesa partenza. Appena “C” lo rivela lo cancella e prosegue con l’avvio e il funzionamento regolare. “C” inoltre cancella subito tutti i file che trovata nella cartella “ALV”. Nella routine principale “C” questo lo farà di seguito ciclicamente ogni volta che termina l’annuncio (variabile, max. ogni 10 secondi).
Vediamo ora come si comporta il tutto se un XML è già in esecuzione. La prima parte sarà identica, “A” e “C” si scambiano l’ID, “A” scrive l’ID nella cartella “ALV”, ma poi “A” riscontra il file “Rekur.txt” e attende che il suo ID sparisca nella cartella “ALV”. A cancellare file nella cartella “ALV” è il programma “C” che sta già girando in modo ordinario, e quindi se il fil ID di “A” viene cancellato nella cartella “ALV” significa che un processo “C” è attivo: Se “A” rivela questo termina subito mentre il “C”, non ricevendo da “A” il comando di avvio, termina dopo un timeout.
Se invece la CF e contiene un file “Rekur.txt” nonostante non vi sia un XML attivo, la situazione sopra sarà uguale fino al punto del timeout di “A”, che non vedeno scomparire il suo ID file nella cartella “ALV” (perché “C” non gira in modo ordinario) capisce la situazione e prosegue nonostante il file di blocco.
In sintesi quindi “A” e “C” si scambiano un ID che utilizzano per i vari passaggi di sincronizzazione, essendo un ID unico anche se partono diversi XML non si disturbano perché ogni copia utilizza i suoi file di sincronizzazione. “C” esegue la funzione di watchdog cancellando ciclicamente file che “A” in partenza scrive segnalando cosi un processo attivo.
Problematiche note
• Se durante una campagna di allarme il PBX si riavvia (reset oppure power fail) il sequencer si interrompe e non riparte una volta riavviato il sistema. Di conseguenza è necessario monitorare l’avvio del PBX (tramite SNMP oppure contatto su IP60x0 o IP8x0).
• Se si ha un forking su un interno, sarà indicato nei log sempre solo il numero interno (ovvero quello indicato nei vari file “x.txt”) anche se risponde il numero di forking. La stessa cosa avviene per logica anche nel caso di chiamata a un gruppo di interni e la stessa cosa succede se un interno chiamato ha una deviazione. Questo perché l’XML non esegue un controllo della chiamata a livello PBX ma rivela e riporta il numero dai file “x.txt”. Se quindi è essenziale capire chi ha realmente risposto sarà buon uso ricorrere in parallelo ad un reporting che illustri in dettaglio l’accaduto.
• Se l’email server non è disponibile, l’avviso andrà perso, il sistema non esegue spooling del messaggio.
Articoli corrleati
http://wiki.innovaphone.com/index.php?title=Howto:Door_opener_with_analog_FXS_port
http://wiki.innovaphone.com/index.php?title=Howto:Universal_Track_Recording_Tool
Download
Download the complete file package of scripts and files described in this article.